Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id E07F03E3D84 for ; Thu, 30 Oct 2008 14:35:05 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.102 X-Spam-Level: X-Spam-Status: No, score=0.102 tagged_above=-50 required=4 tests=[BAYES_50=0.001, DNS_FROM_SECURITYSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeQsX2KDV7eQ for ; Thu, 30 Oct 2008 14:35:04 -0700 (PDT) Received: from postalo2.babel.it (81-208-88-105.ip.fastwebnet.it [81.208.88.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 34C873E3D5E for ; Thu, 30 Oct 2008 14:35:04 -0700 (PDT) Received: by postalo2.babel.it (Postfix, from userid 8) id 887A811C58D; Thu, 30 Oct 2008 22:34:49 +0100 (CET) Received: from ananke.lan (unknown [78.13.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rpolli) by postalo2.babel.it (Postfix) with ESMTP id 6E97611C579 for ; Thu, 30 Oct 2008 22:34:46 +0100 (CET) From: Roberto Polli Organization: Babel s.r.l To: ietf-caldav@osafoundation.org Date: Thu, 30 Oct 2008 22:34:54 +0100 User-Agent: KMail/1.9.10 References: <3804FE931F869D387CAF45C4@caldav.corp.apple.com> In-Reply-To: <3804FE931F869D387CAF45C4@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810302234.54581.rpolli@babel.it> Subject: Re: [ietf-caldav] New CalDAV Resource website X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 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: Thu, 30 Oct 2008 21:35:06 -0000 Alle gioved=EC 30 ottobre 2008, Cyrus Daboo ha scritto: > seen! R. =2D-=20 Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo=20 messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20 notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi= o=20 erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto= =20 della legge in materia di protezione dei dati personali." Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 7EFBE3E3D63 for ; Thu, 30 Oct 2008 08:38:07 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usJUkwpGcNwl for ; Thu, 30 Oct 2008 08:38:03 -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 leka.osafoundation.org (Postfix) with ESMTP id 5E5B53E3C7C for ; Thu, 30 Oct 2008 08:38:03 -0700 (PDT) Received: from m6d0f36d0.tmodns.net ([208.54.15.109] helo=[10.242.44.115]) by redwood.morsemedia.net with esmtpa (Exim 4.69) (envelope-from ) id 1KvZb0-0005kt-Rn; Thu, 30 Oct 2008 08:38:02 -0700 Message-ID: <4909D4D8.3060806@calconnect.org> Date: Thu, 30 Oct 2008 08:38:00 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-caldav list Content-Type: multipart/alternative; boundary="------------080403010603000905070901" 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] An Invitation to Meet CalConnect in Europe in November X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 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: Thu, 30 Oct 2008 15:38:07 -0000 This is a multi-part message in MIME format. --------------080403010603000905070901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Folks, CalConnect - The Calendaring and Scheduling Consortium - will be holding an introductory Meet CalConnect event in Europe in early November, and I would like to invite you to one of the two sessions to introduce CalConnect and give you a chance to learn more about who we are, what we do, and how we are working to further interoperable Calendaring and Scheduling. The event will be held the afternoons of Friday November 7th in Prague, Czech Republic, and Monday November 10th in London, England. Each event is scheduled for 1300-1600 and will be preceded by a light lunch and followed by a reception. There will be no charge but we do request that you register in advance so we know how many people to expect at each venue. Complete details on the event, including locations, logistics, and a link to the registration form, is at http://www.calconnect.org/meetcalconnect.shtml. Best Regards, 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 --------------080403010603000905070901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Folks,

CalConnect - The Calendaring and Scheduling Consortium - will be holding an introductory Meet CalConnect event in Europe in early November, and I would like to invite you to one of the two sessions to introduce CalConnect and give you a chance to learn more about who we are, what we do, and how we are working to further interoperable Calendaring and Scheduling. 

The event will be held the afternoons of Friday November 7th in Prague, Czech Republic, and Monday November 10th in London, England.  Each event is scheduled for 1300-1600 and will be preceded by a light lunch and followed by a reception.

There will be no charge but we do request that you register in advance so we know how many people to expect at each venue.

Complete details on the event, including locations, logistics, and a link to the registration form, is at http://www.calconnect.org/meetcalconnect.shtml

Best Regards,

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
--------------080403010603000905070901-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 662023E3D2B for ; Thu, 30 Oct 2008 07:54:11 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxZ8Z5kj7JI9 for ; Thu, 30 Oct 2008 07:54:09 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by leka.osafoundation.org (Postfix) with ESMTP id DAD3F3E3D5A for ; Thu, 30 Oct 2008 07:54:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 9A07CE77906 for ; Thu, 30 Oct 2008 10:54:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nZZHQ2F8DpV for ; Thu, 30 Oct 2008 10:54:03 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 8F896E778FF for ; Thu, 30 Oct 2008 10:54:02 -0400 (EDT) Date: Thu, 30 Oct 2008 10:53:59 -0400 From: Cyrus Daboo To: ietf-caldav@osafoundation.org Message-ID: <3804FE931F869D387CAF45C4@caldav.corp.apple.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 Subject: [ietf-caldav] New CalDAV Resource website X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 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: Thu, 30 Oct 2008 14:54:11 -0000 Hi folks, I am pleased to say we have a new CalDAV Resource website: Our goal is to keep this up to date with lots of useful information, including details of products, service providers, news (such as the upcoming CalConnect Mobile interop and "Meet CalConnect" events in Europe, IETF meetings etc). Please review and feel free to use the "Contact Us" link on the website to send feedback - corrections, ideas for new content etc. The site is pretty basic right now but we would really like to expand it with more useful content. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 2FA9E3E3CEA for ; Wed, 29 Oct 2008 20:34:52 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, SPF_PASS=-0.001] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om2PVgTCnsOf for ; Wed, 29 Oct 2008 20:34:51 -0700 (PDT) Received: from mail1.catalyst.net.nz (godel.catalyst.net.nz [202.78.240.40]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id D3AD23E3C76 for ; Wed, 29 Oct 2008 20:34:50 -0700 (PDT) Received: from [2404:130:b055:0:215:afff:fe48:6c48] by mail1.catalyst.net.nz with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KvOJ1-0001A0-4T for ietf-caldav@osafoundation.org; Thu, 30 Oct 2008 16:34:43 +1300 From: Andrew McMillan To: ietf-caldav@osafoundation.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+cgFmzitbTUtFXt8km9c" Date: Thu, 30 Oct 2008 16:34:42 +1300 Message-Id: <1225337682.14860.108.camel@happy.mcmillan.net.nz> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [ietf-caldav] Response when free/busy information is unavailable X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 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: Thu, 30 Oct 2008 03:34:52 -0000 --=-+cgFmzitbTUtFXt8km9c Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I've been puzzling my way through the draft scheduling extensions for CalDAV and I don't find it clear what sort of response should be delivered in situations where the access is denied, or the attendee cannot be found. My best guess is that if the attendee can't be found I should respond something like this: mailto:user3@example.n 3.7;Invalid Calendar User And then if they can be found, but this user is not authorised to see the free/busy information, then the response should look something like this: mailto:user3@example.net 3.8;No authority Are those reasonable answers? I'm particularly uncertain about the second response, because it seems that by doing so I am providing an avenue for someone to ascertain whether the user does or does not exist. Thanks, Andrew McMillan. ------------------------------------------------------------------------ Andrew @ McMillan .Net .NZ Porirua, New Zealand http://andrew.mcmillan.net.nz/ Phone: +64(272)DEBIAN We should all be glad that Richard Reid wasn't the 'underwear bomber' -- Bruce Schneier ------------------------------------------------------------------------ --=-+cgFmzitbTUtFXt8km9c Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkkJK04ACgkQjJA0f48GgBKlvwCfcH47nSS8H/IMRUr0JjPMyGXe jp8An0Inhc1vbRHOhXc/z9we4JIwJZts =x/kK -----END PGP SIGNATURE----- --=-+cgFmzitbTUtFXt8km9c-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 4F2733E38FF for ; Thu, 23 Oct 2008 06:49:02 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, HTML_MESSAGE=0.001] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4fhKOhN96gr for ; Thu, 23 Oct 2008 06:48:38 -0700 (PDT) Received: from engine19-1277-1.icritical.com (engine19-1277-1.icritical.com [78.33.47.133]) by leka.osafoundation.org (Postfix) with SMTP id B6A403E390D for ; Thu, 23 Oct 2008 06:48:35 -0700 (PDT) Received: (qmail 9348 invoked from network); 23 Oct 2008 13:48:31 -0000 Received: from localhost (127.0.0.1) by engine19-1277-1.icritical.com with SMTP; 23 Oct 2008 13:48:31 -0000 Received: from engine19-1277-1.icritical.com ([127.0.0.1]) by localhost (engine19-1277-1.icritical.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 08575-09 for ; Thu, 23 Oct 2008 14:48:24 +0100 (BST) Received: (qmail 9127 invoked by uid 599); 23 Oct 2008 13:48:17 -0000 Received: from unknown (HELO exchangegw03.rl.ac.uk) (130.246.135.202) by engine19-1277-1.icritical.com (qpsmtpd/0.28) with ESMTP; Thu, 23 Oct 2008 14:48:17 +0100 Received: from exchange11.fed.cclrc.ac.uk ([172.16.133.11]) by exchangegw03.rl.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Oct 2008 14:47:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93515.D2B39556" Date: Thu, 23 Oct 2008 14:47:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scheduling groups Thread-Index: Ack1FdLnBUpzuKl3Q5Wiu86hWhE+Eg== From: "Emsley, I (Iain)" To: X-OriginalArrivalTime: 23 Oct 2008 13:47:00.0400 (UTC) FILETIME=[D2CCEB00:01C93515] X-Virus-Scanned: by iCritical at engine19-1277-1.icritical.com Subject: [ietf-caldav] Scheduling groups X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 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: Thu, 23 Oct 2008 13:49:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C93515.D2B39556 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 I've been working on the idea of scheduling groups within the Bedework calendar server for our mailing list service which is group-based in nature. I'm about to launch a test version of our implementation in the next couple of weeks but am aware that I'm at the very beginning of trying to satisfactorily bring about group scheduling.=20 =20 Our first steps towards a solution are to expand the allow the client to expand the group so that the client invites attendees. As user privacy is a concern, the client returns calendar_user addresses which we define in a database to anonymise the group member's addresses, although if a user enters an individual's email, we assume that they are inviting that person with a reason so the Uri will appear.=20 =20 Arnaud Quillam wrote: > In some other cases it might not be desirable, or even impossible to=20 > do so (case of a very large group). The invitation is still sent to=20 > individual members of the group, but those members will initially not=20 > appear as attendees (unless they were also specified explicitly in the > original PUT). =20 Our suggestion, which we are looking to implement, is to allow the user to expand the group in the interface but have a warning that if it is over a certain size, such as 1,000 members, that it will take a while or do they want to abort. This approach does, of course, have an issue if the list is over 1,000 members which some of ours are (albeit around 3% of lists) and one is over 100,000 members. At this stage, I have no clear idea as to how to deal with these size lists and would be grateful for any suggestions.=20 =20 I don't believe that we can break the group up after the event since that breaks the relationship between the organiser and attendee. On the other hand, if you allowed a group invite to go out to the individuals, how do you track responses, let alone counters? =20 A good point was raised in the idea that if an individual leaves a group, a cancellation needs to be issued from the organizer to remove the event from the calendar. This raises issues if that member has only left that group (for us a mailing list) but are interested in coming to the event which might be a conference or seminar and so they would not wish to see this deleted. Is there any way for linking an event to a private status if the event was dependent upon list membership? =20 I'm also about to experiment with creating an address book-style function for the user so that they are aware of which groups they can schedule to rather than do a look-up then block them from trying to schedule. It would be the most explicit way of defining available resources, although of course, the user should also be able to add in individual addresses as well. It might allow a finer grained control over the creation and deletion of group requests since in our current implementation, the user would have to hand delete each member rather than just delete a group.=20 =20 I'd be grateful for any thoughts or pointers on the issues raised.=20 =20 Thanks,=20 =20 Iain =20 Iain Emsley =20 Support Analyst JISCmail: www.jiscmail.ac.uk =20 =20 -- =0AScanned by iCritical.=0A ------_=_NextPart_001_01C93515.D2B39556 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve been working on the idea of scheduling = groups within the Bedework calendar server for our mailing list service which = is group-based in nature. I’m about to launch a test version of our = implementation in the next couple of weeks but am aware that I’m at the very = beginning of trying to satisfactorily bring about group scheduling. =

 

Our first steps towards a solution are to expand = the allow the client to expand the group so that the client invites attendees. As = user privacy is a concern, the client returns calendar_user addresses which = we define in a database to anonymise the group member’s addresses, = although if a user enters an individual’s email, we assume that they are = inviting that person with a reason so the Uri will appear.

 

Arnaud Quillam wrote:

> In some other cases it might not be = desirable, or even impossible to

> do so (case of a very large group). The = invitation is still sent to

> individual members of the group, but those = members will initially not

> appear as attendees (unless they were also = specified explicitly in the

> original PUT).

 

Our suggestion, which we are looking to implement, = is to allow the user to expand the group in the interface but have a warning = that if it is over a certain size, such as 1,000 members, that it will take a = while or do they want to abort. This approach does, of course, have an issue if = the list is over 1,000 members which some of ours are (albeit around 3% of lists) = and one is over 100,000 members. At this stage, I have no clear idea as to = how to deal with these size lists and would be grateful for any suggestions. =

 

I don’t believe that we can break the group = up after the event since that breaks the relationship between the organiser and attendee. On the other hand, if you allowed a group invite to go out to = the individuals, how do you track responses, let alone counters?

 

A good point was raised in the idea that if an = individual leaves a group, a cancellation needs to be issued from the organizer to = remove the event from the calendar. This raises issues if that member has only = left that group (for us a mailing list) but are interested in coming to the = event which might be a conference or seminar and so they would not wish to see = this deleted. Is there any way for linking an event to a private status if = the event was dependent upon list membership?

 

I’m also about to experiment with creating an = address book-style function for the user so that they are aware of which groups = they can schedule to rather than do a look-up then block them from trying to = schedule. It would be the most explicit way of defining available resources, = although of course, the user should also be able to add in individual addresses as = well. It might allow a finer grained control over the creation and deletion of = group requests since in our current implementation, the user would have to = hand delete each member rather than just delete a group.

 

I’d be grateful for any thoughts or pointers = on the issues raised.

 

Thanks,

 

Iain

 

Iain Emsley

 

Support Analyst

JISCmail: www.jiscmail.ac.uk

 


=

-- =0A
Scanned by iCritical.=0A


= ------_=_NextPart_001_01C93515.D2B39556-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 730F577D702 for ; Tue, 21 Oct 2008 08:14:51 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nazvM6X+3zG for ; Tue, 21 Oct 2008 08:14:49 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 0F91C77D6FE for ; Tue, 21 Oct 2008 08:14:48 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9LFEaAx024738 for ; Tue, 21 Oct 2008 15:14:47 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9300K01GT99F00@fe-emea-09.sun.com> (original mail from Arnaud.Quillaud@Sun.COM) for ietf-caldav@osafoundation.org; Tue, 21 Oct 2008 16:14:36 +0100 (BST) Received: from [192.168.0.60] ([82.227.203.159]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9300DJ0H09Q790@fe-emea-09.sun.com> for ietf-caldav@osafoundation.org; Tue, 21 Oct 2008 16:14:33 +0100 (BST) Date: Tue, 21 Oct 2008 17:14:33 +0200 From: Arnaud Quillaud Sender: Arnaud.Quillaud@Sun.COM To: ietf-caldav@osafoundation.org Message-id: <48FDF1D9.8020004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.17 (X11/20080925) Subject: [ietf-caldav] handling of groups X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.9 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, 21 Oct 2008 15:14:51 -0000 Reading the scheduling spec in the context of groups (server managed groups, e.g. LDAP groups) as this is a very much used feature in corporate environments. A client might create an event with an attendee such as: << ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP;SCHEDULE-AGENT=SERVER: mailto:groupA@example.com >> The end user expectation is that all members of the group "groupA@example.com" will receive a corresponding invitation. Nevertheless, there are several ways to handle such groups on the server side. In some cases, it might be desirable to have the server expand the group on each PUT: << ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP;SCHEDULE-AGENT=SERVER: mailto:groupA@example.com ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;SCHEDULE-AGENT=SERVER;MEMBER="groupA@example.com": mailto:joe@example.com ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;SCHEDULE-AGENT=SERVER;MEMBER="groupA@example.com": mailto:jane@example.com >> In some other cases it might not be desirable, or even impossible to do so (case of a very large group). The invitation is still sent to individual members of the group, but those members will initially not appear as attendees (unless they were also specified explicitly in the original PUT). A first question is: do we want to offer a way for clients to control that behavior, i.e.: * either "expand group into individual ATTENDEEs, then send invite to members". * or "don't expand group into ATTENDEEs but send invite to members". This could be controlled via an EXPAND (=true/false) ical param on the group's ATTENDEE property. The server may choose to not honor this attribute if the group is too large and reset it to false. In the case where the group is not expanded, we end up with an attendee's calendar resource where the owner is not listed explicitly as an ATTENDEE. iTIP describes the issue and gives some recommendations on how to handle it (http://tools.ietf.org/html/draft-ietf-calsify-2446bis-07#section-3.7.2). Nevertheless: 1) it might be really hard/impossible for the CUA to make the link between an ATTENDEE;CUTYPE=GROUP and the actual recipient. 2) Such calendar resource is in contradiction with the calsched definition of an attendee scheduling object resource: << A calendar object resource is considered to be a valid attendee scheduling object resource if the "ORGANIZER" iCalendar property is present and set in all the calendar components to the same value and doesn't match one of the calendar user addresses of the owner of the scheduling calendar collection, and that one of the "ATTENDEE" iCalendar property values match one of the calendar user addresses of the owner of the scheduling calendar collection. >> So shouldn't we mandate that in the case of an attendee's calendar resource received as the consequence of a group membership, that attendee should be added by the server in the attendee's copy (with the MEMBER param pointing back to the group)? Otherwise, we need to change the definition above. Finally, remains the question of group membership changes: an attendee might be a member of a group when a meeting is created and no longer a member when the meeting is updated. For example, groupA might have 2 members: joe@example.com and jane@example.com. A meeting is created with groupA as ATTENDEE. joe has accepted the meeting. Hence the organizer's calendar resource might look like: << ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP;SCHEDULE-AGENT=SERVER: mailto:groupA@example.com ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;SCHEDULE-AGENT=SERVER;MEMBER="groupA@example.com": mailto:joe@example.com >> If joe is removed from groupA and a modify (3.2.3.1.1.2. Modify) is done by the organizer with the attendee list above, joe should probably receive a CANCEL. So I think it would be worth mentioning the MEMBER attribute as having an impact on the modify behavior (e.g if an attendee (with SCHEDULE-AGENT=SERVER) has a MEMBER attribute pointing to a group but is no longer a member of that group, a CANCEL should be sent to the attendee and it should be removed from the attendee list by the server). It is a bit harder to send a CANCEL if the attendee (who is no longer a member) is not listed in the organizer's copy. Arnnaud Q