Subject: Re: [Ietf-caldav] Query By UID Without knowing Component Type
From: Bernard Desruisseaux <[email-masked]>
To: Bobby Rullo <[email-masked]>
Cc: CalDAV DevList <[email-masked]>
Date: Mon, 30 Jul 2007 10:13:39 -0400
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

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 -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

To: CalDAV DevList <[email-masked]>
From: Bobby Rullo <[email-masked]>
Date: Thu, 26 Jul 2007 17:38:55 -0700
Subject: [Ietf-caldav] Query By UID Without knowing Component Type

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 

Date: Tue, 17 Jul 2007 18:49:44 +0200
From: Julian Reschke <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Subject: Re: [Ietf-caldav] MKCOL versus MKCALENDAR and status code
Cc: [email-masked]

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 
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.6.3>.

> 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

Content-return: prohibited
Date: Tue, 17 Jul 2007 18:41:41 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-caldav] MKCOL versus MKCALENDAR and status code

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

Date: Mon, 16 Jul 2007 10:01:10 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Julian Reschke <[email-masked]>
Subject: Re: [Ietf-caldav] RFC4791 erratum wrt to condition name
Cc: CalDAV DevList <[email-masked]>

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,
> 
> <http://greenbytes.de/tech/webdav/rfc4791.html#rfc.section.5.3.1> 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 
> (<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>).
> 
> Best regards, Julian
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> 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

Date: Sat, 14 Jul 2007 18:55:45 +0200
From: Julian Reschke <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] RFC4791 erratum wrt to condition name

Hi,

<http://greenbytes.de/tech/webdav/rfc4791.html#rfc.section.5.3.1> 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 
(<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>).

Best regards, Julian

Date: Fri, 13 Jul 2007 15:57:18 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-ietf-calsify-rfc2445bis-07.txt]

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

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

--------------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
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------040002010104060109090008--

Date: Wed, 11 Jul 2007 13:29:01 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>, ietf-calsify list <[email-masked]>, ietf-calendar list <[email-masked]>
Subject: [Ietf-caldav] CalDAV Scheduling Requirements paper published by CalConnect
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------090303050507070509070308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

<http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf>/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 · [email-masked] 
<mailto:[email-masked]>

--------------090303050507070509070308
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">
<a
 href="http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf"></a><i>CalDAV
Scheduling Requirements V1.1</i> 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].&nbsp;&nbsp; The document is at <a
 href="http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf">http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf</a>.<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>

--------------090303050507070509070308--

Content-return: prohibited
Date: Wed, 11 Jul 2007 12:15:38 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-caldav] authorization identity
Sender: [email-masked]
To: Cyrus Daboo <[email-masked]>, [email-masked]

I was talking about the "sudo" user.

Thanks.

Arnaud

> -----Message d'origine-----
> De : Cyrus Daboo [mailto:[email-masked]]=20
> Envoy=E9 : samedi 7 juillet 2007 16:47
> =C0 : Arnaud Quillaud; [email-masked]
> Objet : Re: [Ietf-caldav] authorization identity
>=20
>=20
> Hi Arnaud,
>=20
> --On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud=20
> <[email-masked]> 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

From: "Tim Hare" <[email-masked]>
To: "'CalDAV DevList'" <[email-masked]>
Subject: RE: [Ietf-caldav] authorization identity
Date: Sat, 7 Jul 2007 11:09:25 -0400

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Saturday, July 07, 2007 10:47 AM
To: Arnaud Quillaud; [email-masked]
Subject: Re: [Ietf-caldav] authorization identity

Hi Arnaud,

--On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud <[email-masked]>
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 -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Sat, 07 Jul 2007 10:46:38 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnaud Quillaud <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] authorization identity

Hi Arnaud,

--On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud 
<[email-masked]> 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

Content-return: prohibited
Date: Sat, 07 Jul 2007 16:19:35 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-caldav] authorization identity

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

Date: Fri, 06 Jul 2007 18:33:25 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calendar list <[email-masked]>, ietf-calsify list <[email-masked]>, ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] My apologies for multiple CalConnect-related postings
Reply-To: [email-masked]

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

--------------030804020304020806040400
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">
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.<br>
<br>
And to make it worse, many people are subscribed to two or more of
them, and thus got an unnecessary flood of repeats.<br>
<br>
I apologize for the mistake, however it occurred, and will do my best
to not do it again.&nbsp; I hope that the irritant didn't overcome the
messages!<br>
<br>
Apologies again,<br>
<br>
Dave Thewlis<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>

--------------030804020304020806040400--

Date: Fri, 06 Jul 2007 10:16:36 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts
Reply-To: [email-masked]

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 <http://www.calconnect.org/vcardreg.shtml> and 
logistics <http://www.calconnect.org/vcardworkshoplogistics.shtml> 
pages, a general discussion list 
<http://www.calconnect.org/vcardworkshoplist.shtml> about the workshop, 
and a questionnaire <http://www.calconnect.org/vcardquestionnaire.shtml> 
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 <http://www.calconnect.org/roundtable10.shtml> 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 
<http://www.calconnect.org/vcardquestionnaire.shtml>, 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 · [email-masked] 
<mailto:[email-masked]>

--------------070605060307080506020202
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">
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 <u>open</u> to vendors,
customers, CalConnect members and non-members alike. There is no fee,
but you <u>must</u> register in advance and numbers are limited.
Please see <br>
<a href="http://www.calconnect.org/vcardworkshop.shtml">http://www.calconnect.org/vcardworkshop.shtml</a>
for more information and links to the <a
 href="http://www.calconnect.org/vcardreg.shtml">registration</a> and <a
 href="http://www.calconnect.org/vcardworkshoplogistics.shtml">logistics</a>
pages, a general <a
 href="http://www.calconnect.org/vcardworkshoplist.shtml">discussion
list</a> about the workshop, and a <a
 href="http://www.calconnect.org/vcardquestionnaire.shtml">questionnaire</a>
to give us more guidance to make the workshop as productive as possible.<br>
<br>
>From the workshop introduction page:<br>
<br>
<font color="#330099"><small>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 &amp; 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.<br>
<br>
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.<br>
<br>
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.</small></font><br>
<br>
<br>
If you are not a CalConnect member, this is also an opportunity to stay
on for <a href="http://www.calconnect.org/roundtable10.shtml">Roundtable
X</a> as an observer, and we'd be delighted to have you; you will have
to register separately for the Roundtable.&nbsp; <br>
<br>
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 <a
 href="http://www.calconnect.org/vcardquestionnaire.shtml">questionnaire</a>,
as this will help provide the workshop participants with guidance as to
the directions any progression on vCard should take.<br>
<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>

--------------070605060307080506020202--

Date: Fri, 06 Jul 2007 09:48:58 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Announcing CalConnect Roundtable X and Interoperability Test Event -September 17-21, Cambridge, Massachusetts
Reply-To: [email-masked]

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<b>The Calendaring and Scheduling Consortium announces Roundtable X
and&nbsp; IOP Test Event<br>
<br>
</b>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.&nbsp;
Registration is now open for the Roundtable and/or the IOP test event.&nbsp;
Logistics and registration information may be found at <a
 href="http://www.calconnect.org/roundtable10.shtml">http://www.calconnect.org/roundtable10.shtml</a>
<a href="http://www.calconnect.org/roundtable10.shtml"></a>and at <a
 href="http://www.calconnect.org/iopseptember2007.shtml">http://www.calconnect.org/iopseptember2007.shtml</a><br>
<br>
General schedule:&nbsp; The IOP test will begin at noon Monday and run
through noon Wednesday.&nbsp; The Roundtable will begin at lunch on
Wednesday and run through lunch on Friday.&nbsp; We plan to offer optional
practicums on the iCalendar RFCs (iCalendar/iTIP/iMIP) and on CalDAV on
Wednesday morning prior to lunch.&nbsp; <br>
<br>
The IOP test event will involve both CalDAV and regular iCalendar, iMIP
and iTIP interoperability testing scenarios.&nbsp; In addition, plans and
preliminary work for a Mobile Calendar IOP Test Event, and the
scenarios associated with that event, will be covered.<br>
<br>
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.&nbsp; Time
is also set aside for BOFs either scheduled in advance, or impromptu at
the meeting.<br>
<br>
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 <a
 href="http://www.calconnect.org/observer.shtml">http://www.calconnect.org/observer.shtml</a>
for more information.<br>
<br>
Both members and non-members may participate in the IOP test events.<br>
<br>
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.<br>
<br>
For more information, please call or e-mail me as below.<br>
<br>
See you in Cambridge!<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>

--------------020900090202010405060108--