Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 02B5F80617; Mon, 30 Jul 2007 07:14:46 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 21F78142259; Mon, 30 Jul 2007 07:13:51 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-50 required=4 tests=[AWL=0.424, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnEl22xmrZ-V; Mon, 30 Jul 2007 07:13:44 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 90E6314225C; Mon, 30 Jul 2007 07:13:44 -0700 (PDT) Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l6UEDg80005535; Mon, 30 Jul 2007 08:13:42 -0600 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l6UDhMoC017446; Mon, 30 Jul 2007 08:13:41 -0600 Received: from dhcp-montreal-17fl-utilca-10-156-43-50.ca.oracle.com by acsmt350.oracle.com with ESMTP id 3079848131185804820; Mon, 30 Jul 2007 07:13:40 -0700 Message-ID: <46ADF213.10106@oracle.com> Date: Mon, 30 Jul 2007 10:13:39 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Bobby Rullo Subject: Re: [Ietf-caldav] Query By UID Without knowing Component Type References: <69420766-445F-42C0-B4E8-0185EA07848B@osafoundation.org> In-Reply-To: <69420766-445F-42C0-B4E8-0185EA07848B@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 14:14:46 -0000 Hi Bobby, Correct. The answer is no. What is the use case? Just curious! Cheers, Bernard Bobby Rullo wrote: > Hi all, > > Is it possible in CalDAV REPORTS to filter by components with a > particular UID without knowing what type of component (VEVENT, VTODO, > etc) you want? > > It seems like the answer is no, since a prop-filter must reside within a > comp-filter, which limits you to a particular component... > > Thanks! > > bobby_______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4280A7FA20 for ; Thu, 26 Jul 2007 17:39:53 -0700 (PDT) Received: from [192.168.103.11] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 575D01421F6 for ; Thu, 26 Jul 2007 17:38:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <69420766-445F-42C0-B4E8-0185EA07848B@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: CalDAV DevList From: Bobby Rullo Date: Thu, 26 Jul 2007 17:38:55 -0700 X-Mailer: Apple Mail (2.752.2) Subject: [Ietf-caldav] Query By UID Without knowing Component Type X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 00:39:53 -0000 Hi all, Is it possible in CalDAV REPORTS to filter by components with a particular UID without knowing what type of component (VEVENT, VTODO, etc) you want? It seems like the answer is no, since a prop-filter must reside within a comp-filter, which limits you to a particular component... Thanks! bobby Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E5C117F511 for ; Tue, 17 Jul 2007 09:50:52 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DE759142202 for ; Tue, 17 Jul 2007 09:49:57 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-50 required=4 tests=[AWL=1.039, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4019vQtSrjq for ; Tue, 17 Jul 2007 09:49:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 761191421FF for ; Tue, 17 Jul 2007 09:49:54 -0700 (PDT) Received: (qmail invoked by alias); 17 Jul 2007 16:49:52 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) [217.91.35.233] by mail.gmx.net (mp001) with SMTP; 17 Jul 2007 18:49:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18DmcMgz1gDlThoiuSZPnv3Ra/kSN2ect5v+P3dio Vn8u1MIGKE6sMw Message-ID: <469CF328.8050700@gmx.de> Date: Tue, 17 Jul 2007 18:49:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Arnaud Quillaud Subject: Re: [Ietf-caldav] MKCOL versus MKCALENDAR and status code References: <0JLC006DH10MSNU1@d1-emea-10.sun.com> In-Reply-To: <0JLC006DH10MSNU1@d1-emea-10.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 16:50:53 -0000 Arnaud Quillaud wrote: > Hello, > > Both WebDAV MKCOL and CalDAV MKCALENDAR should fail if the Request-URI is already mapped. Yes. > If I look at the MKCOL definition (http://tools.ietf.org/html/rfc4918#section-9.3.1), I see a corresponding status code: > << > 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL. > but no precondition. Yes. Probably should have been included. > If I look at the MKCALENDAR definition (http://tools.ietf.org/html/rfc4791#section-5.3.1), I see a corresponding precondition: > << > (DAV:resource-must-be-null): A resource MUST NOT exist at the Request-URI; > but no specific status code. Yes, that's stolen^H^H^H^H^H^Hcopied from . > The most common status code when sending back a precondition error is 403 (Forbidden). Not really. It's just a default when nothing else applies. > Both MKCOL and MKCALENDAR define the meaning of this status code in their context in the same way: > << > 403 (Forbidden) - This indicates at least one of two conditions: > 1) the server does not allow the creation of calendar collections > at the given location in its namespace, or 2) the parent > collection of the Request-URI exists but cannot accept members; > > So should MKCALENDAR return a 405 with a DAV:resource-must-be-null error body (and an Allow header), or a 403 with a DAV:resource-must-be-null error body ? 405. > If 403 with a DAV:resource-must-be-null is more appropriate, is there any harm doing the same for MKCOL ? Both should behave the same. That being said, I'd be surprised if it makes any difference in practice. Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 92AA47F8E0 for ; Tue, 17 Jul 2007 09:42:11 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8BAC6142203 for ; Tue, 17 Jul 2007 09:41:16 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-50 required=4 tests=[AWL=1.163, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h44Lr1ln6FzN for ; Tue, 17 Jul 2007 09:41:13 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id C26E3142202 for ; Tue, 17 Jul 2007 09:41:12 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6HGfBbV007377 for ; Tue, 17 Jul 2007 16:41:11 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLC00E010X37N00@d1-emea-10.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-caldav@osafoundation.org; Tue, 17 Jul 2007 17:41:11 +0100 (BST) Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.117.198]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLC006DG10MSNU1@d1-emea-10.sun.com> for ietf-caldav@osafoundation.org; Tue, 17 Jul 2007 17:41:11 +0100 (BST) Content-return: prohibited Date: Tue, 17 Jul 2007 18:41:41 +0200 From: Arnaud Quillaud Sender: Arnaud.Quillaud@Sun.COM To: ietf-caldav@osafoundation.org Message-id: <0JLC006DH10MSNU1@d1-emea-10.sun.com> MIME-version: 1.0 X-Mailer: Sun Outlook Connector 7.2.310.1 Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-transfer-encoding: 7BIT Subject: [Ietf-caldav] MKCOL versus MKCALENDAR and status code X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 16:42:11 -0000 Hello, Both WebDAV MKCOL and CalDAV MKCALENDAR should fail if the Request-URI is already mapped. If I look at the MKCOL definition (http://tools.ietf.org/html/rfc4918#section-9.3.1), I see a corresponding status code: << 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL. >> but no precondition. If I look at the MKCALENDAR definition (http://tools.ietf.org/html/rfc4791#section-5.3.1), I see a corresponding precondition: << (DAV:resource-must-be-null): A resource MUST NOT exist at the Request-URI; >> but no specific status code. The most common status code when sending back a precondition error is 403 (Forbidden). Both MKCOL and MKCALENDAR define the meaning of this status code in their context in the same way: << 403 (Forbidden) - This indicates at least one of two conditions: 1) the server does not allow the creation of calendar collections at the given location in its namespace, or 2) the parent collection of the Request-URI exists but cannot accept members; >> So should MKCALENDAR return a 405 with a DAV:resource-must-be-null error body (and an Allow header), or a 403 with a DAV:resource-must-be-null error body ? If 403 with a DAV:resource-must-be-null is more appropriate, is there any harm doing the same for MKCOL ? Thanks, Arnaud Q Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 674D080460 for ; Mon, 16 Jul 2007 07:02:30 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BD0314220D for ; Mon, 16 Jul 2007 07:01:35 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-50 required=4 tests=[AWL=0.432, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBijUJkE5Je8 for ; Mon, 16 Jul 2007 07:01:25 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C36F71421F2 for ; Mon, 16 Jul 2007 07:01:25 -0700 (PDT) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6GE1LBv024829; Mon, 16 Jul 2007 09:01:22 -0500 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l6GCjQTf018663; Mon, 16 Jul 2007 08:01:21 -0600 Received: from bdesruis-ca.ca.oracle.com by acsmt350.oracle.com with ESMTP id 3042651571184594471; Mon, 16 Jul 2007 07:01:11 -0700 Message-ID: <469B7A26.4080403@oracle.com> Date: Mon, 16 Jul 2007 10:01:10 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Julian Reschke Subject: Re: [Ietf-caldav] RFC4791 erratum wrt to condition name References: <46990011.8050905@gmx.de> In-Reply-To: <46990011.8050905@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2007 14:02:30 -0000 Hi Julian, Thanks for the feedback! I've started a draft to keep track of issues reported for RFC 4791. http://ietf.osafoundation.org/caldav/draft-desruisseaux-rfc4791bis.changes.html http://ietf.osafoundation.org/caldav/draft-desruisseaux-rfc4791bis.html http://ietf.osafoundation.org/caldav/draft-desruisseaux-rfc4791bis.pdf http://ietf.osafoundation.org/caldav/draft-desruisseaux-rfc4791bis.txt The text change for the issue you just brought up can be found here: http://ietf.osafoundation.org/caldav/draft-desruisseaux-rfc4791bis.changes.html#rfc.issue.need-privileges Thanks, Bernard Julian Reschke wrote: > Hi, > > says: > > (DAV:needs-privilege): The DAV:bind privilege MUST be granted to > the current user on the parent collection of the Request-URI. > > This should be...: > > (DAV:need-privileges): The DAV:bind privilege MUST be granted to > the current user on the parent collection of the Request-URI. > > ...it probably would be good if this would also point to the original > definition > (). > > Best regards, Julian > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav -- Bernard Desruisseaux | Senior Manager, Software Development | 514.905.8696 Oracle Server Technologies 600 Blvd. de Maisonneuve W., Suite 1900 | Montreal, Quebec H3A 3J2 Bernard Desruisseaux | Chef senior du développement logiciel | 514.905.8696 Oracle Technologies serveurs 600, boul. de Maisonneuve Ouest, bureau 1900 | Montréal (Québec) H3A 3J2 Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 26DAB80618 for ; Sat, 14 Jul 2007 09:56:48 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 15F6514220D for ; Sat, 14 Jul 2007 09:55:53 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-50 required=4 tests=[AWL=1.050, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pscxQsrRdnE3 for ; Sat, 14 Jul 2007 09:55:51 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id B8F9514220A for ; Sat, 14 Jul 2007 09:55:50 -0700 (PDT) Received: (qmail invoked by alias); 14 Jul 2007 16:55:49 -0000 Received: from p508FAC31.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.172.49] by mail.gmx.net (mp052) with SMTP; 14 Jul 2007 18:55:49 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Bz5cmuKKBdxRuR4QEGIXip0uiKDGwckeDcd6EP3 WhP4pTpCkAjcfH Message-ID: <46990011.8050905@gmx.de> Date: Sat, 14 Jul 2007 18:55:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: CalDAV DevList Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [Ietf-caldav] RFC4791 erratum wrt to condition name X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2007 16:56:48 -0000 Hi, says: (DAV:needs-privilege): The DAV:bind privilege MUST be granted to the current user on the parent collection of the Request-URI. This should be...: (DAV:need-privileges): The DAV:bind privilege MUST be granted to the current user on the parent collection of the Request-URI. ...it probably would be good if this would also point to the original definition (). Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3FCC980AAA for ; Fri, 13 Jul 2007 12:58:50 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2800E14220E for ; Fri, 13 Jul 2007 12:57:55 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-50 required=4 tests=[AWL=0.455, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSJBn5N-BiD7 for ; Fri, 13 Jul 2007 12:57:53 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F3D32142207 for ; Fri, 13 Jul 2007 12:57:52 -0700 (PDT) Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l6DJvm82025612; Fri, 13 Jul 2007 13:57:48 -0600 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6DJvlcE010129; Fri, 13 Jul 2007 13:57:47 -0600 Received: from bdesruis-ca.ca.oracle.com by acsmt351.oracle.com with ESMTP id 3038431001184356651; Fri, 13 Jul 2007 12:57:31 -0700 Message-ID: <4697D91E.208@oracle.com> Date: Fri, 13 Jul 2007 15:57:18 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: CalDAV DevList , ietf-calendar@imc.org, imc-vcalendar@mail.imc.org, libical@softwarestudio.org, www-rdf-calendar@w3.org Content-Type: multipart/mixed; boundary="------------040002010104060109090008" X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-ietf-calsify-rfc2445bis-07.txt] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 19:58:50 -0000 This is a multi-part message in MIME format. --------------040002010104060109090008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The Calsify WG Chairs have issued a Working Group Last Call on draft-ietf-calsify-rfc2445bis-07.txt (i.e., the revision of iCalendar). See: http://lists.osafoundation.org/pipermail/ietf-calsify/2007-July/001762.html People interested to know exactly what was changed in RFC 2445 can look at the following annotated version of the draft: http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.changes.html Please send your comments to the ietf-calsify@osafoundation.org mailing list before August 10th, 2007. Cheers, Bernard -------- Original Message -------- Subject: I-D ACTION:draft-ietf-calsify-rfc2445bis-07.txt Date: Mon, 09 Jul 2007 17:15:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ietf-calsify@osafoundation.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF. Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Author(s) : B. Desruisseaux Filename : draft-ietf-calsify-rfc2445bis-07.txt Pages : 177 Date : 2007-7-9 This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to- dos, journal entries and free/busy information, independent of any particular calendar service or protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsify-rfc2445bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------040002010104060109090008 Content-Type: Message/External-body; name="draft-ietf-calsify-rfc2445bis-07.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-calsify-rfc2445bis-07.txt" Content-Type: text/plain Content-ID: <2007-7-9155906.I-D@ietf.org> --------------040002010104060109090008 Content-Type: text/plain; name="file:///C:/DOCUME~1/BDESRUIS/LOCALS~1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C:/DOCUME~1/BDESRUIS/LOCALS~1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------040002010104060109090008-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 39C7880708; Wed, 11 Jul 2007 13:30:05 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 21BBB1421FD; Wed, 11 Jul 2007 13:29:10 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-50 required=4 tests=[AWL=0.007, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPj3LobUNr+X; Wed, 11 Jul 2007 13:29:08 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 551CB1421FC; Wed, 11 Jul 2007 13:29:08 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1I8io8-0005Qk-CE; Wed, 11 Jul 2007 13:29:08 -0700 Message-ID: <46953D8D.30109@calconnect.org> Date: Wed, 11 Jul 2007 13:29:01 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-caldav list , ietf-calsify list , ietf-calendar list Content-Type: multipart/alternative; boundary="------------090303050507070509070308" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-caldav] CalDAV Scheduling Requirements paper published by CalConnect X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 20:30:05 -0000 This is a multi-part message in MIME format. --------------090303050507070509070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit /CalDAV Scheduling Requirements V1.1/ has been published by the CalDAV Technical Committee of the Calendaring and Scheduling Consortium. It presents a list of features in the form of requirements for the scheduling extensions to CalDAV [RFC 4791], that is, the extensions to the Web Distributed Authoring and Versioning (WebDAV) [RFC 2518] protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC 2446]. The document is at http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf. -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------090303050507070509070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit CalDAV Scheduling Requirements V1.1 has been published by the CalDAV Technical Committee of the Calendaring and Scheduling Consortium. It presents a list of features in the form of requirements for the scheduling extensions to CalDAV [RFC 4791], that is, the extensions to the Web Distributed Authoring and Versioning (WebDAV) [RFC 2518] protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC 2446].   The document is at http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf.
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------090303050507070509070308-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 65DD180705 for ; Wed, 11 Jul 2007 03:16:08 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4AD191421FC for ; Wed, 11 Jul 2007 03:15:13 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-50 required=4 tests=[AWL=1.199, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoMB+xFsUHTl for ; Wed, 11 Jul 2007 03:15:11 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id B092A1421F7 for ; Wed, 11 Jul 2007 03:15:08 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6BAF7EI000680 for ; Wed, 11 Jul 2007 10:15:07 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL000801F52KW00@d1-emea-09.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-caldav@osafoundation.org; Wed, 11 Jul 2007 11:15:07 +0100 (BST) Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.117.41]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL000465F55WO2S@d1-emea-09.sun.com>; Wed, 11 Jul 2007 11:15:07 +0100 (BST) Content-return: prohibited Date: Wed, 11 Jul 2007 12:15:38 +0200 From: Arnaud Quillaud Subject: RE : [Ietf-caldav] authorization identity In-reply-to: Sender: Arnaud.Quillaud@Sun.COM To: Cyrus Daboo , ietf-caldav@osafoundation.org Message-id: <0JL000466F56WO2S@d1-emea-09.sun.com> MIME-version: 1.0 X-Mailer: Sun Outlook Connector 7.2.310.1 Content-type: TEXT/PLAIN; CHARSET=Windows-1252 Content-transfer-encoding: QUOTED-PRINTABLE X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 10:16:08 -0000 I was talking about the "sudo" user. Thanks. Arnaud > -----Message d'origine----- > De : Cyrus Daboo [mailto:cyrus@daboo.name]=20 > Envoy=E9 : samedi 7 juillet 2007 16:47 > =C0 : Arnaud Quillaud; ietf-caldav@osafoundation.org > Objet : Re: [Ietf-caldav] authorization identity >=20 >=20 > Hi Arnaud, >=20 > --On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud=20 > wrote: >=20 > > For connection oriented protocols, SASL defines the notion of= =20 > > authorization identity=20 > > (http://tools.ietf.org/html/rfc4422#section-3.4.1). This allows = to=20 > > authenticate as one user and then "switch identity" to act=20 > as another=20 > > user for all following operations (of course assuming that the= =20 > > authenticated user has the right to act on behalf of the=20 > other user). > > > > HTTP and HTTP Basic authentication=20 > > (http://tools.ietf.org/html/rfc2617) > > which is more or less the only auth mechanism supported by=20 > CalDAV do not > > seem to include such functionality. > > > > Is the functionality actually defined somewhere else or is=20 > it missing=20 > > from HTTP/WebDAV/CalDAV ? Is any CalDAV client/server using=20 > > proprietary mechanism (e.g. simple http header) to achieve the sa= me=20 > > result ? >=20 > It is missing. In the Apple CalendarServer we have a private=20 > header that=20 > does this. We maintain a special list of "sudo" users - those=20 > are users who=20 > can authenticate using HTTP but then authorize as someone=20 > else by including=20 > the special header. I think any revisions to or new=20 > mechanisms for HTTP=20 > auth should include an authorization identity facility. >=20 > BTW Do you want to use this facility to support calendar user=20 > proxying -=20 > i.e. one user acting on behalf of another? If so, there is an=20 > alternative=20 > approach to that that we also implemented and which has been=20 > presented to=20 > Calconnect to move forward with standarizing. Our approach=20 > for that is to=20 > use ACLs - basically the server has two group principals per=20 > "primary"=20 > principal. Members of those groups are proxy users for the=20 > corresponding=20 > primary principal. The server automatically provisions=20 > privileges on each=20 > user's account such that these proxy groups have the=20 > appropriate privileges=20 > (one group only has read access, the other group additionally=20 > has write and=20 > scheduling access). This approach allows a calendar client to=20 > control proxy=20 > user access by simply adding/removing users on the relevant=20 > proxy group=20 > principals. >=20 > There are several benefits to this over the authorization=20 > identity approach=20 > - not least is the ability to disable access on specific=20 > resources via=20 > ACLs. i.e. there are times when you don't want a proxy to see=20 > events - ones=20 > that might relate directly to them or others etc. This=20 > approach allows=20 > that, whereas an authorization identity will not. >=20 > Calconnect is working on a more generalized concept based on=20 > this, that=20 > would allow definition of arbitrary "roles" (two of which map=20 > to the proxy=20 > groups we have). Hopefully we will be submitting something to=20 > the IETF soon=20 > for standardization. >=20 >=20 >=20 > --=20 > Cyrus Daboo >=20 >=20 Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 952BA80A60 for ; Sat, 7 Jul 2007 08:09:51 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 71569142207 for ; Sat, 7 Jul 2007 08:08:56 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-50 required=4 tests=[AWL=0.854, BAYES_00=-2.599, MSGID_FROM_MTA_ID=1.393] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJJ2yWriX4a7 for ; Sat, 7 Jul 2007 08:08:54 -0700 (PDT) Received: from alnrmhc15.comcast.net (alnrmhc15.comcast.net [206.18.177.55]) by laweleka.osafoundation.org (Postfix) with ESMTP id AA9BA142202 for ; Sat, 7 Jul 2007 08:08:54 -0700 (PDT) Received: from thare (c-71-203-100-120.hsd1.fl.comcast.net[71.203.100.120]) by comcast.net (alnrmhc15) with SMTP id <20070707150853b1500ch8hue>; Sat, 7 Jul 2007 15:08:53 +0000 From: "Tim Hare" To: "'CalDAV DevList'" Subject: RE: [Ietf-caldav] authorization identity Date: Sat, 7 Jul 2007 11:09:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcfApaTH7DZT5/PbTo+mnC7KhDSvQAAAbNuQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Message-Id: <20070707150854.AA9BA142202@laweleka.osafoundation.org> X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2007 15:09:51 -0000 Not to bring my mainframe background into this, but... Most mainframe security products protect a resource by a profile, to which users _or_ groups may be granted appropriate access. The advantage of using groups is that the group can remain in the access list, but someone granted authority can manage the contents of the group, without being the owning/controlling administrator of the resource. For example: I, as system administrator, may own a set of conference rooms. I can grant scheduling access to SchedGroup A and SchedGroup B, and allow Manager A and Manager B to control who within their organization is a member of those groups. This works well for both parties: if I feel Group B is abusing their privilege (or for some other reason) I can revoke SchedGroup B's access without knowing who is in SchedGroupB; the manager can handle staff turnover, or changes of duties, by determining who he connects to SchedGroupB. I think the ACL mechanisms work better than allowing 'sudo' switching; and since things are always occurring in one user's security context, there's no doubts when debugging or auditing as there would be otherwise. Think of the case where the sudo doesn't work correctly, some updates in a transaction get done under the special ID, others under the 'sudo' ID; this could be due to program bugs or to multiprocessing environments gone wrong, but it still adds to the problem of figuring out who actually updated the calendar. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: ietf-caldav-bounces@osafoundation.org [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of Cyrus Daboo Sent: Saturday, July 07, 2007 10:47 AM To: Arnaud Quillaud; ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] authorization identity Hi Arnaud, --On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud wrote: > For connection oriented protocols, SASL defines the notion of > authorization identity > (http://tools.ietf.org/html/rfc4422#section-3.4.1). This allows to > authenticate as one user and then "switch identity" to act as another > user for all following operations (of course assuming that the > authenticated user has the right to act on behalf of the other user). > > HTTP and HTTP Basic authentication > (http://tools.ietf.org/html/rfc2617) > which is more or less the only auth mechanism supported by CalDAV do > not seem to include such functionality. > > Is the functionality actually defined somewhere else or is it missing > from HTTP/WebDAV/CalDAV ? Is any CalDAV client/server using > proprietary mechanism (e.g. simple http header) to achieve the same result ? It is missing. In the Apple CalendarServer we have a private header that does this. We maintain a special list of "sudo" users - those are users who can authenticate using HTTP but then authorize as someone else by including the special header. I think any revisions to or new mechanisms for HTTP auth should include an authorization identity facility. BTW Do you want to use this facility to support calendar user proxying - i.e. one user acting on behalf of another? If so, there is an alternative approach to that that we also implemented and which has been presented to Calconnect to move forward with standarizing. Our approach for that is to use ACLs - basically the server has two group principals per "primary" principal. Members of those groups are proxy users for the corresponding primary principal. The server automatically provisions privileges on each user's account such that these proxy groups have the appropriate privileges (one group only has read access, the other group additionally has write and scheduling access). This approach allows a calendar client to control proxy user access by simply adding/removing users on the relevant proxy group principals. There are several benefits to this over the authorization identity approach - not least is the ability to disable access on specific resources via ACLs. i.e. there are times when you don't want a proxy to see events - ones that might relate directly to them or others etc. This approach allows that, whereas an authorization identity will not. Calconnect is working on a more generalized concept based on this, that would allow definition of arbitrary "roles" (two of which map to the proxy groups we have). Hopefully we will be submitting something to the IETF soon for standardization. -- Cyrus Daboo _______________________________________________ Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org See http://ietf.webdav.org/caldav/ for more CalDAV resources http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3C14480A25 for ; Sat, 7 Jul 2007 07:47:40 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1AF591421F7 for ; Sat, 7 Jul 2007 07:46:45 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-50 required=4 tests=[AWL=0.215, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjbpqcZ6IF9W for ; Sat, 7 Jul 2007 07:46:43 -0700 (PDT) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 20139142202 for ; Sat, 7 Jul 2007 07:46:42 -0700 (PDT) Received: from [10.0.1.2] ([10.0.1.2]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l67EkcW2010494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jul 2007 10:46:38 -0400 Date: Sat, 07 Jul 2007 10:46:38 -0400 From: Cyrus Daboo To: Arnaud Quillaud , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] authorization identity Message-ID: In-Reply-To: <0JKT005PGBRTQG09@d1-emea-09.sun.com> References: <0JKT005PGBRTQG09@d1-emea-09.sun.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2007 14:47:40 -0000 Hi Arnaud, --On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud wrote: > For connection oriented protocols, SASL defines the notion of > authorization identity > (http://tools.ietf.org/html/rfc4422#section-3.4.1). This allows to > authenticate as one user and then "switch identity" to act as another > user for all following operations (of course assuming that the > authenticated user has the right to act on behalf of the other user). > > HTTP and HTTP Basic authentication (http://tools.ietf.org/html/rfc2617) > which is more or less the only auth mechanism supported by CalDAV do not > seem to include such functionality. > > Is the functionality actually defined somewhere else or is it missing > from HTTP/WebDAV/CalDAV ? Is any CalDAV client/server using proprietary > mechanism (e.g. simple http header) to achieve the same result ? It is missing. In the Apple CalendarServer we have a private header that does this. We maintain a special list of "sudo" users - those are users who can authenticate using HTTP but then authorize as someone else by including the special header. I think any revisions to or new mechanisms for HTTP auth should include an authorization identity facility. BTW Do you want to use this facility to support calendar user proxying - i.e. one user acting on behalf of another? If so, there is an alternative approach to that that we also implemented and which has been presented to Calconnect to move forward with standarizing. Our approach for that is to use ACLs - basically the server has two group principals per "primary" principal. Members of those groups are proxy users for the corresponding primary principal. The server automatically provisions privileges on each user's account such that these proxy groups have the appropriate privileges (one group only has read access, the other group additionally has write and scheduling access). This approach allows a calendar client to control proxy user access by simply adding/removing users on the relevant proxy group principals. There are several benefits to this over the authorization identity approach - not least is the ability to disable access on specific resources via ACLs. i.e. there are times when you don't want a proxy to see events - ones that might relate directly to them or others etc. This approach allows that, whereas an authorization identity will not. Calconnect is working on a more generalized concept based on this, that would allow definition of arbitrary "roles" (two of which map to the proxy groups we have). Hopefully we will be submitting something to the IETF soon for standardization. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 748E5804CA for ; Sat, 7 Jul 2007 07:20:04 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 53C5E142202 for ; Sat, 7 Jul 2007 07:19:09 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-50 required=4 tests=[AWL=1.238, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKmnM2UoGFBA for ; Sat, 7 Jul 2007 07:19:07 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 56C3E142201 for ; Sat, 7 Jul 2007 07:19:07 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l67EJ5ib020794 for ; Sat, 7 Jul 2007 14:19:06 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKT00I01BLJBZ00@d1-emea-09.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-caldav@osafoundation.org; Sat, 07 Jul 2007 15:19:05 +0100 (BST) Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.116.111]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKT005PFBRSQG09@d1-emea-09.sun.com> for ietf-caldav@osafoundation.org; Sat, 07 Jul 2007 15:19:05 +0100 (BST) Content-return: prohibited Date: Sat, 07 Jul 2007 16:19:35 +0200 From: Arnaud Quillaud Sender: Arnaud.Quillaud@Sun.COM To: ietf-caldav@osafoundation.org Message-id: <0JKT005PGBRTQG09@d1-emea-09.sun.com> MIME-version: 1.0 X-Mailer: Sun Outlook Connector 7.2.310.1 Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-transfer-encoding: 7BIT Subject: [Ietf-caldav] authorization identity X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2007 14:20:04 -0000 For connection oriented protocols, SASL defines the notion of authorization identity (http://tools.ietf.org/html/rfc4422#section-3.4.1). This allows to authenticate as one user and then "switch identity" to act as another user for all following operations (of course assuming that the authenticated user has the right to act on behalf of the other user). HTTP and HTTP Basic authentication (http://tools.ietf.org/html/rfc2617) which is more or less the only auth mechanism supported by CalDAV do not seem to include such functionality. Is the functionality actually defined somewhere else or is it missing from HTTP/WebDAV/CalDAV ? Is any CalDAV client/server using proprietary mechanism (e.g. simple http header) to achieve the same result ? Thanks, Arnaud Q Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8CBBB809D6; Fri, 6 Jul 2007 18:34:25 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A57114220A; Fri, 6 Jul 2007 18:33:30 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-50 required=4 tests=[AWL=0.006, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obOYGUaaxi7x; Fri, 6 Jul 2007 18:33:27 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CC8241421F7; Fri, 6 Jul 2007 18:33:27 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.100]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1I6zAw-0005Ob-LC; Fri, 06 Jul 2007 18:33:30 -0700 Message-ID: <468EED65.6010806@calconnect.org> Date: Fri, 06 Jul 2007 18:33:25 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-calendar list , ietf-calsify list , ietf-caldav list Content-Type: multipart/alternative; boundary="------------030804020304020806040400" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-caldav] My apologies for multiple CalConnect-related postings X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2007 01:34:25 -0000 This is a multi-part message in MIME format. --------------030804020304020806040400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I seem to have screwed up somehow and posted our announcement of the vCard workshop and possibly the next Roundtable multiple times to at least one of these lists. And to make it worse, many people are subscribed to two or more of them, and thus got an unnecessary flood of repeats. I apologize for the mistake, however it occurred, and will do my best to not do it again. I hope that the irritant didn't overcome the messages! Apologies again, Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------030804020304020806040400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I seem to have screwed up somehow and posted our announcement of the vCard workshop and possibly the next Roundtable multiple times to at least one of these lists.

And to make it worse, many people are subscribed to two or more of them, and thus got an unnecessary flood of repeats.

I apologize for the mistake, however it occurred, and will do my best to not do it again.  I hope that the irritant didn't overcome the messages!

Apologies again,

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------030804020304020806040400-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 82E628084A for ; Fri, 6 Jul 2007 10:17:43 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5CDDE142212 for ; Fri, 6 Jul 2007 10:16:48 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-50 required=4 tests=[AWL=0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZLFX3DtoOIW for ; Fri, 6 Jul 2007 10:16:45 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5AB9D14220A for ; Fri, 6 Jul 2007 10:16:45 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1I6rQE-00062W-9c; Fri, 06 Jul 2007 10:16:46 -0700 Message-ID: <468E78F4.6000102@calconnect.org> Date: Fri, 06 Jul 2007 10:16:36 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-caldav list Content-Type: multipart/alternative; boundary="------------070605060307080506020202" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-caldav] CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2007 17:17:43 -0000 This is a multi-part message in MIME format. --------------070605060307080506020202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit CalConnect invites you to a a one-day open workshop on vCard and what should be done about it on Tuesday, September 18, 2007, at M.I.T. in Cambridge, Massachusetts. This event is _open_ to vendors, customers, CalConnect members and non-members alike. There is no fee, but you _must_ register in advance and numbers are limited. Please see http://www.calconnect.org/vcardworkshop.shtml for more information and links to the registration and logistics pages, a general discussion list about the workshop, and a questionnaire to give us more guidance to make the workshop as productive as possible. From the workshop introduction page: vCard is a well established standard for representing and transferring contact information on computer systems and mobile devices. Having been in use for a while, a number of areas of the specification have been noted as problematic and in need of revision for fixes or enhancements. To that end, CalConnect (the Calendaring & Scheduling Consortium) is hosting a one day vCard-focused workshop event at M.I.T. in Cambridge, Massachusetts in September with the goal of bringing together the key players to help move forward vCard revision efforts. Note that an effort is already under way at the IETF (Internet Engineering Task Force) to develop a personal address book access protocol based on the CardDAV specification, and since that is based on vCard, a revision of the vCard specification will be taking place within the IETF. However, bringing together interested parties in a focused discussion at a workshop can help drive that effort and provide supporting input to it to ensure the specific needs of the key players is covered. The goal of the workshop is two-fold. First to determine the real interest in revising the vCard specification, and second to determine what needs to be revised and how to go about doing that. If you are not a CalConnect member, this is also an opportunity to stay on for Roundtable X as an observer, and we'd be delighted to have you; you will have to register separately for the Roundtable. Regardless of whether or not you are interested in attending the workshop, we would appreciate it very much if you would take a few minutes to fill out the questionnaire , as this will help provide the workshop participants with guidance as to the directions any progression on vCard should take. -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------070605060307080506020202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit CalConnect invites you to a a one-day open workshop on vCard and what should be done about it on Tuesday, September 18, 2007, at M.I.T. in Cambridge, Massachusetts. This event is open to vendors, customers, CalConnect members and non-members alike. There is no fee, but you must register in advance and numbers are limited. Please see
http://www.calconnect.org/vcardworkshop.shtml for more information and links to the registration and logistics pages, a general discussion list about the workshop, and a questionnaire to give us more guidance to make the workshop as productive as possible.

>From the workshop introduction page:

vCard is a well established standard for representing and transferring contact information on computer systems and mobile devices. Having been in use for a while, a number of areas of the specification have been noted as problematic and in need of revision for fixes or enhancements. To that end, CalConnect (the Calendaring & Scheduling Consortium) is hosting a one day vCard-focused workshop event at M.I.T. in Cambridge, Massachusetts in September with the goal of bringing together the key players to help move forward vCard revision efforts.

Note that an effort is already under way at the IETF (Internet Engineering Task Force) to develop a personal address book access protocol based on the CardDAV specification, and since that is based on vCard, a revision of the vCard specification will be taking place within the IETF. However, bringing together interested parties in a focused discussion at a workshop can help drive that effort and provide supporting input to it to ensure the specific needs of the key players is covered.

The goal of the workshop is two-fold. First to determine the real interest in revising the vCard specification, and second to determine what needs to be revised and how to go about doing that.


If you are not a CalConnect member, this is also an opportunity to stay on for Roundtable X as an observer, and we'd be delighted to have you; you will have to register separately for the Roundtable. 

Regardless of whether or not you are interested in attending the workshop, we would appreciate it very much if you would take a few minutes to fill out the questionnaire, as this will help provide the workshop participants with guidance as to the directions any progression on vCard should take.


--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------070605060307080506020202-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D51577F54A for ; Fri, 6 Jul 2007 09:50:05 -0700 (PDT) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8B4421421F2 for ; Fri, 6 Jul 2007 09:49:10 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-50 required=4 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRY09qNz8FuS for ; Fri, 6 Jul 2007 09:49:07 -0700 (PDT) Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7B55E1421F7 for ; Fri, 6 Jul 2007 09:49:07 -0700 (PDT) Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.66) (envelope-from ) id 1I6qzT-0003hW-DA; Fri, 06 Jul 2007 09:49:07 -0700 Message-ID: <468E727A.3030404@calconnect.org> Date: Fri, 06 Jul 2007 09:48:58 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-caldav list Content-Type: multipart/alternative; boundary="------------020900090202010405060108" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - redwood.morsemedia.net X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-caldav] Announcing CalConnect Roundtable X and Interoperability Test Event -September 17-21, Cambridge, Massachusetts X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2007 16:50:09 -0000 This is a multi-part message in MIME format. --------------020900090202010405060108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit *The Calendaring and Scheduling Consortium announces Roundtable X and IOP Test Event *CalConnect would like to invite you to our Roundtable X and the associated CalConnect Interoperability Test Event, the week of September 17-21, 2007, in Cambridge, Massachusetts, hosted by M.I.T. Registration is now open for the Roundtable and/or the IOP test event. Logistics and registration information may be found at http://www.calconnect.org/roundtable10.shtml and at http://www.calconnect.org/iopseptember2007.shtml General schedule: The IOP test will begin at noon Monday and run through noon Wednesday. The Roundtable will begin at lunch on Wednesday and run through lunch on Friday. We plan to offer optional practicums on the iCalendar RFCs (iCalendar/iTIP/iMIP) and on CalDAV on Wednesday morning prior to lunch. The IOP test event will involve both CalDAV and regular iCalendar, iMIP and iTIP interoperability testing scenarios. In addition, plans and preliminary work for a Mobile Calendar IOP Test Event, and the scenarios associated with that event, will be covered. Roundtables are largely comprised of technical committee sessions, which generally include reports on work accomplished or in progress, working sessions in a "committee of the whole" environment for all interested parties, and discussions about work to be undertaken. Time is also set aside for BOFs either scheduled in advance, or impromptu at the meeting. If you are not currently a member of the Consortium, you may attend a single Roundtable, or a single IOP test event, as an observer; see http://www.calconnect.org/observer.shtml for more information. Both members and non-members may participate in the IOP test events. If you think you might attend, it is advisable to book your hotel room early -- hotel rooms in Cambridge in September are hard to come by. For more information, please call or e-mail me as below. See you in Cambridge! Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------020900090202010405060108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Calendaring and Scheduling Consortium announces Roundtable X and  IOP Test Event

CalConnect would like to invite you to our Roundtable X and the associated CalConnect Interoperability Test Event, the week of September 17-21, 2007, in Cambridge, Massachusetts, hosted by M.I.T.  Registration is now open for the Roundtable and/or the IOP test event.  Logistics and registration information may be found at http://www.calconnect.org/roundtable10.shtml and at http://www.calconnect.org/iopseptember2007.shtml

General schedule:  The IOP test will begin at noon Monday and run through noon Wednesday.  The Roundtable will begin at lunch on Wednesday and run through lunch on Friday.  We plan to offer optional practicums on the iCalendar RFCs (iCalendar/iTIP/iMIP) and on CalDAV on Wednesday morning prior to lunch. 

The IOP test event will involve both CalDAV and regular iCalendar, iMIP and iTIP interoperability testing scenarios.  In addition, plans and preliminary work for a Mobile Calendar IOP Test Event, and the scenarios associated with that event, will be covered.

Roundtables are largely comprised of technical committee sessions, which generally include reports on work accomplished or in progress, working sessions in a "committee of the whole" environment for all interested parties, and discussions about work to be undertaken.  Time is also set aside for BOFs either scheduled in advance, or impromptu at the meeting.

If you are not currently a member of the Consortium, you may attend a single Roundtable, or a single IOP test event, as an observer; see http://www.calconnect.org/observer.shtml for more information.

Both members and non-members may participate in the IOP test events.

If you think you might attend, it is advisable to book your hotel room early -- hotel rooms in Cambridge in September are hard to come by.

For more information, please call or e-mail me as below.

See you in Cambridge!

Dave Thewlis

--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------020900090202010405060108--