headers
Dave Thewlis | 6 Jul 2007 18:48
Favicon

Announcing CalConnect Roundtable X and Interoperability Test Event -September 17-21, Cambridge, Massachusetts

The Calendaring and Scheduling Consortium announces Roundtable X and  IOP Test Event

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

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

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

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

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

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

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

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

See you in Cambridge!

Dave Thewlis

--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis <at> calconnect.org 
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 0 comments |
headers
Dave Thewlis | 6 Jul 2007 19:16
Favicon

CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts

CalConnect invites you to a a one-day open workshop on vCard and what should be done about it on Tuesday, September 18, 2007, at M.I.T. in Cambridge, Massachusetts. This event is open to vendors, customers, CalConnect members and non-members alike. There is no fee, but you must register in advance and numbers are limited. Please see
http://www.calconnect.org/vcardworkshop.shtml for more information and links to the registration and logistics pages, a general discussion list about the workshop, and a questionnaire to give us more guidance to make the workshop as productive as possible.

>From the workshop introduction page:

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

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

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


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

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


--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis <at> calconnect.org 
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 0 comments |
headers
Dave Thewlis | 7 Jul 2007 03:33
Favicon

My apologies for multiple CalConnect-related postings

I seem to have screwed up somehow and posted our announcement of the vCard workshop and possibly the next Roundtable multiple times to at least one of these lists.

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

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

Apologies again,

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis <at> calconnect.org 
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 0 comments |
headers
Arnaud Quillaud | 7 Jul 2007 16:19
Picon

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

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 3 comments |
headers
Cyrus Daboo | 7 Jul 2007 16:46
Favicon

Re: authorization identity

Hi Arnaud,

--On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud 
<Arnaud.Quillaud <at> Sun.COM> wrote:

> For connection oriented protocols, SASL defines the notion of
> authorization identity
> (http://tools.ietf.org/html/rfc4422#section-3.4.1).  This allows to
> authenticate as one user and then "switch identity" to act as another
> user for all following operations (of course assuming that the
> authenticated user has the right to act on behalf of the other user).
>
> HTTP and HTTP Basic authentication (http://tools.ietf.org/html/rfc2617)
> which is more or less the only auth mechanism supported by CalDAV do not
> seem to include such functionality.
>
> Is the functionality actually defined somewhere else or is it missing
> from HTTP/WebDAV/CalDAV ? Is any CalDAV client/server using proprietary
> mechanism (e.g. simple http header) to achieve the same result ?

It is missing. In the Apple CalendarServer we have a private header that 
does this. We maintain a special list of "sudo" users - those are users who 
can authenticate using HTTP but then authorize as someone else by including 
the special header. I think any revisions to or new mechanisms for HTTP 
auth should include an authorization identity facility.

BTW Do you want to use this facility to support calendar user proxying - 
i.e. one user acting on behalf of another? If so, there is an alternative 
approach to that that we also implemented and which has been presented to 
Calconnect to move forward with standarizing. Our approach for that is to 
use ACLs - basically the server has two group principals per "primary" 
principal. Members of those groups are proxy users for the corresponding 
primary principal. The server automatically provisions privileges on each 
user's account such that these proxy groups have the appropriate privileges 
(one group only has read access, the other group additionally has write and 
scheduling access). This approach allows a calendar client to control proxy 
user access by simply adding/removing users on the relevant proxy group 
principals.

There are several benefits to this over the authorization identity approach 
- not least is the ability to disable access on specific resources via 
ACLs. i.e. there are times when you don't want a proxy to see events - ones 
that might relate directly to them or others etc. This approach allows 
that, whereas an authorization identity will not.

Calconnect is working on a more generalized concept based on this, that 
would allow definition of arbitrary "roles" (two of which map to the proxy 
groups we have). Hopefully we will be submitting something to the IETF soon 
for standardization.

--

-- 
Cyrus Daboo

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 2 comments |
headers
Tim Hare | 7 Jul 2007 17:09
Picon

RE: authorization identity

Not to bring my mainframe background into this, but...

Most mainframe security products protect a resource by a profile, to which
users _or_ groups may be granted appropriate access. The advantage of using
groups is that the group can remain in the access list, but someone granted
authority can manage the contents of the group, without being the
owning/controlling administrator of the resource. For example:  I, as system
administrator, may own a set of conference rooms. I can grant scheduling
access to SchedGroup A and SchedGroup B, and allow Manager A and Manager B
to control who within their organization is a member of those groups. This
works well for both parties: if I feel Group B is abusing their privilege
(or for some other reason) I can revoke SchedGroup B's access without
knowing who is in SchedGroupB; the manager can handle staff turnover, or
changes of duties, by determining who he connects to SchedGroupB.

I think the ACL mechanisms work better than allowing 'sudo' switching; and
since things are always occurring in one user's security context, there's no
doubts when debugging or auditing as there would be otherwise. Think of the
case where the sudo doesn't work correctly, some updates in a transaction
get done under the special ID, others under the 'sudo'  ID; this could be
due to program bugs or to multiprocessing environments gone wrong, but it
still adds to the problem of figuring out who actually updated the calendar.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: ietf-caldav-bounces <at> osafoundation.org
[mailto:ietf-caldav-bounces <at> osafoundation.org] On Behalf Of Cyrus Daboo
Sent: Saturday, July 07, 2007 10:47 AM
To: Arnaud Quillaud; ietf-caldav <at> osafoundation.org
Subject: Re: [Ietf-caldav] authorization identity

Hi Arnaud,

--On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud <Arnaud.Quillaud <at> Sun.COM>
wrote:

> For connection oriented protocols, SASL defines the notion of 
> authorization identity 
> (http://tools.ietf.org/html/rfc4422#section-3.4.1).  This allows to 
> authenticate as one user and then "switch identity" to act as another 
> user for all following operations (of course assuming that the 
> authenticated user has the right to act on behalf of the other user).
>
> HTTP and HTTP Basic authentication 
> (http://tools.ietf.org/html/rfc2617)
> which is more or less the only auth mechanism supported by CalDAV do 
> not seem to include such functionality.
>
> Is the functionality actually defined somewhere else or is it missing 
> from HTTP/WebDAV/CalDAV ? Is any CalDAV client/server using 
> proprietary mechanism (e.g. simple http header) to achieve the same result
?

It is missing. In the Apple CalendarServer we have a private header that
does this. We maintain a special list of "sudo" users - those are users who
can authenticate using HTTP but then authorize as someone else by including
the special header. I think any revisions to or new mechanisms for HTTP auth
should include an authorization identity facility.

BTW Do you want to use this facility to support calendar user proxying -
i.e. one user acting on behalf of another? If so, there is an alternative
approach to that that we also implemented and which has been presented to
Calconnect to move forward with standarizing. Our approach for that is to
use ACLs - basically the server has two group principals per "primary" 
principal. Members of those groups are proxy users for the corresponding
primary principal. The server automatically provisions privileges on each
user's account such that these proxy groups have the appropriate privileges
(one group only has read access, the other group additionally has write and
scheduling access). This approach allows a calendar client to control proxy
user access by simply adding/removing users on the relevant proxy group
principals.

There are several benefits to this over the authorization identity approach
- not least is the ability to disable access on specific resources via ACLs.
i.e. there are times when you don't want a proxy to see events - ones that
might relate directly to them or others etc. This approach allows that,
whereas an authorization identity will not.

Calconnect is working on a more generalized concept based on this, that
would allow definition of arbitrary "roles" (two of which map to the proxy
groups we have). Hopefully we will be submitting something to the IETF soon
for standardization.

--
Cyrus Daboo

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 0 comments |
headers
Arnaud Quillaud | 11 Jul 2007 12:15
Picon

RE : authorization identity

I was talking about the "sudo" user.

Thanks.

Arnaud

> -----Message d'origine-----
> De : Cyrus Daboo [mailto:cyrus <at> daboo.name] 
> Envoyé : samedi 7 juillet 2007 16:47
> À : Arnaud Quillaud; ietf-caldav <at> osafoundation.org
> Objet : Re: [Ietf-caldav] authorization identity
> 
> 
> Hi Arnaud,
> 
> --On July 7, 2007 4:19:35 PM +0200 Arnaud Quillaud 
> <Arnaud.Quillaud <at> Sun.COM> wrote:
> 
> > For connection oriented protocols, SASL defines the notion of 
> > authorization identity 
> > (http://tools.ietf.org/html/rfc4422#section-3.4.1).  This allows to 
> > authenticate as one user and then "switch identity" to act 
> as another 
> > user for all following operations (of course assuming that the 
> > authenticated user has the right to act on behalf of the 
> other user).
> >
> > HTTP and HTTP Basic authentication 
> > (http://tools.ietf.org/html/rfc2617)
> > which is more or less the only auth mechanism supported by 
> CalDAV do not
> > seem to include such functionality.
> >
> > Is the functionality actually defined somewhere else or is 
> it missing 
> > from HTTP/WebDAV/CalDAV ? Is any CalDAV client/server using 
> > proprietary mechanism (e.g. simple http header) to achieve the same 
> > result ?
> 
> It is missing. In the Apple CalendarServer we have a private 
> header that 
> does this. We maintain a special list of "sudo" users - those 
> are users who 
> can authenticate using HTTP but then authorize as someone 
> else by including 
> the special header. I think any revisions to or new 
> mechanisms for HTTP 
> auth should include an authorization identity facility.
> 
> BTW Do you want to use this facility to support calendar user 
> proxying - 
> i.e. one user acting on behalf of another? If so, there is an 
> alternative 
> approach to that that we also implemented and which has been 
> presented to 
> Calconnect to move forward with standarizing. Our approach 
> for that is to 
> use ACLs - basically the server has two group principals per 
> "primary" 
> principal. Members of those groups are proxy users for the 
> corresponding 
> primary principal. The server automatically provisions 
> privileges on each 
> user's account such that these proxy groups have the 
> appropriate privileges 
> (one group only has read access, the other group additionally 
> has write and 
> scheduling access). This approach allows a calendar client to 
> control proxy 
> user access by simply adding/removing users on the relevant 
> proxy group 
> principals.
> 
> There are several benefits to this over the authorization 
> identity approach 
> - not least is the ability to disable access on specific 
> resources via 
> ACLs. i.e. there are times when you don't want a proxy to see 
> events - ones 
> that might relate directly to them or others etc. This 
> approach allows 
> that, whereas an authorization identity will not.
> 
> Calconnect is working on a more generalized concept based on 
> this, that 
> would allow definition of arbitrary "roles" (two of which map 
> to the proxy 
> groups we have). Hopefully we will be submitting something to 
> the IETF soon 
> for standardization.
> 
> 
> 
> -- 
> Cyrus Daboo
> 
> 

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 0 comments |
headers
Dave Thewlis | 11 Jul 2007 22:29
Favicon

CalDAV Scheduling Requirements paper published by CalConnect

CalDAV Scheduling Requirements V1.1 has been published by the CalDAV Technical Committee of the Calendaring and Scheduling Consortium. It presents a list of features in the form of requirements for the scheduling extensions to CalDAV [RFC 4791], that is, the extensions to the Web Distributed Authoring and Versioning (WebDAV) [RFC 2518] protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC 2446].   The document is at http://www.calconnect.org/publications/caldavschedulingrequirementsv1.1.pdf.
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis <at> calconnect.org 
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 0 comments |
headers
Bernard Desruisseaux | 13 Jul 2007 21:57
Picon
Favicon

[Fwd: I-D ACTION:draft-ietf-calsify-rfc2445bis-07.txt]

The Calsify WG Chairs have issued a Working Group Last Call on
draft-ietf-calsify-rfc2445bis-07.txt (i.e., the revision of
iCalendar).  See:

http://lists.osafoundation.org/pipermail/ietf-calsify/2007-July/001762.html

People interested to know exactly what was changed in RFC 2445
can look at the following annotated version of the draft:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-07.changes.html

Please send your comments to the ietf-calsify <at> osafoundation.org
mailing list before August 10th, 2007.

Cheers,
Bernard

-------- Original Message --------
Subject: I-D ACTION:draft-ietf-calsify-rfc2445bis-07.txt
Date: Mon, 09 Jul 2007 17:15:01 -0400
From: Internet-Drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org
CC: ietf-calsify <at> osafoundation.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Calendaring and Scheduling Standards 
Simplification Working Group of the IETF.

	Title		: Internet Calendaring and Scheduling Core Object Specification 
(iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-07.txt
	Pages		: 177
	Date		: 2007-7-9
	
This document defines the iCalendar data format for representing and
    exchanging calendaring and scheduling information such as events, to-
    dos, journal entries and free/busy information, independent of any
    particular calendar service or protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-07.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-calsify-rfc2445bis-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-calsify-rfc2445bis-07.txt): message/external-body, 69 bytes
_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce


_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 0 comments |
headers
Julian Reschke | 14 Jul 2007 18:55
Picon
Picon

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
_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 1 comment |

Gmane