From owner-ietf-calendar Wed Jul 24 11:45:17 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA22932 for ietf-calendar-bks; Wed, 24 Jul 1996 11:45:17 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.3) with ESMTP id LAA22927 for ; Wed, 24 Jul 1996 11:45:16 -0700 (PDT) Received: from [204.179.128.160] (mg128-136.ricochet.net [204.179.128.136]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id LAA23522 for ; Wed, 24 Jul 1996 11:56:21 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 1996 11:49:02 -0700 To: ietf-calendar@imc.org From: Dave Crocker Subject: Let the scheduling of the games begin Sender: owner-ietf-calendar@imc.org Precedence: bulk The ietf-calendar@imc.org list is now active. I will bring over the existing subscriptions from the cst.ca list as soon as I can. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-calendar Wed Jul 24 12:14:08 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA23053 for ietf-calendar-bks; Wed, 24 Jul 1996 12:14:08 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mail.ico.net (psycho.ico.net [204.94.129.66]) by imc.org (8.7.4/8.7.3) with SMTP id MAA23048 for ; Wed, 24 Jul 1996 12:14:06 -0700 (PDT) Received: from philippe.philippe.com by mail.ico.net with SMTP (5.65/950621.1) id AA06359; Wed, 24 Jul 96 12:17:59 -0700 Message-Id: <2.2.32.19960724191753.006bde58@mail.ico.com> X-Sender: phil0001@mail.ico.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 1996 09:17:53 -1000 To: Dave Crocker From: Philippe Kahn Subject: Re: Let the scheduling of the games begin Cc: ietf-calendar@imc.org Sender: owner-ietf-calendar@imc.org Precedence: bulk Dave, with all this confusion etc... how can we make sure that we are on the list etc...? At 11:49 AM 7/24/96 -0700, Dave Crocker wrote: >The ietf-calendar@imc.org list is now active. I will bring over the >existing subscriptions from the cst.ca list as soon as I can. > >d/ > >-------------------- >Dave Crocker +1 408 246 8253 >Brandenburg Consulting fax: +1 408 249 6205 >675 Spruce Dr. dcrocker@brandenburg.com >Sunnyvale CA 94086 USA http://www.brandenburg.com > >Internet Mail Consortium http://www.imc.org, info@imc.org > > > Philippe Kahn Starfish Software, Inc. philippe@philippe.com http://www.starfishsoftware.com Voice: 408-461-5855 Fax: 408-461-5955 Pager: 1-800-841-9668 AOL: philippe From owner-ietf-calendar Wed Jul 24 14:39:42 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id OAA23821 for ietf-calendar-bks; Wed, 24 Jul 1996 14:39:42 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.3) with ESMTP id OAA23816 for ; Wed, 24 Jul 1996 14:39:40 -0700 (PDT) Received: from [205.214.160.94] (d60.netgate.net [205.214.160.94]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id OAA01332; Wed, 24 Jul 1996 14:50:44 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <2.2.32.19960724191753.006bde58@mail.ico.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 24 Jul 1996 14:41:35 -0700 To: Philippe Kahn From: Dave Crocker Subject: Re: Let the scheduling of the games begin Cc: ietf-calendar@imc.org Sender: owner-ietf-calendar@imc.org Precedence: bulk Philippe, At 12:17 PM -0700 7/24/96, Philippe Kahn wrote: >with all this confusion etc... how can we make sure that we are on the list >etc...? If you got the announcement (as YOU did) then you are already on the list. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-calendar Thu Jul 25 07:38:06 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id HAA29746 for ietf-calendar-bks; Thu, 25 Jul 1996 07:38:06 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.3) with ESMTP id HAA29741 for ; Thu, 25 Jul 1996 07:38:05 -0700 (PDT) Received: from [205.214.160.73] (d46.netgate.net [205.214.160.80]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id HAA16530 for ; Thu, 25 Jul 1996 07:49:23 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Jul 1996 07:41:53 -0700 To: ietf-calendar@imc.org From: Dave Crocker Subject: Full list transferred from cst.ca Sender: owner-ietf-calendar@imc.org Precedence: bulk All of who joined the cst.ca list are now on the imc.org list. Welcome aboard! You should be able to continue the dialogue using ietf-calendar@imc.org. I'm still working on getting a copy of the archive from cst.ca and still working on setting up a separate address for posting archival documents. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-calendar Thu Jul 25 08:46:32 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA00434 for ietf-calendar-bks; Thu, 25 Jul 1996 08:46:32 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.3) with ESMTP id IAA00429 for ; Thu, 25 Jul 1996 08:46:30 -0700 (PDT) Received: from [205.214.160.102] (d66.netgate.net [205.214.160.102]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id IAA18820 for ; Thu, 25 Jul 1996 08:57:48 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Jul 1996 08:50:20 -0700 To: ietf-calendar@imc.org From: Dave Crocker Subject: document archive: ietf-calendar-doc@imc.org, etc. Sender: owner-ietf-calendar@imc.org Precedence: bulk At the meeting yesterday, I said I'd try to set up a parallel mailing address, for posting documents. The address now exists. It is: Send mail to this address to cause it to be posted to the web page It will NOT be mailed out to others. It will only be posted to the web archive. I've posted some documents, by way of demonstrations. As you will see, the current mechanism does not process anything but straight ascii text. I posted a powerpoint document and it is there in its full MIME bin64 Content-transfer-encoding. It's possible to get it and turn it into processable powerpoint data, but only with separate software. Hence, for now, I think folks should only post ascii data. Also, I've now listed the ietf-calendar activity on the home page. Please note that the address info@imc.org is a way of obtaining files and data via email. To find out more, send a message to the address and put the word help into the body. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-calendar Thu Jul 25 09:48:23 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA00753 for ietf-calendar-bks; Thu, 25 Jul 1996 09:48:23 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from on.on.com (on.on.com [207.18.216.2]) by imc.org (8.7.4/8.7.3) with ESMTP id JAA00748 for ; Thu, 25 Jul 1996 09:48:08 -0700 (PDT) Received: from dev.on.com (dev.on.com [207.18.216.16]) by on.on.com (8.7.5/ON-1) with ESMTP id MAA29610 for ; Thu, 25 Jul 1996 12:48:16 -0400 (EDT) Received: from IP_TUNNEL/SpoolDir by dev.on.com (DaVinci Version: 4.11); 25 Jul 96 13:02:45 -0500 Received: from SpoolDir by IP_TUNNEL (DaVinci Version: 4.11); 25 Jul 96 13:02:31 -0500 X-DVS-Message-Class: 1 From: Jay Batson To: ietf-calendar Subject: Not that I don't trust Dave, but ... "This is a test" ... Date: 25 Jul 1996 12:51:09 -0400 X-DVS-Mail-Trail: Originated by: Jay Batson on 7/25/96 12:51PM X-Mailer: DaVinci SMTP 4.11 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <838309869@dev.on.com> X-DVS-Conversation-ID: 838309869@dev.on.com Sender: owner-ietf-calendar@imc.org Precedence: bulk ... just to see if this list actually works.... ;-) I thought we had a great meeting yesterday. I'm fairly proud of us for how well behaved we all were. On the other hand, we didn't actually get anywhere *near* the real fun.... Cheers -jb Jay Batson jbatson@on.com From owner-ietf-calendar Thu Jul 25 10:23:32 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA00920 for ietf-calendar-bks; Thu, 25 Jul 1996 10:23:32 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by imc.org (8.7.4/8.7.3) with SMTP id KAA00915 for ; Thu, 25 Jul 1996 10:23:31 -0700 (PDT) Received: from poleary.vip.best.com (poleary.vip.best.com [206.86.235.98]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id KAA27506 for ; Thu, 25 Jul 1996 10:27:36 -0700 Message-ID: <31F7AF4E.57AD@clearblue.com> Date: Thu, 25 Jul 1996 10:30:54 -0700 From: "Peter O'Leary" Reply-To: poleary@clearblue.com Organization: Clear Blue Network Systems, Inc. X-Mailer: Mozilla 3.0b4 (Win95; I) MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Pointer to ICAP and thanks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Everyone, Thanks for a very productive session yesterday. Everyone should feel proud that we're off to such a promising start. The ICAP spec is definately up on Internet-Drafts for those that might have missed it. I will make HTML and DOC version available shortly. http://ds1.internic.net/internet-drafts/draft-oleary-icap-00.txt Thanks again, Pete. From owner-ietf-calendar Fri Jul 26 08:33:20 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA07654 for ietf-calendar-bks; Fri, 26 Jul 1996 08:33:20 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from shrimp.fishy.net (fluke.fishy.net [206.156.56.33]) by imc.org (8.7.4/8.7.3) with ESMTP id IAA07649 for ; Fri, 26 Jul 1996 08:33:17 -0700 (PDT) Received: from taj (cobia.fishy.net [172.16.3.30]) by shrimp.fishy.net (8.7.5/8.7.3) with SMTP id LAA64012 for ; Fri, 26 Jul 1996 11:32:55 -0400 Message-ID: <31F8ADDC.A6C@staff.prodigy.net> Date: Fri, 26 Jul 1996 11:37:00 +0000 From: Arathi Balakrishna X-Mailer: Mozilla 3.0b5aGold (WinNT; I) MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: access control Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk After reviewing the calendar specs, there are a few questions that came up: 1. How do you plan to convey user access control from client to server at the calendar level? 2.It would be nice to have links to other calendar events on a user's personal calendar. Has it been given any thought? regards, Arathi (arathib@staff.prodigy.com) From owner-ietf-calendar Fri Jul 26 09:24:17 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA07879 for ietf-calendar-bks; Fri, 26 Jul 1996 09:24:17 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by imc.org (8.7.4/8.7.3) with ESMTP id JAA07874 for ; Fri, 26 Jul 1996 09:24:15 -0700 (PDT) Received: from eng.mcom.com (h-207-1-142-202.mcom.com [207.1.142.202]) by netscape.com (8.7.5/8.7.3) with SMTP id JAA16589; Fri, 26 Jul 1996 09:27:13 -0700 (PDT) Message-ID: <31F8F1B1.4897@netscape.com> Date: Fri, 26 Jul 1996 09:26:25 -0700 From: David Mease Reply-To: dmease@netscape.com Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.0b6Gold (Win95; U) MIME-Version: 1.0 To: Arathi Balakrishna CC: ietf-calendar@imc.org Subject: Re: access control References: <31F8ADDC.A6C@staff.prodigy.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Arathi Balakrishna wrote: > 2.It would be nice to have links to other calendar events on a user's > personal calendar. Has it been given any thought? You are talking about the concept of event lists. Event lists are not calendars, but simply lists of events typically related in some way e.g. Holidays, Company events. Using event lists the user can bring events into her calendar which are not necessarily appointments, but just events to be aware of. Event lists provide a mechanism for people or companies to publish lists of their events to the world and allow individual users to bring those events into their personal calendars. For example, the SF Giants could publish a list of their baseball games. If a user added this event list to their calendar, the baseball game schedule would show up in their calendar and maybe they could select specific games to be notified on, but most of the games would just be place holders for viewing purposes only. In the intranet world, companies could publish event lists for company events, etc. which would show up on all employee personal calendars. This is a very powerful feature and something we should definitely include in our investigation. -- Dave -------------------------------------------------------------------- David Mease Netscape Communications Corp. Email: dmease@netscape.com 685 East Middlefield Rd Phone: 415-937-4410 Mountain View, CA 94043 Fax: 415-528-4122 -------------------------------------------------------------------- From owner-ietf-calendar Fri Jul 26 12:41:15 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA08678 for ietf-calendar-bks; Fri, 26 Jul 1996 12:41:15 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from feyuri.microsoft.com (feyuri.microsoft.com [131.107.243.53]) by imc.org (8.7.4/8.7.3) with SMTP id MAA08673 for ; Fri, 26 Jul 1996 12:41:11 -0700 (PDT) Received: by feyuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB7AF0.4346E540@feyuri.microsoft.com>; Fri, 26 Jul 1996 12:45:02 -0700 Message-ID: From: "Ian Ferrell (Exchange)" To: "'ietf-calendar@imc.org'" Subject: Internet draft pointers... Date: Fri, 26 Jul 1996 12:44:52 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk A number of you asked for a pointer to our internet draft docs at Wednesday's meeting. If you've lost that note, or were not able to attend the informal meeting, here they are: The first draft outlines a framework for carrying properties in a MIME body part: ftp://ds.internic.net/internet-drafts/draft-shakib-mime-prop-00.txt The second draft defines a profile for appointments, appointment requests/cancellations and appointment responses. The profile includes both one-time and recurring appointments: ftp://ds.internic.net/internet-drafts/draft-ferrell-prop-cal-00.txt I will also forward them to this list's document archive at http://www.imc.org/ietf-calendar-doc (very cool feature!) Please feel free to forward questions and comments to Darren or me. Thanks, - ian ___________ Ian Ferrell Program Manager, Microsoft mailto: ianf@microsoft.com From owner-ietf-calendar Mon Jul 29 07:04:38 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id HAA27737 for ietf-calendar-bks; Mon, 29 Jul 1996 07:04:38 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from on.on.com (on.on.com [207.18.216.2]) by imc.org (8.7.4/8.7.3) with ESMTP id HAA27732 for ; Mon, 29 Jul 1996 07:04:35 -0700 (PDT) Received: from dev.on.com (dev.on.com [207.18.216.16]) by on.on.com (8.7.5/ON-1) with ESMTP id KAA04825 for ; Mon, 29 Jul 1996 10:04:57 -0400 (EDT) Received: from IP_TUNNEL/SpoolDir by dev.on.com (DaVinci Version: 4.11); 29 Jul 96 10:19:42 -0500 Received: from SpoolDir by IP_TUNNEL (DaVinci Version: 4.11); 29 Jul 96 10:19:13 -0500 To: ietf-calendar Subject: Re: access control In-Reply-To: Re: access control X-DVS-Message-Class: 2 From: Jay Batson Date: 27 Jul 1996 07:05:43 -0400 X-DVS-Mail-Trail: Replied by: Jay Batson on 7/27/96 7:05AM X-Mailer: DaVinci SMTP 4.11 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <838461943@dev.on.com> X-DVS-Conversation-ID: 838461943@dev.on.com Sender: owner-ietf-calendar@imc.org Precedence: bulk On 7/26/96 at 12:26PM you said: >Arathi Balakrishna wrote: > >> 2.It would be nice to have links to other calendar events on a user's >> personal calendar. Has it been given any thought? > >You are talking about the concept of event lists. Event lists are not >calendars, but simply lists of events typically related in some way e.g. >Holidays, Company events. Using event lists the user can bring events >into her calendar which are not necessarily appointments, but just >events to be aware of. Event lists provide a mechanism for people or >companies to publish lists of their events to the world and allow >individual users to bring those events into their personal calendars. >For example, the SF Giants could publish a list of their baseball >games. If a user added this event list to their calendar, the baseball >game schedule would show up in their calendar and maybe they could >select specific games to be notified on, but most of the games would >just be place holders for viewing purposes only. In the intranet world, >companies could publish event lists for company events, etc. which would >show up on all employee personal calendars. > >This is a very powerful feature and something we should definitely >include in our investigation. A reminder that the process of creating a standards spec is slightly different than creating a product. Products want neat features. Standards specs want to powerful base constructs that products can be built on. To me, "event lists" are a function that arise out of careful definition of an event object containing a type tag. What happens with the event object and its type is up to the product implementer. If the vendor wants to put it on a web page with links, or embed it in a Windows object, it's up to the vendor. As to Arathi's original access control comment, the spec should specify coarse access control mechanism, but not policy. For example, not every company will want to allow free/busy time searches. So providing them should not be required for a product to "meet the spec". However, the spec *should* provide a mechanism to allow a program to require one level of authentication for free/busy time searches as contrasted with the level that allows viewing the contents of a particular users' calendar. The former would be useful for companies who want to provide free/busy time searches to "trusted" foreign domains (e.g. trading partners) but not to the "general public. Other administrators / users might choose to provide any/all info without authentication. Anything in the spec that is designed to "inquire" about information should permit differing behavior based on authentication level. As a reference, SSTP provides for this in its authentication mechanism. You can authenticate any way you can. If you've provided "enough" authentication to satisfy the inquired system, you get what you've asked for. If not, you get an error code back saying you don't have access to this info. -jb ----- Jay Batson ON Technology Corp. jbatson@on.com 617-692-3591 From owner-ietf-calendar Mon Jul 29 09:00:01 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA28173 for ietf-calendar-bks; Mon, 29 Jul 1996 09:00:01 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by imc.org (8.7.4/8.7.3) with SMTP id IAA28158 for ; Mon, 29 Jul 1996 08:59:50 -0700 (PDT) Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA25102; Mon, 29 Jul 1996 12:01:55 -0400 Received: from rtpnsi01.raleigh.ibm.com (rtpnsi01.raleigh.ibm.com [9.67.71.43]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id MAA40096 for ; Mon, 29 Jul 1996 12:01:53 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA5929; Mon, 29 Jul 96 12:03:09 -0400 Message-Id: <9607291603.AA5929@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id A695B7E44123089C8525637600572731; Mon, 29 Jul 96 12:03:09 To: ietf-calendar From: Frank Dawson Date: 29 Jul 96 11:51:56 Subject: Access Control Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk We probably need to differentiate between a few of the security terms that have been used in this list and at the previous calendaring summit meeting. I think that these were AUTHORIZATION, AUTENTICATION, and ACCESS CONTROL. Typically, authorization and authentication would be done within the service level. If we are using an email service access, then authorization might map through the originator's SMTP address. The authentication might be mapped using some current IETF authentication service (eg, certificates). In many calendaring/scheduling systems, access control is defined on a per user or per group basis by the owner of the calendar that is being "accessed". Within the XAPIA and X/Open Calendaring and Scheduling API and within the vCalendar specifications this is initially defined in terms of three levels of access control. Products may implement further levels beyond this, based on customer requirements etc. The XAPIA/XOpen/vCalendar use of the PUBLIC, PRIVATE, and CONFIDENTIAL have a VERY long legacy and product basis. This is not to say that specific implementation would not want to go beyond this basic level of specification. Cheers. - - Frank Dawson From owner-ietf-calendar Mon Jul 29 09:03:01 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA28229 for ietf-calendar-bks; Mon, 29 Jul 1996 09:03:01 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by imc.org (8.7.4/8.7.3) with SMTP id JAA28224 for ; Mon, 29 Jul 1996 09:02:58 -0700 (PDT) Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA34072; Mon, 29 Jul 1996 12:05:13 -0400 Received: from rtpnsi01.raleigh.ibm.com (rtpnsi01.raleigh.ibm.com [9.67.71.43]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id MAA16030 for ; Mon, 29 Jul 1996 12:05:10 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA5982; Mon, 29 Jul 96 12:06:26 -0400 Message-Id: <9607291606.AA5982@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id E1461AE7BD68F16A8525637600566FB9; Mon, 29 Jul 96 12:06:26 To: ietf-calendar From: Frank Dawson Date: 29 Jul 96 11:44:07 Subject: Event Links Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk The concept of event links may have a couple of impacts to our work. I am in somewhat agreement though with Jay Batson. This capability may be more a capability of a specific product, rather than a feature/function of an IETF calendaring standard. Using the term "link" to mean a "thread" of related events, we might see no feature/function in the standard, but instead use the text of the SUMMARY property of an event to perform "threading" of related events within the calendar product. An alternative approach would be to add a RELATIONAL IDENTIFIER property to an event or todo object. This would allow related events and todo objects to refer to the same identifier. The identifier would probably want to be a GUID. The former is a loose coupling of the concept. The latter involves a tighter coupling of the concept. Using the term "link" in its more current semantic, cross event referencing can be achieved using an URL property, as is done in the vCalendar specification. Alternately, if every event can be identified by a GUID type of reference identifier, then another event can refer to it merely by putting that GUID as a value in a LINK REFERENCE property. This would provide for a chaining of related events. Traditional approches would be used to refer to end of the linked list or a circularly linked list. Cheers. - - Frank Dawson From owner-ietf-calendar Mon Jul 29 09:23:17 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA28375 for ietf-calendar-bks; Mon, 29 Jul 1996 09:23:17 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from owi.com. ([205.231.150.4]) by imc.org (8.7.4/8.7.3) with SMTP id JAA28370 for ; Mon, 29 Jul 1996 09:23:14 -0700 (PDT) From: tim@bitter.owi.com Received: from bitter.owi.com. ([205.231.150.6]) by owi.com. (5.x/SMI-SVR4) id AA17960; Mon, 29 Jul 1996 12:26:42 -0400 Received: from bitter.owi.com (localhost) by bitter.owi.com. (5.x/SMI-SVR4) id AA21933; Mon, 29 Jul 1996 12:12:06 -0400 Message-Id: <9607291612.AA21933@bitter.owi.com.> X-Mailer: exmh version 1.6.5 12/11/95 To: ietf-calendar@imc.org Subject: Security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jul 1996 12:12:05 -0400 Sender: owner-ietf-calendar@imc.org Precedence: bulk Folks, As Frank Dawson writes: "We probably need to differentiate between a few of the security terms that have been used in this list and at the previous calendaring summit meeting. I think that these were AUTHORIZATION, AUTENTICATION, and ACCESS CONTROL." Access Control in calendaring has to go beyond simple PUBLIC/PRIVATE schemes. It needs to take into account the need for some people to have access to your entire schedule, partially view your schedule, simply check to see if you are busy at a given time without access to the information as to why you might be busy or simple no access. The SWTP take on access control goes something like this (from Section 11.2 of the SWTP protocol (ftp://://ds.internic.net/internet-drafts/draft-spencer-swtp- 00.txt) 2. Permission levels permitting or denying access to other calen- dars after binding. SWTP recognizes 6 different levels of secu- rity here. Full A user is granted full access to another persons calendar and may modify schedules as if that user. ViewInvite A user may view another calendar, and invite that person to meetings, but may not other- wise modify that calendar. Invite A user may invite another to meetings, and determine if that person is available, but may not view specific data on that calendar. ViewOnly A user may view another schedule, but not invite that person to meetings. None A user may not view another calendar, nor invite them to meetings. Best, Tim -- Tim McEachern, CEO Phase2 Software tim@p2software.com 518.392.6928 - direct tel 518.392.4537 - direct fax From owner-ietf-calendar Mon Jul 29 09:35:49 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA28466 for ietf-calendar-bks; Mon, 29 Jul 1996 09:35:49 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from p2software.com (bill@ruby.p2software.com [146.115.104.49]) by imc.org (8.7.4/8.7.3) with SMTP id JAA28460 for ; Mon, 29 Jul 1996 09:35:45 -0700 (PDT) Received: (from bill@localhost) by p2software.com (8.6.11/8.6.9) id MAA02140; Mon, 29 Jul 1996 12:44:29 -0400 Date: Mon, 29 Jul 1996 12:44:28 -0400 (EDT) From: "William P. Spencer" To: ietf-calendar Subject: Re: access control In-Reply-To: <838461943@dev.on.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@imc.org Precedence: bulk You are right on target Jay. Event "links" are really just a special type of event, so should just be part of the event object. If there is a related group of events then they should be related by a common category specifier. And the comments on the access control are correct, too. The spec needs to specify some levels of access control which indicate what services are allowed/available to the user agent from the server. It's not the UA that is imposing the access control, it's the server, based on policies set by the individuals who own the calendar, or server. Reading Jay's note brought up an interesting point in my mind, which is: It may be very tempting to create a Level I spec, and defer other difficult, or otherwise not well understood, operations to a Level II spec. In general, I'm not in favor of this because it's too easy to brush off critical topics because they are hard, and thereby miss some critical issue which will be harder to correct later. This is not to say we shouldn't have a Level II spec, but if we defer something to it, it should only be after careful study. My first glance at Jay's message caused me to mis-read it, and I thought he was somehow deferring the issue of free time searches. However, a closer read made me realize that the opposite was the case. As Jay points out, the need for free time searches, and the equal need to limit free time searches requires linking it to access permissions. We need both access permissions, and capability for free-time search in our spec. Jay Batson wrote: > > To me, "event lists" are a function that arise out of careful definition > of an event object containing a type tag. What happens with the event > object and its type is up to the product implementer. If the vendor wants > to put it on a web page with links, or embed it in a Windows object, it's > up to the vendor. > > As to Arathi's original access control comment, the spec should specify > coarse access control mechanism, but not policy. > > For example, not every company will want to allow free/busy time searches. > So providing them should not be required for a product to "meet the spec". > However, the spec *should* provide a mechanism to allow a program to > require one level of authentication for free/busy time searches as > contrasted with the level that allows viewing the contents of a particular > users' calendar. The former would be useful for companies who want to Bill Spencer From owner-ietf-calendar Mon Jul 29 10:46:27 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA29005 for ietf-calendar-bks; Mon, 29 Jul 1996 10:46:27 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from imakron.sarrus.com (imakron.sarrus.com [205.219.53.129]) by imc.org (8.7.4/8.7.3) with ESMTP id KAA29000 for ; Mon, 29 Jul 1996 10:46:25 -0700 (PDT) Received: from sarrus.com (sarrus [205.219.53.65]) by imakron.sarrus.com (8.7.1/8.7.1) with SMTP id KAA01279 for ; Mon, 29 Jul 1996 10:30:38 -0700 (PDT) Received: from galli by sarrus.com (NX5.67d/NeXT-2.0) id AA13090; Mon, 29 Jul 96 10:42:20 -0700 Message-Id: <31FCF95D.5337@sarrus.com> Date: Mon, 29 Jul 1996 10:48:13 -0700 From: Andy Turk Reply-To: andy@sarrus.com Organization: Sarrus Software, Inc. X-Mailer: Mozilla 3.0b4 (Win95; I) Mime-Version: 1.0 To: ietf-calendar@imc.org Subject: Access Control Requirements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk If we want the standard to succeed as a basis for interoperability between existing C&S products, then we will definitely need a standard access control model. Ignoring access control would lead to a spec where anyone might see everything in your calendar, or conversely, nobody (except for those who use the same scheduling product) might be able to see anything. Neither extreme would go very far to solve the interoperability problem for customers. I think we could save ourselves some time by trying to nail down some requirements before attempting to choose between alternative feature sets. Here are a couple of suggestions for requirements that our standard should satisfy. Requirement #1 Calendar Access Model Current products seem to offer two different types of access control: event level (e.g., "private" and "confidential") and calendar level (e.g., "view only" and "modify"). Of the two, I think that a standard calendar access model is a *must* for interoperability. Event level control will be important to some users, but probably not everyone. We might be able to live without it. Requirement #2 Server-side Control vCalendar (Frank, I'm only picking on your spec because it was well written :-), lets you specify an event as being "PRIVATE" but leaves the interpretation of what that means up to the software that parses the representation. This means that I could download "Bubba's Freeware Calendar" which ignores event level access control and see who's having lunch with an attractive co-worker. To prevent problems like this, access control should be enforced on the server side (i.e., not the client side). Thoughts, comments? Andy Turk Sarrus Software, Inc. andy@sarrus.com From owner-ietf-calendar Mon Jul 29 10:49:38 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA29030 for ietf-calendar-bks; Mon, 29 Jul 1996 10:49:38 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from loki.ossi.com (loki-8.ossi.com [192.240.8.1]) by imc.org (8.7.4/8.7.3) with SMTP id KAA29025 for ; Mon, 29 Jul 1996 10:49:37 -0700 (PDT) Received: from TEAMWARE02. TeamWARE MIME Connector (teamware02.ossi.com [192.240.10.16]) by loki.ossi.com (8.6.11/8.6.11) with SMTP id KAA15801; Mon, 29 Jul 1996 10:53:22 -0700 MIME-Version: 1.0 Date: 29 Jul 96 10:52:36 +0000 From: "ENBERG MIKA" Subject: RE:Security Reply-To: mika@ossi.com In-Reply-To: Security Message-Id: <9607291052.aa36@TEAMWARE02.> To: jari@ossi.com, khorwitz@ossi.com, ietf-calendar@imc.org, tim@bitter.owi.com Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@imc.org Precedence: bulk Hello all, I believe that what Tim is saying is in line with the customer requirements for a calendaring/scheduling tool. But I believe that even a little bit more granularity is needed, and I am not sure if I am going to specifying functionality rather than the standard, but I would like to propose a couple of additions. 1. After the ViewInvite, I would like to add ViewInviteSubject only, which would allow only the time and subject of the meeting to be seen, but not the comments partisipants, location etc. 2 Add an access right called Autoconfirm, a right that would allow all made request by a set or all calendars to be automatically confirmed. This would be especially usefull for the resource calendars, that are not managed by someone, and information related to the meetings is for the participants eyes only. 3. This propably belongs to the event object attributes, but an per event attribute Private, to make it private and override all the standard above and below access rights. Tere, Mika tim@bitter.owi.com: > 2. Permission levels permitting or denying access to other calen- > dars after binding. SWTP recognizes 6 different levels of secu- > rity here. > > > Full A user is granted full access to another > persons calendar and may modify schedules as > if that user. > > ViewInvite A user may view another calendar, and invite > that person to meetings, but may not other- > wise modify that calendar. > > Invite A user may invite another to meetings, and > determine if that person is available, but > may not view specific data on that calendar. > > ViewOnly A user may view another schedule, but not > invite that person to meetings. > > None A user may not view another calendar, nor > invite them to meetings. From owner-ietf-calendar Mon Jul 29 11:13:53 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA29170 for ietf-calendar-bks; Mon, 29 Jul 1996 11:13:53 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.3) with ESMTP id LAA29165 for ; Mon, 29 Jul 1996 11:13:50 -0700 (PDT) Received: from [205.214.160.88] (d8.netgate.net [205.214.160.40]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id LAA24194; Mon, 29 Jul 1996 11:25:39 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <9607291603.AA5929@rtpnsi01.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 29 Jul 1996 11:06:59 -0700 To: Frank Dawson From: Dave Crocker Subject: Re: Access Control Cc: ietf-calendar Sender: owner-ietf-calendar@imc.org Precedence: bulk Frank, At 11:51 AM -0700 7/29/96, Frank Dawson wrote: >We probably need to differentiate between a few of the security terms that >have >been used in this list and at the previous calendaring summit meeting. I >think >that these were AUTHORIZATION, AUTENTICATION, and ACCESS CONTROL. > >Typically, authorization and authentication would be done within the service >level. If we are using an email service access, then authorization might map >through the originator's SMTP address. The authentication might be mapped >using >some current IETF authentication service (eg, certificates). fact of life: there is no IETF authentication standard in general deployment and I don't think there is anything that one would even call a standard. This is a problem on several fronts and one which I think we should push for solution to, this year. The ACAP working group (configuration protocol, effort derivative of IMAP) has an authorization spec that it is considering. >In many calendaring/scheduling systems, access control is defined on a per >user >or per group basis by the owner of the calendar that is being "accessed". I'm not clear about the distinction you are making between authorization and access control. I'm used to treating them as synonyms. Please elaborate. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-calendar Mon Jul 29 11:38:11 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA29256 for ietf-calendar-bks; Mon, 29 Jul 1996 11:38:11 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from p2software.com (bill@ruby.p2software.com [146.115.104.49]) by imc.org (8.7.4/8.7.3) with SMTP id LAA29251 for ; Mon, 29 Jul 1996 11:38:09 -0700 (PDT) Received: (from bill@localhost) by p2software.com (8.6.11/8.6.9) id OAA02230; Mon, 29 Jul 1996 14:46:56 -0400 Date: Mon, 29 Jul 1996 14:46:55 -0400 (EDT) From: "William P. Spencer" To: ietf-calendar@imc.org Subject: Re: Security Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@imc.org Precedence: bulk I just wanted to elaborate on Tim M.'s comments on SWTP security. >From a user's perspective, there are (at least) 4 types of access which are important CHECK Allow a check for free-time on my calendar. (Can view date and time info only). INVITE Allow an invitation to be sent to me. VIEW Allow my calendar to be viewed. MODIFY Allow my calendar to be modified. You can also imagine access privileges which are a logical or'ing of two or more of these access permissions. Some of them overlap, for example, VIEW access always implies CHECK access. The SWTP user-level permissions Tim describes, and the SWTP draft describes are derived from various combinations of this privilege set. Something we left out of SWTP, which there seems to be real sentiment for are access permissions on a per-event basis. This would be the CONFIDENTIAL event which can be VIEW'ed , MODIFY'ed or CHECK'ed only by the true, authenticated owner of the calendar. I hope this helps. Bill From owner-ietf-calendar Mon Jul 29 12:11:45 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA29469 for ietf-calendar-bks; Mon, 29 Jul 1996 12:11:45 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by imc.org (8.7.4/8.7.3) with SMTP id MAA29464 for ; Mon, 29 Jul 1996 12:11:42 -0700 (PDT) Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA52124; Mon, 29 Jul 1996 15:13:59 -0400 Received: from rtpnsi01.raleigh.ibm.com (rtpnsi01.raleigh.ibm.com [9.67.71.43]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id PAA32812 for ; Mon, 29 Jul 1996 15:13:55 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA7435; Mon, 29 Jul 96 15:15:12 -0400 Message-Id: <9607291915.AA7435@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id B740BF759E00EB3E8525637600685BF1; Mon, 29 Jul 96 15:15:12 To: ietf-calendar From: Frank Dawson Date: 29 Jul 96 15:04:51 Subject: Access Control Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Dave: Yes, thanks for reminding us about what you said at the "Summit" meeting that the IETF does not have a common AUTENTICATION service defined. As to differentiation of AUTHORIZATION and ACCESS CONTROL. An end user can be authorized to use a calendar service, but may not have the access control to access an individual calendar or to free-time search, view, or modify an individual entry. Within an application like calendaring and scheduling, there is quite often a distinction made between authorization and access control. This is also the case in other services such as document management and work flow management. Bill Spencer's last remarks about access control being differentiated between the calendar container and the individual event or todo instances in the calendar is VERY important. A good point, Bill! Cheers. - - Frank Dawson From owner-ietf-calendar Mon Jul 29 12:48:54 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA29659 for ietf-calendar-bks; Mon, 29 Jul 1996 12:48:54 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from prawn.fishy.net (flounder.fishy.net [206.156.56.34]) by imc.org (8.7.4/8.7.3) with ESMTP id MAA29653 for ; Mon, 29 Jul 1996 12:48:46 -0700 (PDT) Received: from taj (cobia.fishy.net [172.16.3.30]) by prawn.fishy.net (8.7.5/8.7.3) with SMTP id PAA14904; Mon, 29 Jul 1996 15:48:24 -0400 Message-ID: <31FCDCB9.5AF7@staff.prodigy.net> Date: Mon, 29 Jul 1996 15:52:36 +0000 From: Arathi Balakrishna X-Mailer: Mozilla 3.0b5aGold (WinNT; I) MIME-Version: 1.0 To: andy@sarrus.com CC: ietf-calendar@imc.org Subject: Re: Access Control Requirements References: <31FCF95D.5337@sarrus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Andy Turk wrote: > I think we could save ourselves some time by trying to nail down some > requirements before attempting to choose between alternative feature sets. > Here are a couple of suggestions for requirements that our standard should > satisfy. > > Requirement #1 Calendar Access Model > Current products seem to offer two different types of access control: > event level (e.g., "private" and "confidential") and calendar level (e.g., > "view only" and "modify"). Of the two, I think that a standard calendar > access model is a *must* for interoperability. Event level control will be > important to some users, but probably not everyone. We might be able to > live without it. > At the event level, we might need a "restricted" level based on user groups being able to view/modify the calendar, or intepret the "private" access level to mean "restricted". Something that would come up eventually..... regards, Arathi arathib@staff.prodigy.com From owner-ietf-calendar Mon Jul 29 12:49:44 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA29673 for ietf-calendar-bks; Mon, 29 Jul 1996 12:49:44 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by imc.org (8.7.4/8.7.3) with SMTP id MAA29668 for ; Mon, 29 Jul 1996 12:49:41 -0700 (PDT) Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA21990; Mon, 29 Jul 1996 15:51:57 -0400 Received: from rtpnsi01.raleigh.ibm.com (rtpnsi01.raleigh.ibm.com [9.67.71.43]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id PAA27744 for ; Mon, 29 Jul 1996 15:51:52 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA7674; Mon, 29 Jul 96 15:53:08 -0400 Message-Id: <9607291953.AA7674@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id AB581BE4F6262F04852563760069BD7E; Mon, 29 Jul 96 15:53:08 To: ietf-calendar From: Frank Dawson Date: 29 Jul 96 15:20:57 Subject: Security Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Mika wrote: 1. After the ViewInvite, I would like to add ViewInviteSubject only, which would allow only the time and subject of the meeting to be seen, but not the comments partisipants, location etc. >>>Large organization calendaring experience suggests that if you don't >>>want someone to see the attendees, location, description, then the >>>subject is probably taboo too. I would lobby that if you can't see >>>the event details then all you can see is the blocking time, all >>>else is hidden. 2 Add an access right called Autoconfirm, a right that would allow all made request by a set or all calendars to be automatically confirmed. This would be especially usefull for the resource calendars, that are not managed by someone, and information related to the meetings is for the participants eyes only. >>>The autoconfirm feature is better left to the calendar >>>implementation, not to the protocol. This can very well be >>>implemented in a number of ways (ie, agent technology, client >>>profile option, server profile option, etc). THIS SHOULD NOT BE >>>IN THE IETF PROTOCOL!! 3. This propably belongs to the event object attributes, but an per event attribute Private, to make it private and override all the standard above and below access rights. >>>I think that the spirit of your requirement is better met by an >>>event and todo property for classification of the object into >>>PUBLIC, PRIVATE, or CONFIDENTIAL. XAPIA CSA gives a good definition >>>for these access control values. - - Frank Dawson From owner-ietf-calendar Mon Jul 29 13:32:32 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA29870 for ietf-calendar-bks; Mon, 29 Jul 1996 13:32:32 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by imc.org (8.7.4/8.7.3) with ESMTP id NAA29865 for ; Mon, 29 Jul 1996 13:32:30 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I7N6VUU2XC8Y4X7P@INNOSOFT.COM>; Mon, 29 Jul 1996 13:35:58 -0700 (PDT) Date: Mon, 29 Jul 1996 13:23:27 -0700 (PDT) From: Ned Freed Subject: Re: Access Control In-reply-to: "Your message dated Mon, 29 Jul 1996 11:06:59 -0700" To: Dave Crocker Cc: Frank Dawson , ietf-calendar Message-id: <01I7NATNJ0TE8Y4X7P@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <9607291603.AA5929@rtpnsi01.raleigh.ibm.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk > fact of life: there is no IETF authentication standard in general > deployment and I don't think there is anything that one would even call a > standard. This is a problem on several fronts and one which I think we > should push for solution to, this year. Whether or not this assessment is correct depends very much on what you mean by "authentication". If you're talking about end-to-end authentication across a store-and-forward protocol like email, then yes I agree absolutely. But if you're talking about point-to-point authentication, I disagree. We have standard solutions in this area for IMAP4 and POP3 that are in fact in fairly widespread use. > The ACAP working group (configuration protocol, effort derivative > of IMAP) has an authorization spec that it is considering. Both ACAP and SMTP are in the process of acquiring the same technology that is being used with POP3 and IMAP4. Having a common authentication framework for all of these is proving to be a huge win for implementors. Note also that authentication is only one part of access control. Both IMAP4 and ACAP share a core access control model that I would strongly recommend as a starting point for any access control model for calendering. There are obvious differences, of course, but having these be as close to each other as possible would again be a major win in my opinion. > I'm not clear about the distinction you are making between > authorization and access control. I'm used to treating them as synonyms. Authorization is normally just a means of identifying someone. Access control is what happens after that: Given that you're so-and-so, there has to be some mechanism that defines what you can or cannot do and what you can or cannot do it to. Acess control therefore involves a lot of stuff other than simple authentication: (1) Defining an object space of things to be secured. (2) Define what can be done to these objects and thus what rights can be granted or denied to different users. (3) In the case of hierarchical object spaces, defining how rights are inherited and propogated. This includes specification of default rights for newly created objects. (4) Defining the interfaces to present all this to applications. Ned From owner-ietf-calendar Mon Jul 29 14:28:51 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id OAA00343 for ietf-calendar-bks; Mon, 29 Jul 1996 14:28:51 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.3) with ESMTP id OAA00337 for ; Mon, 29 Jul 1996 14:28:49 -0700 (PDT) Received: from [205.214.160.88] (d72.netgate.net [205.214.160.108]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id OAA03580; Mon, 29 Jul 1996 14:40:39 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <01I7NATNJ0TE8Y4X7P@INNOSOFT.COM> References: "Your message dated Mon, 29 Jul 1996 11:06:59 -0700" <9607291603.AA5929@rtpnsi01.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 29 Jul 1996 14:29:43 -0700 To: Ned Freed From: Dave Crocker Subject: Re: Access Control Cc: Frank Dawson , ietf-calendar Sender: owner-ietf-calendar@imc.org Precedence: bulk At 1:23 PM -0700 7/29/96, Ned Freed wrote: >> fact of life: there is no IETF authentication standard in general >> deployment and I don't think there is anything that one would even call a >> standard. This is a problem on several fronts and one which I think we >> should push for solution to, this year. > >Whether or not this assessment is correct depends very much on what you >mean by >"authentication". If you're talking about end-to-end authentication across a actually, it primarily depends upon my typing. I meant authorization, not authentication and apologize muchly for the error. Having already had two cups of coffee at that point of the day, I can't blame it on anything outside of my control. We have various authentication mechanisms that are standardized and even deployed. None particularly massively, but at least they're real. Such is not the case for a net-wide authorization scheme and mechanism. >store-and-forward protocol like email, then yes I agree absolutely. But if >you're talking about point-to-point authentication, I disagree. We have but since my note triggered this point from you, let me strongly agree and make sure folks appreciate your point. "Channel" mechanisms between an interactive pair are in tolerable shape. "Object" mechanisms are not. S/Mime, PGP, etc., all hope to solve that. It's another 1-2 years before we'll know (IMO). >Note also that authentication is only one part of access control. Both IMAP4 >and ACAP share a core access control model that I would strongly recommend >as a >starting point for any access control model for calendering. There are obvious >differences, of course, but having these be as close to each other as possible >would again be a major win in my opinion. this is in the realm I MEANT to cite in my previous, mangled, message. > >> I'm not clear about the distinction you are making between >> authorization and access control. I'm used to treating them as synonyms. > >Authorization is normally just a means of identifying someone. Access control ??? I'm used to using the term "identification" for specifying a label/name; authentication for certifying its validity; and authorization for applying it to give/withhold permission. Mumble. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-calendar Mon Jul 29 15:24:01 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id PAA00584 for ietf-calendar-bks; Mon, 29 Jul 1996 15:24:01 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from dns1.noc.best.net (root@dns1.noc.best.net [206.86.8.69]) by imc.org (8.7.4/8.7.3) with SMTP id PAA00579 for ; Mon, 29 Jul 1996 15:23:59 -0700 (PDT) Received: from poleary.vip.best.com (poleary.vip.best.com [206.86.235.98]) by dns1.noc.best.net (8.6.12/8.6.5) with SMTP id PAA27246 for ; Mon, 29 Jul 1996 15:28:21 -0700 Message-ID: <31FD3BCF.1AAE@clearblue.com> Date: Mon, 29 Jul 1996 15:31:43 -0700 From: "Peter O'Leary" Reply-To: poleary@clearblue.com Organization: Clear Blue Network Systems, Inc. X-Mailer: Mozilla 3.0b4 (Win95; I) MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Access Control Requirements References: <31FCF95D.5337@sarrus.com> <31FCDCB9.5AF7@staff.prodigy.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Arathi Balakrishna wrote: > At the event level, we might need a "restricted" level based on user > groups being able to view/modify the calendar, or intepret the > "private" access level to mean "restricted". Something that would > come up eventually..... My humble $.02: Based on my experience with OfficeVision users's requirements, the important attributes at the event level are "Personal" and "Confidential". "Personal" events are not viewable by anyone other than yourself. "Confidential" events are viewable by those with a "trusted relationship" (I'm being deliberatly vague here) relative to you - perhaps your assistant or some other delegate. Events with neither of these attributes can be viewed by anyone with read access to your calendar store. In implementations that I've worked on in the past, I've toyed with the idea having many more discrete levels of access control on events, but these just seemed to confuse the heck out of users. Having only one level of control, i.e. "Confidential" only, was not considered to be sufficient. BTW, the same seems to be true in regards to calendar-level access also. Presenting folks with the tradional read/write/delete/etc. flags often causes confusion. By far the two most common levels of access are (expressed from a user's point of view): "Fred is my assistant and he needs to be able to do anything to my calendar that I ask him to" and "I'd like everyone in my workgroup (or company) to be able to browse my calendar, but not modify it". In short: I definately think that access control should be defined, but kept as simple as possible. Pete. From owner-ietf-calendar Mon Jul 29 17:54:23 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id RAA01115 for ietf-calendar-bks; Mon, 29 Jul 1996 17:54:23 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by imc.org (8.7.4/8.7.3) with SMTP id RAA01110 for ; Mon, 29 Jul 1996 17:54:18 -0700 (PDT) Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA28730; Mon, 29 Jul 1996 20:56:36 -0400 Received: from rtpnsi01.raleigh.ibm.com (rtpnsi01.raleigh.ibm.com [9.67.71.43]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id UAA44738 for ; Mon, 29 Jul 1996 20:56:37 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA9363; Mon, 29 Jul 96 20:57:45 -0400 Message-Id: <9607300057.AA9363@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 197A52168DB14900852563770004B821; Mon, 29 Jul 96 20:57:43 To: ietf-calendar From: Frank Dawson Date: 29 Jul 96 20:53:01 Subject: Access Control Requirements Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Pete: In your OV/VM summary you forgot the basic level, PUBLIC. This is the default. This is also true for the other OfficeVision family of calendaring systems (ie, OV/MVS and OV/400). - - Frank From owner-ietf-calendar Mon Jul 29 18:27:25 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id SAA01255 for ietf-calendar-bks; Mon, 29 Jul 1996 18:27:25 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by imc.org (8.7.4/8.7.3) with SMTP id SAA01250 for ; Mon, 29 Jul 1996 18:27:22 -0700 (PDT) Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA55270; Mon, 29 Jul 1996 21:29:40 -0400 Received: from rtpnsi01.raleigh.ibm.com (rtpnsi01.raleigh.ibm.com [9.67.71.43]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id VAA26276 for ; Mon, 29 Jul 1996 21:29:37 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA9427; Mon, 29 Jul 96 21:30:52 -0400 Message-Id: <9607300130.AA9427@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id DD54AF146CE10D3B8525637700057246; Mon, 29 Jul 96 21:30:52 To: ietf-calendar From: Frank Dawson Date: 29 Jul 96 21:24:59 Subject: Access Rights According to CSA Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Folks, health warning...long note: Since I haven't formatted the XAPIA CSA document into a I-D like *.txt format, here is the text from that document on access rights etc. I don't know how this will format in an email message, so let me describe. This is the AccessList abstract data type from the CSA specification. I keep quoting scripture from it because it was defined as a consensus document from input from Lotus, WordPerfect, Novell, Microsoft, DAC Associates, IBM, CE Software, Campbell Services, Microsystems Software, Attachmate, Arabesque Software, and SunSoft. It has been implemented in over four vendor products. Sorry for the tendency to reuse. It's just good stuff, built on previous consensus The access list in the CSA is a linked list of a two-tuple of the calendar user and a mask of access rights. This access list is defined on a calendar basis for determining access privileges to the calendar container by a number of external users. The highest access right is the rights equivalent to the calendar owner. Remember these are the access rights given an external user. The individual objects or entries in a calendar have classifications that match the basic three levels made use of here (ie, PUBLIC, PRIVATE, and CONFIDENTIAL). I think that this meets the requirements indicated in the notes so far. Here is the descriptive prose that describes a very good model for access control (page 11-12, CSA): The accessibility of a calendar to an individual user can be controlled by the access rights given that user. Access rights are paired with a calendar user. A calendar user can be an individual, group or resource. The access rights are maintained in an access list. The access list is a particular calendar attribute. The access rights are individually controlled and can be accumulated to define a range of accessibility of a user to a calendar and its entries. The access rights can also be specified in terms of one of three access roles. These include the role of the owner of a calendar, the organizer of a particular entry within the calendar, and the sponsor of a particular entry within the calendar. The owner role permits the user to do anything to the calendar or calendar entries that the owner of the calendar can do. This includes deleting the calendar, viewing, inserting, and changing calendar attributes, adding and deleting calendar entries, and viewing, inserting, and changing entry attributes. The organizer role permits the user to delete the entry or view and change entry attributes for those calendar entries which the user is specified as the organizer. The organizer defaults to the calendar user that created the entry. The sponsor role permits the user to delete the entry or view and change entry attributes for those calendar entries which the user is specified as the sponsor. The sponsor is the calendar user that effectively owns the calendar event or todo. In addition to these roles, an access right can be set to limit access to free time searches, view, insert or change calendar attributes, or view, insert or change entries; dependent on thei r classification as public, confidential, or private. The entry classification acts as a secondary filter on accessibility. Here is the definition of the access list abstract data type: Access List NAME Access List - type definition for a list of access rights data value. C DECLARATION typedef struct CSA_TAG_ACCESS_RIGHTS { CSA_calendar_user *user; CSA_flags rights; struct CSA_TAG_ACCESS_RIGHTS *next; } CSA_access_rights, *CSA_access_list; DESCRIPTION A data value of this data type is used to define the access rights for a list of calendar users. An access list is a list of access rights data structures. The access rights structure consists of the following components: 1. user - Identifies the calendar user associated with this access entry. 2. rights - Specifies the access rights for this user to this calendar. The defined access rights include: CSA_FREE_TIME_SEARCH CSA_VIEW_PUBLIC_ENTRIES CSA_VIEW_CONFIDENTIAL_ENTRIES CSA_VIEW_PRIVATE_ENTRIES CSA_INSERT_PUBLIC_ENTRIES CSA_INSERT_CONFIDENTIAL_ENTRIES CSA_INSERT_PRIVATE_ENTRIES CSA_CHANGE_PUBLIC_ENTRIES CSA_CHANGE_CONFIDENTIAL_ENTRIES CSA_CHANGE_PRIVATE_ENTRIES CSA_VIEW_CALENDAR_ATTRIBUTES CSA_INSERT_CALENDAR_ATTRIBUTES CSA_CHANGE_CALENDAR_ATTRIBUTES CSA_ORGANIZER_RIGHTS CSA_SPONSOR_RIGHTS CSA_OWNER_RIGHTS CSA_FREE_TIME_SEACH - When set, implies that the user will be able to access the calendar entries for free time search. No access is provided to the calendar attributes. CSA_VIEW_PUBLIC_ENTRIES, CSA_VIEW_PRIVATE_ENTRIES, and CSA_VIEW_CONFIDENTIAL_ENTRIES - When set, gives the user access to list and read the calendar entries with an access class of public, private, or confidential, respectively. No access is provided to the calendar attributes. CSA_INSERT_PUBLIC_ENTRIES, CSA_INSERT_PRIVATE_ENTRIES, CSA_INSERT_CONFIDENTIAL_ENTRIES - When set, gives the user access to add the calendar entries with an access classs of public, private, or confidential, respectively. No access is provided to the calendar attributes. CSA_CHANGE_PUBLIC_ENTRIES, CSA_CHANGE_PRIVATE_ENTRIES, CSA_CHANGE_CONFIDENTIAL_ENTRIES - When set, gives the user access to update, and delete the calendar entries with an access classs of public, private, or confidential, respectively. No access is provided to the calendar attributes. CSA_VIEW_CALENDAR_ATTRIBUTES - When set, gives the user access to list and read the calendar attributes. CSA_INSERT_CALENDAR_ATTRIBUTES - When set, gives the user access to add calendar attributes. CSA_CHANGE_CALENDAR_ATTRIBUTES - When set, gives the user access to update, and delete the calendar attributes. CSA_ORGANIZER_RIGHTS - When set gives the user access rights to read, update, or delete the entry attributes for any calendar entry for which the user is specified as the organizer. CSA_SPONSOR_RIGHTS - When set gives the user the same access to read, update, or delete the entry attributes for any calendar entry for which the user is specified as the sponsor. CSA_OWNER_RIGHTS - When set gives the user the same access rights as the owner of the calendar. These rights permit the user to read, update, or add either the calendar attributes or the calendar entries, regardless of their access class. The default access rights are implementation specific. 3. next - Points to the access entry for the next calendar user in this access list. Now, here are the descriptions for the classification options for calendar entries: Classification NAME Classification - definition of the classification attribute. C DECLARATION #define CSA_ENTRY_ATTR_CLASSIFICATION \ &-//XAPIA/CSA/ENTRYATTR//NONSGML Classification//EN8 DESCRIPTION The access classification for the calendar entry. The default for this attribute is CSA_CLASS_PUBLIC. The valid values include: CSA_CLASS_PUBLIC CSA_CLASS_PRIVATE CSA_CLASS_CONFIDENTIAL The attribute can be modified by a call to csa_update_entry_attributes(). Support for this attribute is mandatory for implementations conforming to this specification. This attribute is a CSA_VALUE_UINT32 type of attribute. Phewww! I think that's it. - - Frank From owner-ietf-calendar Tue Jul 30 08:29:08 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA06200 for ietf-calendar-bks; Tue, 30 Jul 1996 08:29:08 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from feyuri.microsoft.com (feyuri.microsoft.com [131.107.243.53]) by imc.org (8.7.4/8.7.3) with SMTP id IAA06195 for ; Tue, 30 Jul 1996 08:29:03 -0700 (PDT) Received: by feyuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB7DF1.BB0751B0@feyuri.microsoft.com>; Tue, 30 Jul 1996 08:33:06 -0700 Message-ID: From: "Darren Shakib (Exchange)" To: "'ietf-calendar'" , "'Frank Dawson'" Subject: RE: Access Rights According to CSA Date: Tue, 30 Jul 1996 08:33:03 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Maybe I am wrong, but isn't this discussion a little premature. We have not defined any of the basic architecture for Calendaring, but we are discussing how to describe the access permissions via an undetermined protocol. Darren >---------- >From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] >Sent: Monday, July 29, 1996 2:24 pm >To: ietf-calendar >Subject: Access Rights According to CSA > >Folks, health warning...long note: > >Since I haven't formatted the XAPIA CSA document into a I-D like *.txt >format, >here is the text from that document on access rights etc. > >I don't know how this will format in an email message, so let me describe. >This >is the AccessList abstract data type from the CSA specification. I keep >quoting >scripture from it because it was defined as a consensus document from input >from Lotus, WordPerfect, Novell, Microsoft, DAC Associates, IBM, CE Software, >Campbell Services, Microsystems Software, Attachmate, Arabesque Software, and >SunSoft. It has been implemented in over four vendor products. Sorry for the >tendency to reuse. It's just good stuff, built on previous consensus > >The access list in the CSA is a linked list of a two-tuple of the calendar >user >and a mask of access rights. This access list is defined on a calendar basis >for determining access privileges to the calendar container by a number of >external users. The highest access right is the rights equivalent to the >calendar owner. Remember these are the access rights given an external user. >The individual objects or entries in a calendar have classifications that >match >the basic three levels made use of here (ie, PUBLIC, PRIVATE, and >CONFIDENTIAL). I think that this meets the requirements indicated in the >notes >so far. > >Here is the descriptive prose that describes a very good model for access >control (page 11-12, CSA): >The accessibility of a calendar to an individual user can be controlled by >the >access rights given that user. Access rights are paired with a calendar >user. >A calendar user can be an individual, group or resource. The access rights >are >maintained in an access list. The access list is a particular calendar >attribute. The access rights are individually controlled and can be >accumulated to define a range of accessibility of a user to a calendar and >its >entries. The access rights can also be specified in terms of one of three >access roles. These include the role of the owner of a calendar, the >organizer >of a particular entry within the calendar, and the sponsor of a particular >entry within the calendar. The owner role permits the user to do anything to >the calendar or calendar entries that the owner of the calendar can do. This >includes deleting the calendar, viewing, inserting, and changing calendar >attributes, adding and deleting calendar entries, and viewing, inserting, and >changing entry attributes. The organizer role permits the user to delete the >entry or view and change entry attributes for those calendar entries which >the >user is specified as the organizer. The organizer defaults to the calendar >user that created the entry. The sponsor role permits the user to delete the >entry or view and change entry attributes for those calendar entries which >the >user is specified as the sponsor. The sponsor is the calendar user that >effectively owns the calendar event or todo. In addition to these roles, an >access right can be set to limit access to free time searches, view, insert >or >change calendar attributes, or view, insert or change entries; dependent on >thei >r classification as public, confidential, or private. The entry >classification >acts as a secondary filter on accessibility. >Here is the definition of the access list abstract data type: >Access List >NAME > Access List - type definition for a list of access rights data value. >C DECLARATION > typedef struct CSA_TAG_ACCESS_RIGHTS { > CSA_calendar_user *user; > CSA_flags rights; > struct CSA_TAG_ACCESS_RIGHTS *next; > } CSA_access_rights, *CSA_access_list; >DESCRIPTION >A data value of this data type is used to define the access rights for a list >of calendar users. An access list is a list of access rights data >structures. >The access rights structure consists of the following components: >1. user - Identifies the calendar user associated with this access entry. >2. rights - Specifies the access rights for this user to this calendar. The >defined access rights include: >CSA_FREE_TIME_SEARCH >CSA_VIEW_PUBLIC_ENTRIES >CSA_VIEW_CONFIDENTIAL_ENTRIES >CSA_VIEW_PRIVATE_ENTRIES >CSA_INSERT_PUBLIC_ENTRIES >CSA_INSERT_CONFIDENTIAL_ENTRIES >CSA_INSERT_PRIVATE_ENTRIES >CSA_CHANGE_PUBLIC_ENTRIES >CSA_CHANGE_CONFIDENTIAL_ENTRIES >CSA_CHANGE_PRIVATE_ENTRIES >CSA_VIEW_CALENDAR_ATTRIBUTES >CSA_INSERT_CALENDAR_ATTRIBUTES >CSA_CHANGE_CALENDAR_ATTRIBUTES >CSA_ORGANIZER_RIGHTS >CSA_SPONSOR_RIGHTS >CSA_OWNER_RIGHTS >CSA_FREE_TIME_SEACH - When set, implies that the user will be able to access >the calendar entries for free time search. No access is provided to the >calendar attributes. >CSA_VIEW_PUBLIC_ENTRIES, CSA_VIEW_PRIVATE_ENTRIES, and >CSA_VIEW_CONFIDENTIAL_ENTRIES - When set, gives the user access to list and >read the calendar entries with an access class of public, private, or >confidential, respectively. No access is provided to the calendar >attributes. >CSA_INSERT_PUBLIC_ENTRIES, CSA_INSERT_PRIVATE_ENTRIES, >CSA_INSERT_CONFIDENTIAL_ENTRIES - When set, gives the user access to add the >calendar entries with an access classs of public, private, or confidential, >respectively. No access is provided to the calendar attributes. >CSA_CHANGE_PUBLIC_ENTRIES, CSA_CHANGE_PRIVATE_ENTRIES, >CSA_CHANGE_CONFIDENTIAL_ENTRIES - When set, gives the user access to update, >and delete the calendar entries with an access classs of public, private, or >confidential, respectively. No access is provided to the calendar >attributes. >CSA_VIEW_CALENDAR_ATTRIBUTES - When set, gives the user access to list and >read >the calendar attributes. >CSA_INSERT_CALENDAR_ATTRIBUTES - When set, gives the user access to add >calendar attributes. >CSA_CHANGE_CALENDAR_ATTRIBUTES - When set, gives the user access to update, >and >delete the calendar attributes. >CSA_ORGANIZER_RIGHTS - When set gives the user access rights to read, update, >or delete the entry attributes for any calendar entry for which the user is >specified as the organizer. >CSA_SPONSOR_RIGHTS - When set gives the user the same access to read, update, >or delete the entry attributes for any calendar entry for which the user is >specified as the sponsor. >CSA_OWNER_RIGHTS - When set gives the user the same access rights as the >owner >of the calendar. These rights permit the user to read, update, or add either >the calendar attributes or the calendar entries, regardless of their access >class. >The default access rights are implementation specific. >3. next - Points to the access entry for the next calendar user in this >access >list. >Now, here are the descriptions for the classification options for calendar >entries: >Classification >NAME > Classification - definition of the classification attribute. >C DECLARATION > #define CSA_ENTRY_ATTR_CLASSIFICATION \ > &-//XAPIA/CSA/ENTRYATTR//NONSGML Classification//EN8 >DESCRIPTION >The access classification for the calendar entry. The default for this >attribute is CSA_CLASS_PUBLIC. The valid values include: >CSA_CLASS_PUBLIC >CSA_CLASS_PRIVATE >CSA_CLASS_CONFIDENTIAL >The attribute can be modified by a call to csa_update_entry_attributes(). >Support for this attribute is mandatory for implementations conforming to >this >specification. >This attribute is a CSA_VALUE_UINT32 type of attribute. >Phewww! I think that's it. >- - Frank > From owner-ietf-calendar Tue Jul 30 09:03:00 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA06340 for ietf-calendar-bks; Tue, 30 Jul 1996 09:03:00 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by imc.org (8.7.4/8.7.3) with ESMTP id JAA06335 for ; Tue, 30 Jul 1996 09:02:58 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-7 #8694) id <01I7J37VIEN48Y57Z8@INNOSOFT.COM>; Tue, 30 Jul 1996 09:05:59 -0700 (PDT) Date: Tue, 30 Jul 1996 09:04:25 -0700 (PDT) From: Ned Freed Subject: RE: Access Rights According to CSA In-reply-to: "Your message dated Tue, 30 Jul 1996 08:33:03 -0700" To: "Darren Shakib (Exchange)" Cc: "'ietf-calendar'" , "'Frank Dawson'" Message-id: <01I7OFOA657I8Y57Z8@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-ietf-calendar@imc.org Precedence: bulk > Maybe I am wrong, but isn't this discussion a little premature. We have > not defined any of the basic architecture for Calendaring, but we are > discussing how to describe the access permissions via an undetermined > protocol. I agree 100%. And if something was in fact decided at this meeting, the first thing that needs to happen is for the minutes of the meeting to be posted to the list. As far as the IETF is concerned a meeting without any reported minutes effectively didn't happen. Ned From owner-ietf-calendar Tue Jul 30 09:05:12 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA06360 for ietf-calendar-bks; Tue, 30 Jul 1996 09:05:12 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from p2software.com (bill@ruby.p2software.com [146.115.104.49]) by imc.org (8.7.4/8.7.3) with SMTP id JAA06355 for ; Tue, 30 Jul 1996 09:05:10 -0700 (PDT) Received: (from bill@localhost) by p2software.com (8.6.11/8.6.9) id MAA04272; Tue, 30 Jul 1996 12:14:36 -0400 Date: Tue, 30 Jul 1996 12:14:35 -0400 (EDT) From: "William P. Spencer" To: ietf-calendar Subject: Re: Access Rights According to CSA In-Reply-To: <9607300130.AA9427@rtpnsi01.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@imc.org Precedence: bulk On 29 Jul 1996, Frank Dawson wrote: > ... long note ... Whew. Frank, that's alot of stuff in the CSA document. The access list is a great way of controlling access to a calendar. And it is very important to understand that users can take on different roles with respect to certain events, which might give them different access rights to those events. It did take me a while to map out the roles, and the access rights, and in general what's what. I'm still not sure I've got it all. Perhaps some concrete examples, using sponsors, owners, users, and calendars would be good. As a test of my understanding, here's one example. George is the organizer of a meeting to which John is invited, and is a confirmed attendee. If an agenda is included as a description of the meeting, and George wishes to change the agenda after having already scheduled it, he should be allowed to do that, and have the change appear in John's schedule. This should be true even if George (as a calendar owner) does not normally have MODIFY permission to John's schedule. This is what is set up with ORGANIZER_RIGHTS. I also had a question regarding what I call INVITE permission within SWTP. Does that correspond with the INSERT_ENTRIES access permission in the CSA documents? Physically, an insertion is what happens on the SWTP server when someone is invited to a meeting. While I was trying to do a 1-1 correspondance between SWTP and the CSA stuff, I just wanted to make sure there was an access permission that prevented an invitation from being sent. Bill From owner-ietf-calendar Tue Jul 30 09:18:10 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA06409 for ietf-calendar-bks; Tue, 30 Jul 1996 09:18:10 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from on.on.com (on.on.com [207.18.216.2]) by imc.org (8.7.4/8.7.3) with ESMTP id JAA06403 for ; Tue, 30 Jul 1996 09:18:07 -0700 (PDT) Received: from dev.on.com (dev.on.com [207.18.216.16]) by on.on.com (8.7.5/ON-1) with ESMTP id MAA04469 for ; Tue, 30 Jul 1996 12:18:32 -0400 (EDT) Received: from IP_TUNNEL/SpoolDir by dev.on.com (DaVinci Version: 4.11); 30 Jul 96 12:33:22 -0500 Received: from SpoolDir by IP_TUNNEL (DaVinci Version: 4.11); 30 Jul 96 12:33:03 -0500 To: ietf-calendar Subject: RE: Access Rights According to CSA In-Reply-To: X-DVS-Message-Class: 1 From: Jay Batson X-DVS-Conversation-ID: Date: 30 Jul 1996 12:21:26 -0400 X-DVS-Mail-Trail: Replied by: Jay Batson on 7/30/96 12:21PM X-Mailer: DaVinci SMTP 4.11 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <838740086@dev.on.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk On 7/30/96 at 11:33AM Darren Shakib said: >Maybe I am wrong, but isn't this discussion a little premature. We have >not defined any of the basic architecture for Calendaring, but we are >discussing how to describe the access permissions via an undetermined >protocol. Hear hear. And for the record, my take on the reasons CSA didn't go anywhere is that it was too big. Pretty soon you'll be sick of my battle cry, but it's: "Remember SNMP". Let's start with something *simple*. -jb ----- Jay Batson ON Technology Corp. jbatson@on.com 617-692-3591 Selfishness is not living as one wishes to live, it is asking others to live as one wishes to live. Oscar Wilde (1854-1900), From owner-ietf-calendar Tue Jul 30 09:56:15 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA06641 for ietf-calendar-bks; Tue, 30 Jul 1996 09:56:15 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.50.61]) by imc.org (8.7.4/8.7.3) with ESMTP id JAA06635 for ; Tue, 30 Jul 1996 09:56:07 -0700 (PDT) Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by mage.qualcomm.com (8.7.5/1.3d/8.7.2/1.10) with ESMTP id JAA26799; Tue, 30 Jul 1996 09:59:21 -0700 (PDT) X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <01I7OFOA657I8Y57Z8@INNOSOFT.COM> References: "Your message dated Tue, 30 Jul 1996 08:33:03 -0700" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Eudora [Macintosh version 3.0] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Tue, 30 Jul 1996 09:53:27 -0700 To: Ned Freed , "Darren Shakib (Exchange)" From: "John W. Noerenberg" Subject: RE: Access Rights According to CSA Cc: "'ietf-calendar'" , "'Frank Dawson'" , Anik Ganguly Sender: owner-ietf-calendar@imc.org Precedence: bulk At 9:04 AM -0700 7/30/96, Ned Freed wrote: >> Maybe I am wrong, but isn't this discussion a little premature. We have >> not defined any of the basic architecture for Calendaring, but we are >> discussing how to describe the access permissions via an undetermined >> protocol. > >I agree 100%. And if something was in fact decided at this meeting, >the first thing that needs to happen is for the minutes of the meeting >to be posted to the list. As far as the IETF is concerned a meeting without >any reported minutes effectively didn't happen. I just sent the minutes to Anik last night for his review. It is a lengthy tome. I apologize for the delay, but we did cover rather a lot of ground last week. With Anik's permission, or if there is a great hue and cry to see them sooner, I'll release the notes to the list without his review. john noerenberg jwn2@qualcomm.com -------------------------------------------------------------------- Once the land touches you, the wind never blows so cold again. You feel for the land like it was your child. When that happens to you, you can't be bought. -- W. P. Kinsella, "Shoeless Joe", 1982 -------------------------------------------------------------------- From owner-ietf-calendar Tue Jul 30 10:41:33 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA06854 for ietf-calendar-bks; Tue, 30 Jul 1996 10:41:33 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mail.ico.net (psycho.ico.net [204.94.129.66]) by imc.org (8.7.4/8.7.3) with SMTP id KAA06849 for ; Tue, 30 Jul 1996 10:41:31 -0700 (PDT) Received: from starbase.starfishsoftware.com by mail.ico.net with SMTP (5.65/950621.1) id AA11293; Tue, 30 Jul 96 10:45:47 -0700 Message-Id: <9607301745.AA11293@mail.ico.net> Priority: urgent Date: Tue, 30 Jul 1996 11:44:00 -0700 From: Shekhar Kirani Subject: RE: Access Rights According to CSA To: "'ietf-calendar'" X-Mailer: Worldtalk (NetConnex V4.00a)/MIME Sender: owner-ietf-calendar@imc.org Precedence: bulk Hi: I also support for posting the meeting minutes to the list as well as on the web. To reiterate, here are the bullet items that I would be interested in. 1) Completed IETF charter with all the milestone dates updated as was discussed in the summit. 2) The set of customers and requirements that were brain-stormed during the morning session of the meeting. 3) List of open issues that Dave put in on the board (such as naming, timezone, security etc) and the summary of the meeting. Once we have this set, we can start discussing about the most important things first such as the architecture and the open issues. Thanks, Shekhar Kirani Starfish Software ---------- From: Ned Freed[SMTP:Ned.Freed@innosoft.com] Sent: Tuesday, July 30, 1996 9:26 AM To: Darren Shakib (Exchange) Cc: 'ietf-calendar'; 'Frank Dawson' Subject: RE: Access Rights According to CSA > Maybe I am wrong, but isn't this discussion a little premature. We have > not defined any of the basic architecture for Calendaring, but we are > discussing how to describe the access permissions via an undetermined > protocol. I agree 100%. And if something was in fact decided at this meeting, the first thing that needs to happen is for the minutes of the meeting to be posted to the list. As far as the IETF is concerned a meeting without any reported minutes effectively didn't happen. Ned From owner-ietf-calendar Tue Jul 30 13:37:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA07735 for ietf-calendar-bks; Tue, 30 Jul 1996 13:37:09 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from inet-smtp-gw-1.us.oracle.com (inet-smtp-gw-1.us.oracle.com [192.86.155.81]) by imc.org (8.7.4/8.7.3) with SMTP id NAA07730 for ; Tue, 30 Jul 1996 13:37:03 -0700 (PDT) Received: from mailseq2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id NAA21998; Tue, 30 Jul 1996 13:41:29 -0700 Received: by mailseq2.us.oracle.com (8.6.13/37.7) id NAA01946; Tue, 30 Jul 1996 13:41:29 -0700 Message-Id: <199607302041.NAA01946@mailseq2.us.oracle.com> Date: 30 Jul 96 13:40:52 -0700 From: "Uppili Srinivasan" To: jbatson@dev.on.com Subject: RE: Access Rights According to CSA Cc: nakumar@us.oracle.com, ewinner@us.oracle.com, ietf-calendar@imc.org MIME-Version: 1.0 X-Mailer: ORACLE OFFICE (version 2.1.16.0.65) Content-Type: multipart/mixed; boundary="=_ORCL_1231591_0_11919607301442290" Sender: owner-ietf-calendar@imc.org Precedence: bulk --=_ORCL_1231591_0_11919607301442290 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Jay Bateson: I am in total agreement that we must get in synch. regarding the basic architecture for Calendaring before we get into other details. Independent of that, this is my take on CSA. Our experience with XAPIA-CSA is quite different from yours. We found the API to be simple. Implementing it for Oracle's calendaring service as well as using this API was quite straight forward, most importantly because we felt that the service abstraction captured by this API in almost all aspects was coherent and adaptable. This turned out to be a pleasant surprise to us since we didn't directly or actively influence its definition, but virtually all other major vendors (such as Microsoft, IBM, Lotus and Sun) did. I believe its usefulness comes from the fact that it captured the *common* architectural principles behind these diverse *working* solutions. It is my take that Internet standards distinguish themselves because they become standards after the proof of worth is established through robust *working* implementations. If we are to be consistent with this philosophy, CSA should remain an important source of reference in our effort. Thanks. ___________________________________________________________________________ Uppili Srinivasan | Oracle Corporation| Box 659210 |Phone: (415)506-3039 Internet: usriniva@us.oracle.com 200 Oracle Pkwy |Fax: Redwood Shores |X.400: c=us; a=telemail; p=oracle; o=oragate; s=usriniva CA 94065 | __________________|________________________________________________________ --=_ORCL_1231591_0_11919607301442290 Content-Type:message/rfc822 Date: 30 Jul 96 09:21:26 From:"Jay Batson " To:ietf-calendar, Subject:RE: Access Rights According to CSA X-Authentication-Warning:imc.org: majordomo set sender to owner-ietf-calendar using -f In-Reply-To: X-DVS-Message-Class:1 X-DVS-Conversation-ID: X-DVS-Mail-Trail:Replied by: Jay Batson on 7/30/96 12:21PM X-Mailer:DaVinci SMTP 4.11 Sender:owner-ietf-calendar@imc.org Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" On 7/30/96 at 11:33AM Darren Shakib said: >Maybe I am wrong, but isn't this discussion a little premature. We have >not defined any of the basic architecture for Calendaring, but we are >discussing how to describe the access permissions via an undetermined >protocol. Hear hear. And for the record, my take on the reasons CSA didn't go anywhere is that it was too big. Pretty soon you'll be sick of my battle cry, but it's: "Remember SNMP". Let's start with something *simple*. -jb ----- Jay Batson ON Technology Corp. jbatson@on.com 617-692-3591 Selfishness is not living as one wishes to live, it is asking others to live as one wishes to live. Oscar Wilde (1854-1900), --=_ORCL_1231591_0_11919607301442290-- From owner-ietf-calendar Thu Aug 1 18:56:44 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id SAA25317 for ietf-calendar-bks; Thu, 1 Aug 1996 18:56:44 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.50.61]) by imc.org (8.7.4/8.7.3) with ESMTP id SAA25312 for ; Thu, 1 Aug 1996 18:56:42 -0700 (PDT) Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by mage.qualcomm.com (8.7.5/1.3d/8.7.2/1.10) with ESMTP id TAA18796 for ; Thu, 1 Aug 1996 19:00:45 -0700 (PDT) X-Sender: jwn2@mage.qualcomm.com Message-Id: Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Eudora [Macintosh version 3.0] X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57 Date: Thu, 1 Aug 1996 18:35:08 -0700 To: ietf-calendar@imc.org From: "John W. Noerenberg" Subject: Minutes from Calendaring Summit, 7/24/96 Sender: owner-ietf-calendar@imc.org Precedence: bulk The minutes, at last. [Editor's note: I've used some text/enriched constructs to set off portions of the text, and make the sections more clear. I hope you will find this helpful. I also used some white space to set things off, in case the rich text is swallowed. If anyone has trouble with the message, please let me know and I'll send a text/plain version.=20 Actually, the only things I used were <, <, < and <. -- jwn2] The Day Begins Mark Szelenyi of Netscape began by explaining why he was opening the meeting instead of Erik Hahn. Erik's new baby boy was born late Tuesday night! As a result, Erik was otherwise occupied. Mark thanked Nancy Sullivan for handling the logistics for the meeting, and the attendees joined in applauding Nancy. Mark then turned the meeting over to Anik Ganguly of On Time. Anik's intro Anik Ganguly began by acknowledging the flap in the mailing list over the press releases. He asked that we put that behind us on concentrate on the task before us: organzing ourselves to work effectively for protocols that enable calendar and scheduling programs to interoperate for the benefit of their users. He proceeded to present the agenda for the rest of the day. He then introduced the first speaker. Ron Rassner's presentation (Mike Roszkowski, CNI) Mike Roszkowski of CNI, using notes from an article by Ron Rassner, talked about the impact the use of group and personal scheduling software can have on an organization. He pointed out the lack of standards limits the use of time management tools, but the existence of standards will promote interoperability, hence increasing the utility of time management tools for individuals and organizations. He observed the success of Internet email is the result of the wide acceptance and implementation of the protocols that underly email on the net. He continued that time management software needs the same kind of standards to achieve similar success. Mike recited the different effort that have been made to find a standard, and lamented their lack of success. He concluded with a plea to cooperate and collaborate for the good of our customers and our mutual benefit. Anik took the floor to introduce a number of representatives from companies that wished to make brief statements about the meeting today. Nina McIntyre (Lotus) Nina McIntyre of Lotus observed that today the number of email users and users of PIMS and group calender tools was roughly equal. Over the next couple of years the market for calendar tools is expected to grow to 4 times its present size. Because people use calendar management tools in different ways that may require more than one standard evolve for interoperability. She concluded by saying that Lotus was attending today because they want to focus on the technical work of building standards for interoperability. Ian Ferrel (Microsoft) Ian Ferrel of Microsoft stated briefly they were here because they want to participate in the technical work of this group. Mark Szelenyi (Netscape) Mark oberverd that Netscape is a company built on Internet standards.=20 Netscape is interested in entering the market for calendar management software, too. The importance of standards to Netscape, and their interest in this market led to their offer to have the meeting. Jari M=E4enp=E4=E4 (Nokia) Jari M=E4enp=E4=E4 of Nokia held up Nokia's new cellphone/Internet terminal.= =20 It is a handheld device intended not only to be a personal communicator, but a personal tool to help manage information, appointments, and other aspects of an individual's life. Because of the constraint of being a handheld device, it possesses only limited memory. Standardizing protocols greatly helps efficiently using the resources of a device like the new Nokia Internet communicator.=20 Besides the wireless protocols for cellular phones, there are other media that are useful for communication such as infrared, 2-way paging, etc that are not curently being considered as transports by the IETF.=20 Jari asked that other media be considered when developing standard communication protocols. Anik endorsed the idea that it is important to think of being able to work in the small space of phone operating system. Anik then introduced Keith Moore, one of the IESG Applications Area Directors, to talk about the Tao of the IETF. Anik reminded everyone that one of the goals of this meeting was to seek consensus to bring about standard calendar management protocols thru the IETF. Tao of IETF (Keith Moore IESG rep) Keith began by talking about the documents that describe how the IETF works. He referred to RFC 1718, The Tao of the IETF, as basic to understanding the process. In addition, RFC 1602 describes the how a standard evolves. The POISED working group (WG) is currently revising 1602. There is a set of documents, draft-ietf-poised.* that describe the methods of the IETF. To learn more about the workings of the IETF, Keith encouraged people to explore <. Because most of the attendees are unfamiliar with IETF processes, Keith proceeded to summarize the process. The IETF works in WG. A working group has a narrow focus with a limited lifetime. There is no formal membership process. Anyone can join a working group. You join by being interested in the problem and participating in finding its solution. Individuals join by coming to IETF meetings, and by joining the mailing lists where the majority of the discussion about a problem takes place. Individuals are members, not companies. Everyone has a right to be heard in the IETF. No voice speaks louder, simply because they come from a large organization.=20 Decisions in WG are made by rough consensus, and with working code. At this point several IETF regulars shamelessly demonstrated "rough" with interruptions to clarify important points they thought Keith omitted. Keith continued the IETF holds meetings 3 times a year. However, most work is done on the mailing lists which are part of each WG. At each meeting each working group meets for the "face time" that is necessary to work out the thorny issues that can't be settled on the mailing list. In addition, a WG may hold meeting outside of the IETF regular meetings, if it deems them necessary. Decisions of the WG can only be reached, however, on the mailing list to afford all participants the opportunity to contribute to the consensus of the group. IETF drafts are the ONLY route to an IETF standard, a standard RFC.=20 RFC drafts are posted to the RFC editor who maintains them in an archive maintained by the IETF Secretariat. The archive is located at ds.internic.net. Once a draft has been posted, an announcement is made to the ietf mailing list of its existence. RFC documents have a standard outline, but the structure is minimal. Every draft expires 6 months from its submission date. At its expiration an RFC will either advance to the next stage in the standardization process, be renewed for further work, or be retired. A draft can be the product of individual work or a collaboration. Drafts may be submitted either under the auspices of a WG or individually. Generally WGs take responsibility for drafts intended for standards track. Once a WG accepts responsibility for a document, its fate requires the consensus of the WG, and the WG, and by extension the IETF, is solely responsible for changes to the document. Keeping change control is important for maintaining the integrity of IETF documents. It is not possible for there to be two "authoritative" versions of an RFC. RFCs may reference specifications of other organizations, but it may only reference other RFCs which are advanced at least as far towards STD as it itself has advanced. The WG chair is the sole arbiter of when consensus has been reached.=20 Consensus is not a simple majority of the WG, but neither is unanimity required. Once consensus is reached, the WG submits the document to the Area Director(s) (AD) for consideration by the steering committee, the Internet Engineering Steering Committee (IESG). Once the IESG accepts the document it is submitted to the IETF mailing list for Last Call to allow the general readership of the IETF a last opportunity to comment on the document before it advances to the next stage. Last Calls are for a defined period. Once the period elapses and the IESG concludes no serious questions were raised about the document's validity, it advances to the next level. The WG chair is free to use any method which successfully establishes consensus in the group. If members of a WG disagree with the methods employed, they can appeal to the Area Director to intervene.=20 Generally, the AD will confer with the rest of the IESG to help resolve the dispute. If this fails, the members of the WG can appeal to the Internet Architecture Board to adjudicate the issue. A standards track document evolves through 3 stages, Proposed Standard, Draft Standard, and Standard. A Proposed Standard is a description of a protocol which the authors (or editors and collaborators) believe addresses the problem the WG group was organized to solve. An RFC advances to Dreft Standard when 2 independent, interoperable implementations of the protocol have been completed, and the WG has reached consensus the protocol is sufficiently mature and robust that is likely to find wide acceptance. An RFC advances to Standard, when there is significant implementation, successful use and broad acceptance of the protocol's utility to the Internet as a whole. Not all RFCs are standards track documents. There are RFCs which are designated as historic, informational, experimental, and Best Current Practice. The IETF also has a rich tradition of April 1st RFCs, which most people don't take seriously. Keith provided a short defintion of each of these other varieties of RFC. He noted that BCP RFCs are somewhat controversial within the community. They tend to be policy statements, with no formal interoperability requirement, and as such, my inhiibit the development of sound technical practice -- at least, that is part of the argument. Keith reviewed the IETF organization. In addition to IETF members, which is a highly informal body (this is why it makes no sense to speak of someone "close to the IETF"), there are some specific groups that guide the work of the IETF. Already mentioned is the IESG which consists of the Area Directors, the IETF chairman, who also chairs the IESG, and the RFC editor. The Internet Architecture Board, IAB, is a technical advisory board. The members role is to provide technical oversight for the IETF, as well as function as the court of last resort to adjudicate technical disputes. IANA, Internet Assigned Number Authority, is responsible making sure that protocol parameters are uniquely assigned to prevent conflicting use. The IRTF, Internet Research Task Force is a research body which performs deeper investigation into issues that cannot be quickly resolved by the IAB.=20 They make recommendations to the IAB. The Secretariat, which includes the RFC Editor, is responsible for maintaining IETF archives, the ftp server, web pages, and the like. The Internet Society (ISOC) is a chartered society responsible for approving the nominations to the IAB. At this point, Keith summarized where this group is in the process of forming an IETF working group. Working Groups require a charter, approved by the IESG, which outlines the scope of the working group (its focus), and the work it plans to accomplish. WGs also need mailing lists and archives. The charter should be written as narrowly as possible to insure that work is done in a timely way. WG that last more than a year generally are not productive. Today, this group lacks a charter, and the mailing lists and archives haven't been successfully established. The approval of the charter will take at a minimum a couple of weeks. The other things can be done more quickly. Someone from the floor asked how we could avoid the fate of the SNMPv2 working group. Keith felt that it broke down primarily because those responsible for the architecture of the protocol were unwilling or unable to recognize the difficulties the architecture posed for some class of devices for whom the protocol was supposed to work. He suspects that fate can be avoided in this group, because all the technical proposals he's reviewed show a great deal of commonality already. That suggests differences can be resolved without much rancor. Dave Crocker volunteered the resources of the IMC to provide the mailiing list home and document archive. The archive address will most likely be <. Dave mentioned that Keith had written a very useful article about managing mailing lists. A draft can be found at < Marketing review (Heather Rose, Netmosphere) After a short break, we resumed with Anik introducing Heather Rose of Netmosphere. Heather had volunteered to conduct the Marketing analysis that we wished to perform during the meeting. Heather proposed the following agenda for the discussion: * Who are customers * Requirements brainstorming * Priorities Who are the customers We developed the list below of kinds of customers: * Legacy, host-based users This includes not only individuals, but proxies for other individuals, plus resources (conference rooms, etc) that are scheduled with these systems. * Enterprise (dept vs IT vs individual) Within an enterprise different requirements arise. Different departments will choose different tools despite an enterprise wide mandate. * Consumers * Different access device There are a multitude of special purpose devices that offer calendars. * Mobile users People who carry their environment with them, but periodically connect to the "home office". * Heterogenous/location independent (nomadic) People who wander in an enterprise and need access to their calendar information from a variety of portals. * PDA access=20 A special class of different access device * Service provider -- one who publishes calendar data. Several varieties of service providers were listed: POP Publishing Business to customer purchase mediation Calendar information is provided in addition to other descriptive info * IT integrates w/base system * Calender/Schedule enabled applications * PIM + email integration * Person, place, thing - all these are entities that can be placed on a calendar * Network protocol for agents * ToDo discrete time interval vs. use of time While developing the list, we discussed the differences between Calendaring and Scheduling (C&S). Calendaring was described as the data placed on a calendar, and the manipulation of the information on the calendar. Scheduling is negotiation between calendars to place informaiton on them. As we were getting to the end of the list, we began to seque into brainstorming over marketing requirements for the interoperability. Requirements brainstorming * Interoperability of current and future Backward compatibility with existing systems is important. It has to facilitate data format exchange, the exchange of meeting notices, free/busy time searches, viewing calendars with differing levels of access, and different privileges for scheduling information on calendars. It must also be possible to synchronize a calendar that only periodically connects to the network. * Compatible with Internet transport The protocols have to be able to work over the Internet. * Should work with existing devicies such as PDAs, w/email, etc. * Compatible with proprietary LAN protocols Mustn't prohibt the ability to work over other transports beside TCP/IP. In addition, there must be a way to work under an interactive model, and via store&forward methods. We considered whether to match the customer classes identified with the requirements list, and decided to defer that to further discussion on the mailing list. We attempted to categorize the classes of users into smaller sets.=20 This did not produce any definitive result. We acknowledged that meeting access control requirements would be difficult to specify. Recognizing the foregoing were questions about the priority of requirements, we realized we had sequed into discussing priorities. Priority We continued discussion of priorities by asking "What is the most important issue to address?". The answer was to reduce the pain for users of using C&S tools. It was observed there are 14-16 million PIM and C&S users today. If we keep our goals simple, application developers can build on their existing work. The requirements for interoperability we've listed were acknowledged as being difficult problems. When muliple calendars exist for individuals, and responsibility for reconciling requests for time on particular calendars may be distributed across multiple calendars, finding the authoritative source of information about a calendar may become difficult. Anik summarized the discussion about the marketing issues for C&S products by saying there must be interoperability between users relying on Internet transport. Both interactive and store & forward models for data object exchange must be allowed for calendaring system users on a wide variety of devices. Users must have control over access to the information, and that it is secure. Finally, we must keep the protocols as simple as possible. This was rewarded with applause, and we broke for lunch. Tech Infrastrucure (Dave Crocker, Internet Mail Consortium) The first part of the afternoon was a discussion led by Dave Crocker about the technical considerations that will influence the design of the protocols. We began by listing a set of assumptions that were felt to be guiding principles. * Reuse where possible As much as possible we should strive to take advantage of existing work. Our design should be chosen with an eye towards use beyond our specific problem domain. * Variable throughput latency We cannot rely on a consistent level of service always being available for transmission. The procotols must have any built-in assumptions about the speed with with messages are delivered across the network. * Internittent connectivity Some classes of users of C&S protocols will have long periods of time where they have no live connection to the net. Negotiation and exchange can only take place when a connection is live, obviously. But utility of the data exchanged for the user must not end with the connection is broken. * Transport services There are a variety of transports offered by the Internet that we could use. We listed a number of them: TCP, UDP, Mail, Web, C&S-specific session layer. Some commented that TCP would be a more appropriate basis than UDP for a session-layer C&S protocol, but no conclusion was reached by the group. Besides transport protocols, we also listed other media besides traditional wired technologies that might be used for C&S transport.=20 These included cellular wireless protocols and Infrared. There may be other possibilities. One conclusion we reached is C&S protocols must be independent of the underlying transport. * Importance of security model Protecting the contents of a calendar store, and providing a means for authenticating access are necessary to meet the security requirements users will have for C&S products. We debated whether C&S protocols would need to incorporate a security model or whether security models proposed for other uses on the net would be sufficient. We weren't able to resolve this during the discussion, instead, concluding this will need to be taken up further down the path. * Independence of data objects We extended the idea of layer independence to further state that calendar data objects must be able to be represented independently of the transport protocols. This is closely analogous to the email model, where message structure is separate from message transport. This model has been very successful for email. Many at the meeting felt this works well for C&S, too, although not all embrace this idea. * Bits on the wire Dave reminded everyone that what the IETF does, and what we're planning to do is describe the representation and transfer of calendar objects across the net. We're not specify a representation model that must be used at the end points. In fact, this is all we can do. Going further is exceeding our goal of creating interoperability. Going further may unreasonably constrain choices for individual implementors. * Architecture vs. implementation This led into a lengthy discussion about architecture vs implemenation. It is our goal to design architecture, not specify the implementation individual organizations must follow. We identitfed a list of concepts that will influence our architectural choices: Data/Object Transport Agent/Role Commands Security Management Naming Time reference We spent some time examining what was meant by Agent/role. The system we choose will be made of entities that will perform specific functions. The entities are the agents, collectively, the functions performed by each agent define its role. There are a number of possible divisions of functions within a C&S system. Each division defines a different set of agents and roles. Dave proposed two divisions for us to consider: 1) User agent <<-> Transfer agent model 2) Global service <<-> client model 1) proposes the existence of "Calendar Islands" where calendar objects are stored and manipulated locally. A "Common Calender" protocol would be used to exchange information between islands. This model is analogous to the MUA <<-> MTA <<-> MTA <<-> MUA familiar in Internet email. Transfer agents exchange objects with other transfer agents or a user agent. A user agent exchanges information with an entity that consumes and generates calendar objects (for example, a person) and with a transfer agent. 2) proposes the existence of a global calender service with which client calendar agents would interact. Exchanging objects between clients are facilitated by exchanges between the respective clients and the global service. Distinctions between the models are subtle. The may affect how the architecture scales for an arbitrarily large audience, for example.=20 Differences between the models will lead to differences in persistence of calendar objects. We also spent a few minutes considering whether we should be including Directory Service in the issues that we should take up that affect C&S protocols. While we agreed that Naming conventions are important, the task of retrieving information about particular named objects is being taken up by other groups and is best left to them. We should be aware of their work to be sure any peculiarities of C&S are accounted for. Dave concluded our discussion with a recitation of the list of important architectural concepts (given above). He then turned the meeting back over to Anik. When we resumed, Anik introduced speakers for each of the six proposals for C&S protocols that had been invited to present at the meeting.=20 Each speaker summarized the salient points of their protocols, it's advantages and disadvantages. Some provided examples of the protocols' use. VCalendar (Frank Dawson, Versit) =46rank provided an overview of the vCalendar protocol. It is an for description for calendar objects. He outlined Versit's goals for vCalendar's implementation, design principles, some of the technical fundamentals in its design, and Versit's current plans for evangelizing the specification. Versit is principally interested in serving as an industry focus for interest in Personal Data Interchange (PDI). To foster interest they are developing seed code for PDI applications. The code available from Versit is unrestricted in use, and available for several platforms.=20 They are also researching applications for other media such as IR and smart cards. In general, they want transport independence for PDI. =46rank listed a number of design principles they used to guide the specification's development so far:=20 snapshot of personal calendar info event, todo support based on existing consensus vendor neutral transport independent easy to implement 3-4 day proto implementation quick demo He described technical fundamentals on which the specification were built: text-based self-delimiting abnf based syntax ISO 8601 date/time XAPIA, X/Open based calendar semantics either event or todo entity object applicable as clipboard drag/drop, body part, text file and he showed some examples of objects constructed with the specification. He anticipates Versit will make one more revision to the vCalendar specification before this fall, then hand the document over to the WG to further its progress towards a standard. Calendaring & Scheduling Interoperability Protocol (Anik Ganguly & J. Scott Benson) Scott Benson presented an overview of CSIP. It's goal is to achieve interoperability between existing C&S applications. The design assumed a store and forward transport model between systems, and no common name directory. The model for interoperability assumes that a particular product establishes a "calendaring domain." A protocol translation module between the domain CSIP would be responsible for transferring messages in and out of of the domain. Between domains, CSIP would be used to exchange messages. Scott walked us thru an example. No assumptions about the message delay were made, and it is not required that receipt of a mesage be confirmed. The protocol can be used for busy time searches, and for scheduling single events. However, it is limited for scheduling recurrint events or to-do items. No consideration was given for securing messages in transit, and the limits on access to the information in the calendar was not addressed. There have been two implementations of CSIP, and the protocol has been revised at least once. Internet Calendar Access Protocol (Pete O'Leary Clear Blue Network Systems, Inc.) ICAP is an access protocol for Calendar objects based on IMAP. It uses vCalendar as a data object definition, although vCalendar is not required as the object model. Like IMAP, it is designed for interactive use with considerable collaboration between user agent and transfer agent. ICAP enables retrieval of summary information, and it permits the existence of multiple stores for a particluar user. In addition it is possible to browse the stores of other users, as well as simultaneously post to many stores. Because it is an access protocol, it doesn't define the calendar object format, nor does it specify semantics for an event. It doesn't address store & forward between transfer agents, nor does it deal with asynchronous access to the store. Finally, ICAP assumes the existence of a directory service to find the names of objects. One question raised that since ICAP is so close to IMAP, why not simply use IMAP? Pete observed ICAP could be implemented as a set of capability extensions to IMAP. However, requiring C&S vendors to supply an IMAP server might be confusing. In addition, IMAP doesn't provide a satisfactory method for bounding a time interval which is needed for C&S data. Another observation was this could be met by developing an ICAP profile that would drive an IMAP server. The server would simply run on some other port than the standard IMAP port number. Some other issues to be resolved for ICAP is there is no definition of the serach mechanism. In addition, reliance on specifications for directory service and the calendar data object need to be resolved. The protocol specification is available in the Internet drafts directory: ftp://ds.internic.net/internet-drafts/draft-oleary-icap-00.txt Scheduling Wide-area Transport Protocol (Bill Spencer, Phase2 Software) Bill Spencer walked us thru a description fo SWTP. Its design requirements are similar to other C&S protocols. Bill described the format of messages exchanged in the protocol, the operations that are allowed and the assumptions about directory services and security. =46or each session a client performs a bind operation, a series of optional operations on a target calendar, and an unbind to close the session. In addition to operations to manage a particular users calendar, the protocol includes operations to add, modify and delete entities that can have calendars associated with them. The protocol also defines a set of security levels that define levels of access to calendars. The protocol is described by an internet draft:=20 ftp://ds.internic.net/internet-drafts/draft-spencer-swtp-00.txt. There was some discussion about the limitiations of character sets that were required for the objects defined for the protocol, and whether it would be possible to define the character set to be used to represent the data in the calendar object. Simple Scheduling Transport Protocol (Jay Hanna, On Technology) Jay Hanna introduced SSTP saying their goals were much the same as others in terms of the capabilitiies of the protocol: data neutrality and communications between arbitrary end nodes. In addition, they sought to keep the protocol as simple as possible for several reasons.=20 They wanted something easy for a diverse group to agree on, something whose design could be iterated quickly, and have low hurdles to adoption. The protocol follows the models of other widely adopted protocols like SMTP, HTTP, MIME and vCalendar. It assumes TCP for the transport, and this protocol must serve all possible devices. The protocol can be characterized as one with a rich data model, and a small set of operations. There are only 4 verbs defined in the protocol. All data objexts have a type and an implied method for manipulation. The objects are only defined for transfer, they don't imply a storage model. It is assumed that some server owns the objects. Jay listed the set of objects the protocol manipulates. He provided a couple of examples of protocol exchanges. Summarizing, Jay noted their goals were to provide product=20 interoperability, and allow for both client <<-> server and client <<-> interactions with the same protocol. Application/Property (Darren Shakkib, Microsoft) Darren Shakkib presented an object specification which is a MIME content-type, application/property. Using application/property, it would be possbile to define a set of related objects specific for calendaring applications. He defined the syntax for defining the attributes of a property and the range of values the attributes could take on. Darrin offered that using MIME as basic model vehicle for defining the objects allows reuse of a generic parser, at the same time allowing a wide varie