Subject: Re: [ietf-caldav] New CalDAV Resource website
From: Roberto Polli <[email-masked]>
To: [email-masked]
Date: Thu, 30 Oct 2008 22:34:54 +0100
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Alle giovedì 30 ottobre 2008, Cyrus Daboo ha scritto:
> <http://caldav.calconnect.org>
seen!

R.

-- 

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 
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene 
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio 
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto 
della legge in materia di protezione dei dati personali."

Date: Thu, 30 Oct 2008 08:38:00 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [ietf-caldav] An Invitation to Meet CalConnect in Europe in November
Reply-To: [email-masked]

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 · [email-masked] 
<mailto:[email-masked]>

--------------080403010603000905070901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Folks,<br>
<br>
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.&nbsp; <br>
<br>
The event will be held the afternoons of Friday November 7th in Prague,
Czech Republic, and Monday November 10th in London, England.&nbsp; Each
event is scheduled for 1300-1600 and will be preceded by a light lunch
and followed by a reception.<br>
<br>
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.<br>
<br>
Complete details on the event, including locations, logistics, and a
link to the registration form, is at <a
 href="http://www.calconnect.org/meetcalconnect.shtml">http://www.calconnect.org/meetcalconnect.shtml</a>.&nbsp;
<br>
<br>
Best Regards,<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------080403010603000905070901--

Date: Thu, 30 Oct 2008 10:53:59 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [ietf-caldav] New CalDAV Resource website

Hi folks,
I am pleased to say we have a new CalDAV Resource website:

<http://caldav.calconnect.org>

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

From: Andrew McMillan <[email-masked]>
To: [email-masked]
Date: Thu, 30 Oct 2008 16:34:42 +1300
Subject: [ietf-caldav] Response when free/busy information is unavailable

--=-+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:

<schedule-response xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
 <C:response>
  <C:recipient>
   <href>mailto:[email-masked]</href>
  </C:recipient>
  <C:request-status>3.7;Invalid Calendar User</C:request-status>
  <C:calendar-data/>
 </C:response>
</schedule-response>

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:

<schedule-response xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
 <C:response>
  <C:recipient>
   <href>mailto:[email-masked]</href>
  </C:recipient>
  <C:request-status>3.8;No authority</C:request-status>
  <C:calendar-data/>
 </C:response>
</schedule-response>

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

--=-+cgFmzitbTUtFXt8km9c--

Content-class: urn:content-classes:message
Date: Thu, 23 Oct 2008 14:47:00 +0100
From: "Emsley, I (Iain)" <[email-masked]>
To: <[email-masked]>
Subject: [ietf-caldav] Scheduling groups

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, 

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 <http://www.jiscmail.ac.uk> 

-- 
Scanned by iCritical.

------_=_NextPart_001_01C93515.D2B39556
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-GB link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal>Hi, <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>I&#8217;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&#8217;m about to launch a test version of our implementation
in the next couple of weeks but am aware that I&#8217;m at the very beginning
of trying to satisfactorily bring about group scheduling. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>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&#8217;s addresses, although
if a user enters an individual&#8217;s email, we assume that they are inviting
that person with a reason so the Uri will appear. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Arnaud Quillam wrote:<o:p></o:p></p>

<p class=MsoPlainText>&gt; In some other cases it might not be desirable, or
even impossible to <o:p></o:p></p>

<p class=MsoPlainText>&gt; do so (case of a very large group). The invitation
is still sent to <o:p></o:p></p>

<p class=MsoPlainText>&gt; individual members of the group, but those members
will initially not <o:p></o:p></p>

<p class=MsoPlainText>&gt; appear as attendees (unless they were also specified
explicitly in the <o:p></o:p></p>

<p class=MsoNormal>&gt; original PUT).<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>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. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>I don&#8217;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?<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>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?<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>I&#8217;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. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>I&#8217;d be grateful for any thoughts or pointers on the
issues raised. <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Thanks, <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Iain<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Iain
Emsley</span><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'>&nbsp;<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Support
Analyst</span><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>JISCmail:
<a href="http://www.jiscmail.ac.uk"><span style='color:blue'>www.jiscmail.ac.uk</span></a></span><span
style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'>&nbsp;</span><o:p></o:p></p>

</div>

<br><p>-- 
<BR>Scanned by iCritical.
</p>
<br></body>

</html>

------_=_NextPart_001_01C93515.D2B39556--

Date: Tue, 21 Oct 2008 17:14:33 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [ietf-caldav] handling of groups

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:[email-masked]

 >>

The end user expectation is that all members of the group 
"[email-masked]" 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:[email-masked]
        ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;SCHEDULE-AGENT=SERVER;MEMBER="[email-masked]":
         mailto:[email-masked]
        ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;SCHEDULE-AGENT=SERVER;MEMBER="[email-masked]":
         mailto:[email-masked]

 >>

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: [email-masked] and [email-masked]. 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:[email-masked]
        ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL;PARTSTAT¬CEPTED;SCHEDULE-AGENT=SERVER;MEMBER="[email-masked]":
         mailto:[email-masked]

 >>

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