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 variety of object types. Plus, it would be possible to use any transport that was capable of transporting MIME objects. He proceeded to demonstrate how to create a profile using the syntax he proposed,=20 then defined 3 objects used in a calendaring application: an appointment, appointment request, and a appointment response object.=20 He finished his presentation with protocol examples using the objects he defined. Darrin was asked how his model handled the representation of recurring events. It was pointed out that relying on the time format of rfc 822 could lead to problems with interpretation. This concluded the presentation of technical proposals. To aid analysis of the proposals and decisions of how best to proceed reducing the proposals to a single consistent set of protocols, Dave Crocker requested that each presenter provide the group with a summary of how their ideas differed from the others, and for other proposals for C&S protocols not covered at the meeting. IETF Charter Anik then took the floor to summarize what had been accomplished so far: market requirements defined group desires to follow IETF process summarized the technical requirements for a protocol we have overlapping proposals to sort out In order to further the aims of the group, Anik wanted the group to consider the proposed IETF WG charter before it was submitted to the IESG. The consensus was the charter was promising, but the scope of the work too ambitious. We proceed to establish a set of six objectives for the WG, and establish some goals for completing them: 1. Charter 2. event and verb syntax 3. architecture/terms 4. Core objects 5. Object interaction 6. Integration The charter will be amended based the discussion today and submitted to the IESG as soon as possible (within a week or two). The WG deliverables are the definition of 4) Core objects specification, and 5) Object Interaction specification. Completing the deliverables will require we resolve the architecuture and terms discussions. Architecture includes the definition of a common language and approach for interaction for clients (and/or servers) in the C&S system. We must also address questions about security and transport models. These discussions should commence immediately. We outlines a set of objects that should be included in the core set: name, datetime, event. In addition we listed interactions between the objects that would have to be covered: event verbs, verb syntax, and a meta syntax used to describe the elements of the system. Dave Crocker announced that the mailing lists to support the necessary discussion had been created at imc.org (while he was listening to the technical presentations), and that he would provide the facility to archive the discussions and documents this group creates. =46rank Dawson and Darren Shakkib agreed to form an design team to reconcile the differences between different object syntaxes that had been proposed. They were confident they could work out the difference soon. =46or target dates in the charter, we agreed that a 1st draft of the Core objects could be made ready by 1-Oct-1996, with resolution on the architecture by the same date. A 2nd draft of the objects shoudl be ready by the San Jose IETF meeting (1-Dec-1996), and draft suitable for Proposed, along with a suitable draft for Object interaction would be ready for the Spring IETF meeting (15-Mar-1997). Differences and last integration of the two drafts would be completed by 1-Jun-1997, with the specifications reaching Proposed status soon after the Summer IETF meeting next June. With this agreement, Anik declared that we had reached our objectives for the meeting. He thanked everyone for their participation, and we applauded our work for the day. Respectfully submitted, 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 Fri Aug 2 21:04:54 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id VAA03933 for ietf-calendar-bks; Fri, 2 Aug 1996 21:04:54 -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 VAA03928 for ; Fri, 2 Aug 1996 21:04:51 -0700 (PDT) Received: from [205.214.160.102] (d79.netgate.net [205.214.160.115]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id VAA29652; Fri, 2 Aug 1996 21:17:23 -0700 (PDT) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 2 Aug 1996 17:36:02 -0700 To: "John W. Noerenberg" From: Dave Crocker Subject: Re: Minutes from Calendaring Summit, 7/24/96 Cc: ietf-calendar@imc.org Sender: owner-ietf-calendar@imc.org Precedence: bulk John, I would like to extend a very hearty 'well done' to you for your tour de force in note taking. Like, wow, man! Besides that, I think that your contribution to the repertoire of technical vocabulary will prove to have been fundamental. People worry about reliability on the Internet and now we have a name for the problem: intermittent Internet access is "internittent"... 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 Fri Aug 2 21:24:10 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id VAA03990 for ietf-calendar-bks; Fri, 2 Aug 1996 21:24:10 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from dolphin.automatrix.com (dolphin.automatrix.com [198.69.29.254]) by imc.org (8.7.4/8.7.3) with SMTP id VAA03982 for ; Fri, 2 Aug 1996 21:23:58 -0700 (PDT) Received: (from skip@localhost) by dolphin.automatrix.com (8.6.12/8.6.12) id AAA05829; Sat, 3 Aug 1996 00:28:25 -0400 Date: Sat, 3 Aug 1996 00:28:25 -0400 From: Skip Montanaro Message-Id: <199608030428.AAA05829@dolphin.automatrix.com> To: ietf-calendar@imc.org Subject: Looking for vCalendar/vCard-compatible applications... Reply-to: skip@calendar.com (Skip Montanaro) Sender: owner-ietf-calendar@imc.org Precedence: bulk As a starting point for tracking the work in this group I implemented a vCalendar export mechanism in the development version of Musi-Cal today and will be implementing vCard export for venues shortly. Over time I plan to export other formats as well. There's just one itty-bitty problem. I have no applications that import vCalendar or vCard so I have nothing to test my exporting. I know that Four11 exports vCard and that several sites on the Web (like Atlantic Records) export NowSoft's format. If I'm correct in my reading of the Four11 site, NowSoft should import vCards, but that's all I've discovered so far. The Versit site is replete with vCard information, but has little vCalendar stuff. Any pointers appreciated... Skip Montanaro | Check out: skip@calendar.com | Musi-Cal: http://concerts.calendar.com/ (518)372-5583 | Conference Calendar: http://conferences.calendar.com/ From owner-ietf-calendar Sat Aug 3 09:55:39 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA08285 for ietf-calendar-bks; Sat, 3 Aug 1996 09:55:39 -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 JAA08280 for ; Sat, 3 Aug 1996 09:55:37 -0700 (PDT) Received: from sv-2.philippe.com by mail.ico.net with SMTP (5.65/950621.1) id AA07320; Sat, 3 Aug 96 10:00:12 -0700 Message-Id: <2.2.32.19960803170009.0070c278@mail.ico.com> X-Sender: phil0001@mail.ico.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Aug 1996 10:00:09 -0700 To: "John W. Noerenberg" From: Philippe Kahn Subject: Re: Minutes from Calendaring Summit, 7/24/96 Cc: ietf-calendar@imc.org Sender: owner-ietf-calendar@imc.org Precedence: bulk John, your summary is outstanding. All the best -Philippe- 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 Sat Aug 3 11:12:52 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA08601 for ietf-calendar-bks; Sat, 3 Aug 1996 11:12:52 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from dolphin.automatrix.com (dolphin.automatrix.com [198.69.29.254]) by imc.org (8.7.4/8.7.3) with SMTP id LAA08596 for ; Sat, 3 Aug 1996 11:12:48 -0700 (PDT) Received: (from skip@localhost) by dolphin.automatrix.com (8.6.12/8.6.12) id OAA13471; Sat, 3 Aug 1996 14:07:33 -0400 Date: Sat, 3 Aug 1996 14:07:33 -0400 From: Skip Montanaro Message-Id: <199608031807.OAA13471@dolphin.automatrix.com> To: ietf-calendar@imc.org Subject: Accurate location information is a "must have" requirement Reply-to: skip@calendar.com (Skip Montanaro) Sender: owner-ietf-calendar@imc.org Precedence: bulk As the developer of a "calendar/schedule enabled application" I'd like to chip in one thing Bob Tatar and I brought up at the meeting that appears to be missing from the meeting minutes. There is a lot of attention paid to meeting times, but virtually no discussion of accurate location information. Bill Spencer treated timezones pretty carefully in the SWTP spec, and with recurring dates and all, it's pretty clear that they need to be carefully considered. However the only real location tags I remember seeing are the LOCATION properties in SSTP and SWTP (both free-format text fields) and the GEO field in vCalendar (which takes a lat/long tuple). Neither of these is adequate for a number of reasons: 1. Lat/long information isn't enough to infer timezones because people at various places in the world have adopted different ideas about the correct relationship between the Earth's lines of longitude and the clock on the wall. Simply put, there are some pretty daft people out there pushing the boundaries around. (Take a look at the world map in the front of your handy-dandy "Rand McNally Comprehensive World Atlas" if you think I'm kidding.) 2. Many applications that will want to interface to calendar systems (like our event calendars, Musi-Cal and the Internet Conference Calendar) will place as much emphasis on location as time. It would be a shame to think that that basic events could only travel one way (toward calendar systems) because loss of information prevents it going the other direction. 3. People will think up all sorts of different ways to enter information in free-format location fields so people trying to parse them will invariably run into snags. (Believe me, I squeek from experience.) 4. There seems to be an implicit assumption that events are entered one-by-one. We get information in huge batches sometimes, often with varying degrees of consistency. I have never seen concert or conference listings that indicated timezones. Most listings don't even give event times. It's impossible in most cases to add timezone information manually because of the sheer volume of data we deal with, and for most purposes it's pretty irrelevant. Inferring it from accurate city/region/country information is the only chance of being able to feed it to calendar software. 5. Finally, event location will take on greater and greater importance as scheduling reaches out beyond small groups to encompass organizations that are geographically dispersed. No longer will it be sufficient to indicate "Mozilla Room" as the sole indicator of a meeting's location. If I add a conference in Miami, Florida to my scheduler it's not too wacky to think it should automatically add a to-do for two weeks prior to the conference as a reminder to book my super-saver tickets. I welcome comments on this. Skip Montanaro | Check out: skip@calendar.com | Musi-Cal: http://concerts.calendar.com/ (518)372-5583 | Conference Calendar: http://conferences.calendar.com/ From owner-ietf-calendar Sat Aug 3 12:46:47 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA09104 for ietf-calendar-bks; Sat, 3 Aug 1996 12:46:47 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from srvr1.ralden.com (rincon.ralden.com [207.18.126.2]) by imc.org (8.7.4/8.7.3) with SMTP id MAA09099 for ; Sat, 3 Aug 1996 12:46:45 -0700 (PDT) Received: by srvr1.ralden.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB8139.32CD1280@srvr1.ralden.com>; Sat, 3 Aug 1996 12:42:14 -0700 Message-ID: From: "Roland H. Alden" To: "'ietf-calendar@imc.org'" Subject: RE: Accurate location information is a "must have" requirement Date: Sat, 3 Aug 1996 12:42:09 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk In response to Skip Montanaro's comments about location information I'd like to put forth a wacky idea. In addition to a "location," an "event", if it is a "meeting" often has an list of "attendees". Versit's vCard spec defines a format for "person" information which zeros in on location pretty well. In addition to the Time Zone and Latitude/Longitude info Skip mentioned, it has all the address structuring stuff needed to represent a physical address in a machine-readable way. I put forth two ideas here. One is that a vCard is a good representation for a meeting *attendee*. It can represent attendees which have electronically reachable calendaring agents (via email address or URL type pointers) and it can represent those who do not, which is a plus in certain scenarios. The second idea is that a vCard which represents a place, in lieu of a person, be used to represent the meeting *location* in whatever level of resolution is deemed useful. Internally it may just need to be a conference room name but as Skip points out, the further afield an attendee is, the more likely that details like address, and even an attached map, become useful in most applications, and mandatory in some. -Roland > From owner-ietf-calendar Sat Aug 3 12:52:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA09129 for ietf-calendar-bks; Sat, 3 Aug 1996 12:52:09 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from srvr1.ralden.com (rincon.ralden.com [207.18.126.2]) by imc.org (8.7.4/8.7.3) with SMTP id MAA09124 for ; Sat, 3 Aug 1996 12:52:08 -0700 (PDT) Received: by srvr1.ralden.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB8139.F41ED180@srvr1.ralden.com>; Sat, 3 Aug 1996 12:47:39 -0700 Message-ID: From: "Roland H. Alden" To: "'ietf-calendar@imc.org'" , "'skip@calendar.com'" Subject: RE: Looking for vCalendar/vCard-compatible applications... Date: Sat, 3 Aug 1996 12:47:37 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk >There's just one itty-bitty problem. I have no applications that >import >vCalendar or vCard so I have nothing to test my exporting. >Any pointers appreciated... Versit demoed vCard/vCalendar support at PC Expo using a pre-release of Lotus Organizer and OnTime. We don't have permission to pass these around, but we'll using them in demos at Networld+Interop next month, so if you demo with us there we'll have some infrastructure to help. We'll be adding trivial support for a calendar object in the vCard demo applet too, to facilitate some of the cut/paste scenarios and catch events off a web browser. I'll let you know when that's ready. From owner-ietf-calendar Sat Aug 3 13:52:44 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA09292 for ietf-calendar-bks; Sat, 3 Aug 1996 13:52:44 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from glaucus.cso.uiuc.edu (glaucus.cso.uiuc.edu [128.174.81.2]) by imc.org (8.7.4/8.7.3) with SMTP id NAA09287 for ; Sat, 3 Aug 1996 13:52:42 -0700 (PDT) Received: from resnick1.isdn.uiuc.edu by glaucus.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA10049; Sat, 3 Aug 1996 15:53:17 -0500 X-Sender: resnick@glaucus.cso.uiuc.edu Message-Id: In-Reply-To: <199608031807.OAA13471@dolphin.automatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 3.0] Date: Sat, 3 Aug 1996 15:56:43 -0500 To: skip@calendar.com (Skip Montanaro) From: Pete Resnick Subject: Re: Accurate location information is a "must have" requirement Cc: ietf-calendar@imc.org Sender: owner-ietf-calendar@imc.org Precedence: bulk On 8/3/96 at 1:07 PM -0500, Skip Montanaro wrote: >Subject: Accurate location information is a "must have" requirement I could not disagree more. >There is a lot of attention paid to meeting times, but virtually no >discussion of accurate location information. The reason for this, I hope to show in this message, is that *seperate* location information is not a needed component of a calendaring or scheduling protocol. As some of us brought up during the meeting, a location of an event is not a property of the event, but is much more simply expressed as a resource of the event, like an overhead projector or a computer. >Bill Spencer treated timezones >pretty carefully in the SWTP spec, and with recurring dates and all, it's >pretty clear that they need to be carefully considered. That's right. But this is because *time* is the important item of information. We often express times in local time and therefore need timezone information to convert it to something useful. But it is not location which is important here, but the ability to calculate absolute time. >However the only >real location tags I remember seeing are the LOCATION properties in SSTP and >SWTP (both free-format text fields) and the GEO field in vCalendar (which >takes a lat/long tuple). > >Neither of these is adequate for a number of reasons: > > 1. Lat/long information isn't enough to infer timezones because people > at various places in the world have adopted different ideas about the > correct relationship between the Earth's lines of longitude and the > clock on the wall. Simply put, there are some pretty daft people out > there pushing the boundaries around. (Take a look at the world map in > the front of your handy-dandy "Rand McNally Comprehensive World Atlas" > if you think I'm kidding.) But no location information solves this problem anyway, at least in the absense of a rather extensive database which would need constant updating. People not only have adopted different ideas about geographical time zones, but they change those ideas at assorted times in history. Location information by itself does nothing at all to determine time information. It is time zone information that must be encoded in the times of the event itself. > 2. Many applications that will want to interface to calendar systems > (like our event calendars, Musi-Cal and the Internet Conference > Calendar) will place as much emphasis on location as time. It would be > a shame to think that that basic events could only travel one way > (toward calendar systems) because loss of information prevents it going > the other direction. Again, as was said in the meeting, it is only an accident of the types of events you deal with that they always involve a location to which all of the participants must go. In most of the events I am involved with (like phone conferences), a location is not part of the event; there are several locations over which the event takes place. Certainly for to-do items, location is never at issue. Location is a property of a particular participant at a particular event. > 3. People will think up all sorts of different ways to enter information > in free-format location fields so people trying to parse them will > invariably run into snags. (Believe me, I squeek from experience.) That *may* argue for (as Roland mentions) location information being formally defined, but only in the attendees list for the event. It does not indicate that we need a machine parsable location for the event. > 4. There seems to be an implicit assumption that events are entered > one-by-one. We get information in huge batches sometimes, often with > varying degrees of consistency. I have never seen concert or conference > listings that indicated timezones. Most listings don't even give event > times. It's impossible in most cases to add timezone information > manually because of the sheer volume of data we deal with, and for most > purposes it's pretty irrelevant. Inferring it from accurate > city/region/country information is the only chance of being able to feed > it to calendar software. a) You need to find out the location of the venue for your sorts of events, and that is simply a participant in the event. b) Even with the city/region/country information, you will not be able to figure out what time the event takes place at without a current database of time zones and daylight savings time rules. Having tried to build such a thing for a long time, I can tell you from experience that you will find it impossible to keep one up to date and universal. > 5. Finally, event location will take on greater and greater importance > as scheduling reaches out beyond small groups to encompass organizations > that are geographically dispersed. No longer will it be sufficient to > indicate "Mozilla Room" as the sole indicator of a meeting's location. > If I add a conference in Miami, Florida to my scheduler it's not too > wacky to think it should automatically add a to-do for two weeks prior > to the conference as a reminder to book my super-saver tickets. Actually, the geographical dispersion argues more against having a single location field in an event. More and more people will be having teleconferences where locations will be multiple. I urge that we don't go down this path. Location for an event is a property of a participant. Making it a property of an event will cause many more problems than it will solve. pr -- Pete Resnick QUALCOMM Incorporated Work: (217)337-6377 / Fax: (217)337-1980 From owner-ietf-calendar Sat Aug 3 15:29:01 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id PAA09606 for ietf-calendar-bks; Sat, 3 Aug 1996 15:29:01 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from batnet.com (wombatnet.batnet.com [140.174.136.17]) by imc.org (8.7.4/8.7.3) with SMTP id PAA09601 for ; Sat, 3 Aug 1996 15:28:59 -0700 (PDT) Received: from [194.222.56.174] by batnet.com (4.1/SMI-4.1) id AB19380; Sat, 3 Aug 96 15:28:00 PDT Message-Id: <2.2.32.19960803222841.00680d04@batnet.com> X-Sender: skye@batnet.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Aug 1996 23:28:41 +0100 To: ietf-calendar@imc.org From: David Curley Subject: Usage Scenarios... Sender: owner-ietf-calendar@imc.org Precedence: bulk Ignoring content for a moment, the CSA exercise provided a number of useful lessons for generating an acceptable standard in this field based on existing industry practise. One of these was our listing in plain view during meetings a small (four to six) set of user scenarios that embodied all the major requirements. They were abstract enough not to preclude anyone's existing implementation, but realistic enough to serve as a checklist for each point discussed as we went through the material and built the spec. This had the additional benefit of freeing us from our previously overlapping, but incompatible, calendaring lexicons. We could just reject a proposal (etc.) by saying "that breaks scenario number three". Given the large number of participants in the current effort, and the confusion we're already seeing over terminology and how to express requirements, a reference document listing all the scenarios we are agreeing to address in this effort would be a useful tool for the group. I'll volunteer to start this off and find a home for it in the right document if I hear some support for it. Dave. From owner-ietf-calendar Sat Aug 3 16:59:54 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id QAA09883 for ietf-calendar-bks; Sat, 3 Aug 1996 16:59:54 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ics.uci.edu (mmdf@ics.uci.edu [128.195.1.1]) by imc.org (8.7.4/8.7.3) with SMTP id QAA09878 for ; Sat, 3 Aug 1996 16:59:52 -0700 (PDT) Received: from nma.com by q2.ics.uci.edu id aa02562; 3 Aug 96 17:04 PDT Received: from localhost by odin.nma.com id aa00369; 3 Aug 96 17:00 PDT To: David Curley cc: ietf-calendar@imc.org Subject: Re: Usage Scenarios... In-reply-to: Your message of "Sat, 03 Aug 1996 23:28:41 BST." <2.2.32.19960803222841.00680d04@batnet.com> Reply-to: Stef=calendar@nma.com From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <365.839116821.1@odin.nma.com> Date: Sat, 03 Aug 1996 17:00:22 -0700 Message-ID: <367.839116822@odin.nma.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk I will appear to be a voice from out in left field in this list, but I want to comment that documenting these scenarios is a critical part of what I call "PreStandards Work" where-in an abstract model of the domain of interest is developed and documented, and from which overall requirements can be drawn. Until such a model and requirements are in hand, it will not be possible to do any useful engineering of the desired Internet Protocols. Among the things to do is reconfirm that the scenarios so far identified are really the full set. I want to endorse this effort and offer to assist in any way I can. Cheers...\Stef >From your message Sat, 03 Aug 1996 23:28:41 +0100: } }Ignoring content for a moment, the CSA exercise provided a number }of useful lessons for generating an acceptable standard in this }field based on existing industry practise. } }One of these was our listing in plain view during meetings }a small (four to six) set of user scenarios that embodied all the }major requirements. They were abstract enough not to preclude }anyone's existing implementation, but realistic enough to serve }as a checklist for each point discussed as we went through the }material and built the spec. } }This had the additional benefit of freeing us from our }previously overlapping, but incompatible, calendaring lexicons. }We could just reject a proposal (etc.) by saying "that breaks }scenario number three". } }Given the large number of participants in the current effort, and }the confusion we're already seeing over terminology and how to express }requirements, a reference document listing all the scenarios we are }agreeing to address in this effort would be a useful tool for the group. } }I'll volunteer to start this off and find a home for it in the right }document if I hear some support for it. } }Dave. } } From owner-ietf-calendar Sun Aug 4 06:57:50 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id GAA14404 for ietf-calendar-bks; Sun, 4 Aug 1996 06:57:50 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from dolphin.automatrix.com (dolphin.automatrix.com [198.69.29.254]) by imc.org (8.7.4/8.7.3) with SMTP id GAA14399 for ; Sun, 4 Aug 1996 06:57:47 -0700 (PDT) Received: (from skip@localhost) by dolphin.automatrix.com (8.6.12/8.6.12) id KAA21552; Sun, 4 Aug 1996 10:02:28 -0400 Date: Sun, 4 Aug 1996 10:02:28 -0400 From: Skip Montanaro Message-Id: <199608041402.KAA21552@dolphin.automatrix.com> To: Pete Resnick , ietf-calendar@imc.org Subject: Re: Accurate location information is a "must have" requirement In-Reply-To: References: <199608031807.OAA13471@dolphin.automatrix.com> Reply-To: skip@calendar.com (Skip Montanaro) Sender: owner-ietf-calendar@imc.org Precedence: bulk I urge that we don't go down this path. Location for an event is a property of a participant. Making it a property of an event will cause many more problems than it will solve. That's fine with me as long as it's formally defined - that is I can tell the difference between meeting room, city, region and country. Having one catch-all location field with no syntax/semantics is not enough. Skip Montanaro | Check out: skip@calendar.com | Musi-Cal: http://concerts.calendar.com/ (518)372-5583 | Conference Calendar: http://conferences.calendar.com/ From owner-ietf-calendar Sun Aug 4 09:46:18 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA14894 for ietf-calendar-bks; Sun, 4 Aug 1996 09:46:18 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from srvr1.ralden.com (rincon.ralden.com [207.18.126.2]) by imc.org (8.7.4/8.7.3) with SMTP id JAA14889 for ; Sun, 4 Aug 1996 09:46:14 -0700 (PDT) Received: by srvr1.ralden.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB81E9.2D3B6190@srvr1.ralden.com>; Sun, 4 Aug 1996 09:41:56 -0700 Message-ID: From: "Roland H. Alden" To: "'ietf-calendar@imc.org'" Subject: RE: Accurate location information is a "must have" requirement Date: Sun, 4 Aug 1996 09:41:50 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk >I urge that we don't go down this path. Location for an event is a >property >of a participant. Making it a property of an event will cause many more >problems than it will solve. I appreciate why, in the case of a teleconference, location for the "event" itself is meaningless. However, for many events, such as a concert for instance, it is of paramount importance. I understand that different people may place different interpretations on a location. For one person "Madison Square Garden" may be very far away, for another it might be a short cab ride. However the location of the an event at Madison Square Garden *is* a "property of the event" and does not change, even if some people watch the event of TV (one could argue that the TV broadcast is a separate event). I think that "publishers" of such events have a legitimate need to record this information is a well-defined way. I don't think the fact that the information may be null or "overridden" by a specific participant argues that the information is not a valid property of some events. > > From owner-ietf-calendar Sun Aug 4 14:06:33 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id OAA16024 for ietf-calendar-bks; Sun, 4 Aug 1996 14:06:33 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from slip-3.slip.net (mail@slip-3.slip.net [204.160.88.17]) by imc.org (8.7.4/8.7.3) with SMTP id OAA16019 for ; Sun, 4 Aug 1996 14:06:30 -0700 (PDT) Received: from jon [204.162.173.217] by slip-3.slip.net with smtp (Exim 0.52 #1) id E0unAOo-0000wi-00; Sun, 4 Aug 1996 14:07:46 -0700 Message-ID: <32051344.37E5@sarrus.com> Date: Sun, 04 Aug 1996 14:16:52 -0700 From: Rafael Weinstein Reply-To: rafael@sarrus.com Organization: Sarrus Software, Inc. X-Mailer: Mozilla 3.0b4Gold (WinNT; I) MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Accurate location information is a "must have" requirement References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Responding to the discussion of whether location is a property of an event... We may lack the language to describe what it is where arguing over because "location" is no longer sufficient to describe the space of an event when the event itself may take place electronically or may not be an "meeting" our the traditional sense of the word. It seems clear to me that in order for an event description to be useful in an concrete sense it must contain at least three things: a) "What the event is" (Title, id#, or some other way of differentiating it from others) a) "When the event takes place" b) "How to attend the event" ...all in some meaningful way to _me_ as a participant or observer. b) "How to attend the event" may be -(Go to) Meeting Room A, ConHugeCo Inc. Mtn View Campus. -(Connect to) IRC #what's-the-deal-with-Bob-Dole's-Hair -(Turn on office) Video Phone, Channel 4539184947759393XAA -(Bring) Chips & Salsa to David Hasselhof's summer home, knock on the door and tell 'em "Mitch sent me" I realize that, in my flippancy (is that a word?), I've overlooked complete generality, but I'll claim that "events that take place at some exact time somewhere in the known universe" will at least be in the minority of those that people will tend to schedule. And while "location" may not be a good word, using the sense of "How to attend the event", I think it certainly is an essential property. Rafael From owner-ietf-calendar Sun Aug 4 14:46:32 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id OAA16162 for ietf-calendar-bks; Sun, 4 Aug 1996 14:46:32 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from cs.unh.edu (cs.unh.edu [132.177.4.32]) by imc.org (8.7.4/8.7.3) with SMTP id OAA16157 for ; Sun, 4 Aug 1996 14:46:28 -0700 (PDT) Received: from harvey.cs.unh.edu by cs.unh.edu (SMI-8.6/SMI-SVR4) id RAA23329; Sun, 4 Aug 1996 17:51:12 -0400 Received: by harvey.cs.unh.edu with Microsoft Mail id <01BB822C.F81C5980@harvey.cs.unh.edu>; Sun, 4 Aug 1996 17:47:13 -0400 Message-ID: <01BB822C.F81C5980@harvey.cs.unh.edu> From: "James L. Weiner" To: "'ietf-calendar@imc.org'" Subject: Wither directory services? Date: Sun, 4 Aug 1996 17:47:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-calendar@imc.org Precedence: bulk I noticed in the minutes a reference to "directory services." Having not = been there I wasn't sure of the context. It would seem to me a shame = that any scheduling standard wouldn't address the issue of its = implication to directory services - even if only at the level in which = you would address recommendations for MIME encoding. At some point there = will be standardization on formats for objects corresponding to person = and place (room) etc. and it would seem that their use in calendaring = should be considered in any design. In addition, there is also the issue = of object definition to allow a calendar to be "advertised" in a = directory. Roland Alden's note on the notion of "location" and "attendee" gives = examples of why these objects are important to scheduling. Given that = vCard is, I believe, also being put forth as a interchange format for = the "person" object for directory services, there is at least an = implicit reference. I believe the current work on LDAP will have a dramatic impact on = calendaring applications and it would be nice to see the deployment of = directories that list objects that can be usefully imported into future = calendaring applications. =20 From owner-ietf-calendar Sun Aug 4 22:47:47 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id WAA18056 for ietf-calendar-bks; Sun, 4 Aug 1996 22:47:47 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from killer-whale.automatrix.com (root@killer-whale.automatrix.com [198.69.28.254]) by imc.org (8.7.4/8.7.3) with SMTP id WAA18051 for ; Sun, 4 Aug 1996 22:47:45 -0700 (PDT) Received: from juniper.automatrix.com (juniper.automatrix.com [198.69.29.225]) by killer-whale.automatrix.com (8.6.12/8.6.12) with SMTP id BAA24907 for ; Mon, 5 Aug 1996 01:52:26 -0400 Message-ID: <32058E4F.48F8@calendar.com> Date: Mon, 05 Aug 1996 02:01:51 -0400 From: "Robert C. Tatar" Organization: Automatrix, Inc. X-Mailer: Mozilla 3.0b5aGold (Win16; I) MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: WHAT IS AN EVENT? (was Re: Accurate location information is a "must have" requirement) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk I've read with great interest the debate about "location" in calendaring software. Because the following is rather long, I've included some titles to summarize the key point of each section. EVENTS ARE "PEOPLE (and location) TOO" It is primarily because of Pete Resnick's strong reaction to Skip's message that I was inspired to write this though is not intended as an attack on Pete in any way. His perspective is very likely shared by many others who have been involved with "meeting scheduling" software development for some time and thus I feel a strong need to respond to his statements and perhaps clear up what may be a misinterpretation of our suggestions. Though Pete supports the importance of incorporating extensive descriptions of time, he misses some key characteristics of what we mean by "event". His final comment, however, actually supports our contention about the importance of a more general description of event: > Actually, the geographical dispersion argues more against having a single > location field in an event. More and more people will be having > teleconferences where locations will be multiple. IMPORTANCE OF CAPTURING THE CONCEPT NOW During the meeting on the 24th, it was mind-expanding to listen to the potential list of interoperability applications involving desktop systems, robots, hand-held devices and other machines. The goal in simple form was to have all of these devices exchange some rather simple, even trivial, information that I'll call an "event". While I am not convinced that we will ever reach complete semantic agreement on the term "event", it is difficult to imagine how this group will achieve the goals in the proposed charter until more consensus is reached on this term. I think much of the debate has to do with our different perceptions of what is implicitly included in the concept of an "event". Simply put, Skip and I (as well as a few others) are arguing for the use of a more general description of "event" than appears to be assumed by many current developers of scheduling software. We feel that thinking this through a bit more carefully now will greatly simplify future software development by avoiding the need for future software hacks and arbitrary, non-standard extensions to adapt some key concepts that were not included when they should have been. THE THREE FACES OF EVEnt (SUMMARY) We echo Roland Alden and Rafael Weinstein [in slightly different form] that three components: participants, location and time are prerequisites to the concept of an "event". We argue that these three components need to be addressed in the architecture and protocols developed by this group even if all such components need not be explicitly stated or precisely specified to adequately describe every particular "event". Clearly, the "what" of an event is also essential for the user (e.g. phone call, rock concert, IPO, wedding, etc.), but semantic interpretation of this information for the purpose of interoperability does not seem to be required by a general calendaring system (anyone have strong counterarguments about this?). Thus, unlike Rafael, I prefer to think of the "what" as an "event property" that can be handled transparently by the communications protocols. Our basic claim is that each component (who, when, where) is critical to the concept of an event within the scope of this proposed IETF and therefore these components require equal treatment. Furthermore, we suggest adaptability to a range of precision in each component. If we choose to allow a broad range of precision in temporal descriptions (e.g. 8:05:30 EST vs. Monday morning), then we should allow for a range of precision in specifing location (e.g. Mosaic Room, Netscape, Mountain View CA USA vs. Internet) as well as a range of precision in specifying participants (e.g. Benjamin Franklin & George Washington vs. anyone who can read). To imagine that the temporal component requires precise treatment, and the other components do not, misses the most fundamental nature of an "event" and would limit the ability of any calendar system to treat well only a small subset of possible events. EVENTS AS TRANSFORMATIONS OF MATTER-ENERGY IN SPACE-TIME To motivate a general interpretation of "event", I'll start with a physical model which I feel is consistent with Rafael's line of thought. A physicist might propose that an "event" is a transformation of matter or energy at a particular place and time. A relativist might rather say "a transformation of matter-energy at a point in space-time". This physical perspective suggests an inseparability of the three components of what we call an event. In our view, the participants are required to perform the "transformation". Furthermore, the blurring of the distinction between space and time arising from Einstein's observation about the consequences of an upper limit to speeds within the physical universe--which includes the Internet--is suggestive of the appropriateness of handling temporal and spatial components in a more democratic way. On the face of it, this rather abstract definition seems to work for many of the scenarios that arise in scheduling. We usually plan a "meeting" of people at a specific "time" and "place". (Actually, both start and end times are usually specified, but this does not impair the discussion--read on.) The process of a meeting usually results in the transformation of chemical energy into biochemical energy needed to arrange or rearrange words and ideas. Even "to do" events include: 1) a transformation of some type, 2) by an implied participant, 3) at an implied location. Examples such as "Walk the dog", "Send roses to Sue.", "Rework the employment contract to include free lunches.", "Call the boss.", "Read IETF-CAL.", involve explicity actions by at least one person with implicit locations such as: "outside in the woods", "at a florist", "in a workplace", "at a telephone", "on the Internet", respectively, notwithstanding these interpretations may only apply to my specific "todo" list and may also contain only vague specifications of "where". Clearly, some events have very precisely specified parameters of "who", "when", and "where". On the other hand, that some "events" may include a vague specification of "where" or "who", is no more significiant than than the fact that some anticipated events include relatively vague specification of "when", e.g. "have a meeting this morning", "go to a party this weekend", "take a vacation next summer", "get an inheritance after the king dies", or "read the responses to this message". Again (with emphasis) the fact that it may not be essential to specify a location in order to comprehend an event does not mean that explicit specification--no matter how inconvenient the language--would alter the event symantics, nor that some interpretation of location does not exist (as Rafael has observed). USE ONLY WHAT YOU NEED I want to make it clear that we are not proposing to require all "events" to use all the software structures implied by these three components (as apparently some have inferred), just that the structures "must be" available for use when needed. I am especially intrigued by Roland's suggestion of blending vCalendar and vCard specifications to at least partially achieve this and I think it could form a very useful starting point. MORE THAN A POINT The discussion so far refers to an event as if it occurs at a particular "point" of space-time, but this could be generalized as Pete observes to include a larger set of space-time points such as "Monday, Wednesday and Thursday at noon at Jack's", or "Every city in California on the Fifth of June", or a recurring series such as "Every Tuesday at 8PM at Madison Square Garden", or even a continuous distribution of points such as "From 8 AM to 9 AM in Dave's office", or "The entire State of New York on September 2". EVENTS ARE ANTICIPATED We don't usually schedule rainfall, accidents or heart attacks, even though these are "events" in the physical definition above. Therefore, the definition ought to include only "physical events" that we anticipate or plan. PARTICIPANTS ARE DIFFERENT FROM RESOURCES It's true that a system designed to switch on a coffee pot before breakfast does not involve a human participant. It does, however, involve a planned "participant" (the coffee pot) that is vital to the concept of this event. I agree with Pete that there may be other resources (e.g. slide projector, building with a room, etc.) that may be required for the activity to occur, but which can be included as parameters or "resources". LET'S SCHEDULE A VOTE As a working definition of event to guide our thinking, I propose "a planned activity of participants at a given place and time". Though perhaps the members of Automatrix are "new comers" to scheduling software, we feel that we've spent at least as much time thinking about software systems to handle planned events as many of the participants of this mailing list. I strongly urge that we go down this path. "Where" and "who" are as vital as "when" to the concept of an event. Even in the era of inflated school scores, getting 33% of a concept right is still failure. I think we can do much better than this and earn everyone an outstanding grade. :Bob rct@calendar.com From owner-ietf-calendar Mon Aug 5 09:07:34 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA22251 for ietf-calendar-bks; Mon, 5 Aug 1996 09:07:34 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from sundance ([208.194.141.4]) by imc.org (8.7.4/8.7.3) with SMTP id JAA22246; Mon, 5 Aug 1996 09:07:27 -0700 (PDT) From: ed.owens@slc.esltd.com X400-Received: by mta sundance.slc.esltd.com in /PRMD=esltd/ADMD= /C=US/; Relayed; Mon, 5 Aug 1996 10:05:53 +0600 Date: Mon, 5 Aug 1996 10:05:53 +0600 X400-Originator: ed.owens@slc.esltd.com X400-Recipients: owner-ietf-calendar@imc.org, ietf-calendar@imc.org X400-MTS-Identifier: [/PRMD=esltd/ADMD= /C=US/;sundance.s.684:05.08.96.16.05.51] X400-Content-Type: P2-1984 (2) Content-Identifier: 2f20df65.960805 Alternate-Recipient: Allowed Message-ID: <"2f20df65.960805085411-0700*/G=ed/S=owens/OU=slc/O=enterprise solutions limited/PRMD=esltd/ADMD= /C=us/"@MHS> To: owner-ietf-calendar@imc.org (Receipt Notification Requested) (Non Receipt Notification Requested) (Reply Requested) Cc: ietf-calendar@imc.org (Non Receipt Notification Requested) In-Reply-To: <2.2.32.19960803222841.00680d04@batnet.com> Subject: Re: Usage Scenarios... Importance: Low MIME-version: 1.0 Content-type: multipart/mixed; boundary="1z7kpp03jdbO6VvHAqZwZomo3q3NWcgh" Sender: owner-ietf-calendar@imc.org Precedence: bulk --1z7kpp03jdbO6VvHAqZwZomo3q3NWcgh Content-type: text/plain; charset="us-ascii" Dave, As one who was unable to attend the meeting, I would very much like to see the scenarios that were laid out (as well as the minutes as soon as they are available). Thanks to all for the good work that appears to have been done. Ed Owens --1z7kpp03jdbO6VvHAqZwZomo3q3NWcgh Content-type: text/plain; charset="us-ascii" ; Extra Body Part Created By EXM UA. [TEDIT] 7>6021402324255>262:28292=2;7<3=2=546543664=74000100005:0000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000001000001000041000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000;000000000000000000000000;?0100000<0054696=6573 204>657720526?6=616>0000000000000000000000000000000010000000000000000000 00000000000000??????0000000000000000000000000000000000000000000000000000 00000000000000;?000000000000000000000000;?010000000000000000040000000000 000000000000000000000000000000;?01000000;2?=010009;;????:>86????86090000 4<170100000;1115191<1?2225272:2<2>30323436383:3<3>3?4143444647494:4<4=4? 505253545657585:5;5<5=5?6061626365666768696:6;6<6>6?7071;?010001000000:0 3?0000:03?0000803?0000803?01000000003?0000000005000000000000000000000000 000000000000000000000000000000;?0100010000000000000000000000000000000000 000000000000000000000000000000000000000000000000;?0100010000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000;< ;<2803000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000 # --1z7kpp03jdbO6VvHAqZwZomo3q3NWcgh-- From owner-ietf-calendar Mon Aug 5 21:06:02 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id VAA25769 for ietf-calendar-bks; Mon, 5 Aug 1996 21:06:02 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ics.uci.edu (mmdf@ics.uci.edu [128.195.1.1]) by imc.org (8.7.4/8.7.3) with SMTP id VAA25764 for ; Mon, 5 Aug 1996 21:05:59 -0700 (PDT) Received: from nma.com by q2.ics.uci.edu id aa24092; 5 Aug 96 21:10 PDT Received: from localhost by odin.nma.com id aa03708; 5 Aug 96 20:57 PDT To: ietf-calendar@imc.org Subject: Re: WHAT IS AN EVENT? (was Re: Accurate location information is a "must have" requirement) In-reply-to: Your message of "Mon, 05 Aug 1996 02:01:51 EDT." <32058E4F.48F8@calendar.com> Reply-to: Stef=calendar@nma.com From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3704.839303824.1@odin.nma.com> Date: Mon, 05 Aug 1996 20:57:05 -0700 Message-ID: <3706.839303825@odin.nma.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk After struggling to understand the traffic on this list, I want to raise the level of discourse by at least one meta-level. I do not understand the reasons for excluding "WHAT" as a sibling of WHEN, WHERE, and WHO. I have long memories (perhaps ancient - try 1958) of information system designs where-in the inventors could not conceive of why any user would (and hence should not) ever want to do X, where X turns out soon to be the raging thing for users to do. MAJOR CAUTION: Our task is to generally enable, not disable. That means that we can specify how to do X, if you want to do X, and that we must specify things so that not wanting to do X will not disallow what you do want to do. Further, we are (I believe) in the business of providing strong typing tools for labeling objects to be stuffed into bit-bags called Calendar "objects". In the vernacular, this is called "tagging and bagging". I see little reason to distinguish schedule objects from calendar objects. So, we are in the business of defining ways to create attributes with values, give them labels, stuff them into and remove them from, labeled envelopes on opposite ends of exchanges. The better the labeling, the easier it will be to automate the processing. The more we must "sniff" object content with powerful Artificial Intelligence software to guess what what meaning might be contained, the greater the difficulty in achieving our goals. However, I we must remember that at times, structure becomes the enemy, especially when it causes a need for increased complexity in core infrastructures. In rather high level terms then, a calendar or schedule is just a time ordered collection of labeled calendar objects. They might be in the future, or in the past (in which case we call them HISTORY). I fail to see any relevance to suggesting that we are only interested in future events. Why would we want to disallow events to be recorded in history? I don't even see why we want to call our objects events and then argue about what is or is not included in the object class called "events". For my money, we are talking about the tagging and bagging of calendar objects for transfer via electronic media, over the Internet, among other possible transport modes and media. The key is that they must be useful in the Internet, whether they can also travel in other media or not. Take note the the Internet includes all the end points that are reachable via the Internet. You cannot be outside the Internet if you are attached to it. (Think hard about this;-)... The bagging part of our problem has already been determined for the Internet by its adoption of MIME as the primary transport envelope for Application Information Object Exchange, designed to facilitate protection of the object from damage by the transport facility, and to carry the labels which provide for strong typing of the contained information. I will argue that MIME envelopes can be carried in any elecronic medium and there-in provide the same labeling and protection against damage in transit, including EMail, HTTP, TCP, FTP, SneakerNet-diskettes, or most any other way you want to move electronic information. MIME has even been used for typing files in files systems with weak typing. It has also been used to define W-window widgets that accept MIME objests and do the right thing with them. So, the task I see to be completed is to decide how to structure calendar objects into MIME envelopes. I see little reason to engage in discussions at this point about how to limit what such an object might contain, or to decide that certain attribute values must be untagged. What I hope for is an Internet Technology system where I can stuff any MIME envloped calendar object into my calendar/scheudling/logging system, and see them "do the right thing with it" because of the labeling and the damage protection provided by MIME. Cheers...\Stef >From Robert C. Tatar's message Mon, 05 Aug 1996 02:01:51 -0400: } }I've read with great interest the debate about "location" in }calendaring software. Because the following is rather long, I've }included some titles to summarize the key point of each section. } }EVENTS ARE "PEOPLE (and location) TOO" } }It is primarily because of Pete Resnick's strong reaction to Skip's }message that I was inspired to write this though is not intended as an }attack on Pete in any way. His perspective is very likely shared by }many others who have been involved with "meeting scheduling" software }development for some time and thus I feel a strong need to respond to }his statements and perhaps clear up what may be a misinterpretation of }our suggestions. } }Though Pete supports the importance of incorporating extensive }descriptions of time, he misses some key characteristics of what we }mean by "event". His final comment, however, actually supports our }contention about the importance of a more general description of }event: } }> Actually, the geographical dispersion argues more against having a single }> location field in an event. More and more people will be having }> teleconferences where locations will be multiple. } [SNIP]... From owner-ietf-calendar Tue Aug 6 10:08:52 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA00892 for ietf-calendar-bks; Tue, 6 Aug 1996 10:08:52 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from [165.227.113.247] (phoffman.sc.scruznet.com [165.227.113.247]) by imc.org (8.7.4/8.7.3) with ESMTP id KAA00884 for ; Tue, 6 Aug 1996 10:08:50 -0700 (PDT) X-Sender: subs@imc.imc.org Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 Aug 1996 10:14:18 -0700 To: ietf-calendar@imc.org From: Subscription manager Subject: ADMINISTRIVIA: Who is using Skymail? Sender: owner-ietf-calendar@imc.org Precedence: bulk Greetings. Someone on this mailing list has all their email forwarded to their Skymail account. This means that, for every message over 5000 messages, we get the message bounced. If you are the person doing this, please consider not forwarding all your mail to Skymail and/or subscribing under an address that isn't forwarded. Thanks! --Paul Hoffman --Internet Mail Consortium From owner-ietf-calendar Tue Aug 6 22:54:45 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id WAA04050 for ietf-calendar-bks; Tue, 6 Aug 1996 22:54:45 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mail.pilot.net (ns.pilot.net [198.232.147.10]) by imc.org (8.7.4/8.7.3) with ESMTP id WAA04045 for ; Tue, 6 Aug 1996 22:54:43 -0700 (PDT) Received: from relay1.clorox.com (relay.clorox.com [168.189.64.36]) by mail.pilot.net with ESMTP id WAA19194; Tue, 6 Aug 1996 22:59:36 -0700 (PDT) Received: from maverick.clorox.com (shiva-tp10.clorox.com) by relay1.clorox.com with SMTP (CEMS 5.01/1.37.109.14) id AA126217802; Tue, 6 Aug 1996 23:03:22 -0700 From: Paul Rarey Message-Id: <960806225958.ZM13790@maverick.clorox.com> Date: Tue, 6 Aug 1996 22:35:34 -0700 In-Reply-To: Dave Crocker "Re: Access Control" (Jul 29, 14:29) References: "Your message dated Mon 29 Jul 1996 11:06:59 -0700" <9607291603.AA5929@rtpnsi01.raleigh.ibm.com> Reply-To: Paul Rarey X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996) To: Dave Crocker , Ned Freed Subject: Re: Access Control Cc: Frank Dawson , ietf-calendar Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@imc.org Precedence: bulk Thank-u Dave... I actually spent [ time ] (2much) assimilating & focusing on the various terms & views of this list, trying to find a way to speak my views such that they did't fall into one or more factional areas. At least your reconciliation terms let me now go back and do what I really need to do - raise h&(^ with this specification. But that's me - a small part of the - solution.... Best regards..., Paul S. Rarey The Clorox Company Ph: 510.271.2160 Systems Architecture & 1221 Broadway Fx: 510.208.1520 Electronic Munitions Oakland, Ca. 94607-4309 USA On Jul 29, 14:29, Dave Crocker wrote: > Subject: Re: Access Control >At 1:23 PM -0700 7/29/96, Ned Freed wrote: From owner-ietf-calendar Fri Aug 9 00:55:36 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id AAA20482 for ietf-calendar-bks; Fri, 9 Aug 1996 00:55:36 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ics.uci.edu (mmdf@ics.uci.edu [128.195.1.1]) by imc.org (8.7.4/8.7.3) with SMTP id AAA20477 for ; Fri, 9 Aug 1996 00:55:34 -0700 (PDT) Received: from nma.com by q2.ics.uci.edu id ae14934; 9 Aug 96 1:00 PDT Received: from localhost by odin.nma.com id aa08343; 9 Aug 96 0:05 PDT To: ietf-calendar Subject: A curiousity Reply-to: Stef@nma.com From: Einar Stefferud MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <8336.839574170.0@odin.nma.com> Date: Fri, 09 Aug 1996 00:05:20 -0700 Message-ID: <8341.839574320@odin.nma.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8336.839574170.1@odin.nma.com> Just out of curiousity, how does this relate to the work of the proposed IETF-Calendar WG? Cheers...\Stef ------- =_aaaaaaaaaa0 MIME-Version: 1.0 Content-Type: message/rfc822 Message-Id: <9608081725.AA3989@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 0203DAA84AC828C885256380005E718A; Thu, 8 Aug 96 13:24:38 To: stef From: John Christensen Date: 8 Aug 96 13:14:23 Subject: Your Support for vCalender at Networld/Interop (September 18-20) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="-- next item ----" This is the preamble of an RFC-1341 encoded, mixed message. ---- next item ---- Content-Type: Text/Plain Content-Transfer-Encoding: quoted-printable Versit's Personal Data Interchange team, having launched vCard (the Elec= tronic=20 Business Card) in April 1996, will launch vCalendar in September at the=20 Networld/Interop Trade Show in Atlanta.=20 vCalendar defines a format for electronic calendaring and scheduling. The= =20 vCalendar format allows for the capture of information normally stored wi= thin a=20 calendaring and scheduling application; such as a Personal Information Ma= nager=20 or a Group Scheduling product. vCalendar is intended to be used for excha= nging=20 information about event and todo types of calendaring and scheduling enti= ties.=20 An event is a calendaring and scheduling entity that represents a schedul= ed=20 amount of time on a calendar. For example, it may be an activity; such as= a=20 one-hour department meeting from 8am to 9am, tomorrow. A todo is a calend= aring=20 and scheduling entity that represents an action-item or assignment. For=20 example, it may be an item of work assigned to an individual; such as 'tu= rn in=20 travel expense today'. In today's business environment, this information is typically kept on a=20 paper-based day-planner or calendar. More and more, this type of informat= ion is=20 being also managed within electronic Personal Information Manager or Grou= p=20 Scheduling products. Prior to the introduction of vCalendar, users of suc= h=20 applications typically had to re-key the original information, often=20 transcribing it from paper day-planners, scraps of paper or electronic ma= il=20 messages. With the advent of vCalendar, this information can be exchanged= in an=20 automated and consistent fashion. The basis for this specification have their origin in openly defined, ind= ustry=20 specifications; such as the X.400 API Associations Calendaring and Schedu= ling=20 API (CSA). In addition, this specification has capabilities that were der= ived=20 from the experiences of multiple vendors' demonstrations. Versit provides a sample vCalendar implementation which is available at a= Web=20 site:=20 URL: http://www.ralden.com/vcdown.htm And, we offer technical assistance just by sending Email to: pdi@versit.com Information about Versit' "Personal Data Interchange" activities (includi= ng=20 vCard) can be found at: URL: http://www.versit.com/pdi I invite you to consider these specifications (copy attached) which we sh= all=20 offer to the IETF later this year. We offer an open distribution of these= =20 specifications and the shareware for vCard and vCalender support to the=20 industry at large in order to promote interpretability between differing=20 Calendaring and Scheduling products currently available in the market.=20 Companies who demonstrated prototype support at PC Expo in New York inclu= de:=20 =FA Lotus/ Organizer =FA Sundial/ Relish =FA FTP Software/ OnTime =FA Ring Zero/RingCentral=20 =FA Four11 Online Directory If, after consideration of these specifications, your company wishes to=20 endorse our vCalender or vCard formats, we would like to use your name an= d a=20 quotation for our Press Release in September at the Trade Show. Your supp= ort=20 could be as strong as;=20 "(Company name, person, title) endorses vCalendar/vCard and will embed th= e=20 standards into our future product(s)=20 (Product xxx)", /or/ "(Company name, person, title) endorses vCalendar/vCard and hopes to see = their=20 software vendors adding it to their next releases of their=20 calendaring/scheduling products" to as little as;=20 "(Company name, person, title) endorses vCalendar/vCard! It will be a boo= n to=20 Interoperability when widely adopted and/or it becomes a defacto standard= ." Please contact Dave Mabe: Phone: 914-766-1487 FAX: 914-766-9162 Email: mabe@gemini.= ibm.com /or/ John Christensen: Phone: 919-254-9557 FAX: 919-543-6822 Email:=20 christen@raleigh.ibm.com directly with any questions. We look forward to hearing from you.=20 - VCAL03.DOC <=3D=3DVersit's vCalendar Specification in Microsoft WORD f= ormat=20 (VCAL03.DOC) - VCAL03.TXT <=3D=3DVersit's vCalendar Specification in ASCII text forma= t=20 (VCAL03.TXT) ---- next item ----- ------- =_aaaaaaaaaa0-- From owner-ietf-calendar Fri Aug 9 05:52:41 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id FAA23567 for ietf-calendar-bks; Fri, 9 Aug 1996 05:52:41 -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 FAA23562 for ; Fri, 9 Aug 1996 05:52:39 -0700 (PDT) Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA28874; Fri, 9 Aug 1996 08:56:21 -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 IAA37692 for ; Fri, 9 Aug 1996 08:56:19 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA7859; Fri, 09 Aug 96 08:56:13 -0400 Message-Id: <9608091256.AA7859@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 7FFBC0A241E76C88852563810044E465; Fri, 9 Aug 96 08:56:13 To: ietf-calendar From: Frank Dawson Date: 9 Aug 96 8:50:11 Subject: A curiousity (sic) Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Stef: The Versit vCalendar work directly relates to the IETF Calendaring and Scheduling Working Group activities. Much of the initial work on the MIME media type for a calendaring object was done by the calendaring industry vendors that contributed to the vCalendar work. Most of the calendaring contributions to the IETF are based on the vCalendar work. However, it also goes beyond what the focus of an IETF working group charter might address. The attachment to your note highlights the fact that the Versit PDI Team is wrapping up their work on the vCalendar work, with the resultant publication of Version 1.0. The rationale being that (a) our work has reached a level of completion and (b) future work in this area will probably be carried on within groups such as the IETF Calendaring and Scheduling Working Group...when it and if it gets formed. As mentioned, the Versit PDI Team's vCalendar work has a scope that goes beyond that of the IETF. That is, it recognizes that a format such as vCard or vCalendar needs to be useful independent of the transport (eg, Internet protocols, wireless/PCS, IrDA, DSVD, LAN, desktop interactions, etc.) and meet the needs of a wide variety of applications. As such, we feel it VERY important that the vCalendar work be published so that these extra pieces of technology are not eclipsed or lost by the pending work of the IETF. I am not sure that the IETF is the most direct forum for capturing specifications for these other transports too. The Versit PDI Team has also successfully acted as a neutral forum for vendor demonstration of this technology. As we indicated at the July 24th Summit meeting, we are soliciting vendor participation in the Versit PDI Booth at Networld-Interop in September. I think that you would agree that the IETF is not really set up to do this. But they do benefit greatly from this early prototyping. It was a good question. You're good at that! Cheers. - - Frank Dawson From owner-ietf-calendar Wed Aug 14 23:40:14 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id XAA03865 for ietf-calendar-bks; Wed, 14 Aug 1996 23:40:14 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ics.uci.edu (mmdf@ics.uci.edu [128.195.1.1]) by imc.org (8.7.4/8.7.3) with SMTP id XAA03860 for ; Wed, 14 Aug 1996 23:40:07 -0700 (PDT) Received: by q2.ics.uci.edu id aa26502; 14 Aug 96 23:45 PDT Received: from nma.com by q2.ics.uci.edu id aa26338; 14 Aug 96 23:37 PDT Received: from localhost by odin.nma.com id aa15340; 14 Aug 96 22:47 PDT To: Paul Rarey cc: Dave Crocker , Ned Freed , Frank Dawson , ietf-calendar Subject: Re: Access Control In-reply-to: Your message of "Tue, 06 Aug 1996 22:35:34 PDT." <960806225958.ZM13790@maverick.clorox.com> Reply-to: Stef@nma.com From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15335.840088034.1@odin.nma.com> Date: Wed, 14 Aug 1996 22:47:15 -0700 Message-ID: <15337.840088035@odin.nma.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk Hi Paul -- I would be interested in chatting with you about what is wrong with what these behemoths are trying to do to each otehr and to the standards we need for the Internet. I think there is real value in the ASID and vCARD work that will apply to the development of a Simple Agent Transfer Protocol, which woudl serve to both transfer agents around the net, and to facilitate inter-agent commnunication too. My notion is that the extension/addition of sub-attribute tagging in ABNF as used inb RFC822/MIME, et al, headers is a critical thing whcih will enrich the power of these kinds of communication. What I am worried about is that the Netscape/Microsoft fight might derail this work, or at lease distract from it and slow it down. What do you think?-)...\Stef >From your message Tue, 6 Aug 1996 22:35:34 -0700: } }Thank-u Dave... } }I actually spent [ time ] (2much) assimilating & focusing on the various terms & }views of this list, trying to find a way to speak my views such that they did't }fall into one or more factional areas. At least your reconciliation terms let me }now go back and do what I really need to do - raise h&(^ with this }specification. } }But that's me - a small part of the - solution.... } From owner-ietf-calendar Wed Aug 21 15:47:26 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id PAA09437 for ietf-calendar-bks; Wed, 21 Aug 1996 15:47:26 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from tide19.microsoft.com (tide19.microsoft.com [131.107.3.29]) by imc.org (8.7.4/8.7.3) with SMTP id PAA09429 for ; Wed, 21 Aug 1996 15:45:52 -0700 (PDT) Received: by tide19.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB8F78.83796880@tide19.microsoft.com>; Wed, 21 Aug 1996 15:50:44 -0700 Message-ID: From: Lewis Geer To: "'Stef@nma.com'" , "'Paul Rarey'" Cc: "'Dave Crocker'" , "'Ned Freed'" , "'Frank Dawson'" , "'ietf-calendar'" Subject: RE: Access Control Date: Wed, 21 Aug 1996 15:49:13 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 57 TEXT Sender: owner-ietf-calendar@imc.org Precedence: bulk Einar, I think your idea of MIME encapsulation and sub-attribute tagging is a good idea, if I understand it correctly ("bag and tag"). And this is speaking as an engineer and not a behemoth ;-) This is the type of framework that Darren's draft attempts to set up (see ftp://ietf.org/internet-drafts/draft-shakib-mime-prop-00.txt). An alternative would be to use or modify the MIME-DIR draft in the ASID working group since it attempts to do very similar things for LDAP. I also believe Dave Crocker proposed such a scheme several years ago. If I understand correctly, the MIME encapsulation would give transport independence, while tagging the attributes of appointments will allow ease of parsing, extension, and searching in a variety of situations. Lewis >-----Original Message----- From: Einar Stefferud [SMTP:Stef@nma.com] Sent: Wednesday, August 14, 1996 10:47 PM To: Paul Rarey Cc: Dave Crocker; Ned Freed; Frank Dawson; ietf-calendar Subject: Re: Access Control Hi Paul -- I would be interested in chatting with you about what is wrong with what these behemoths are trying to do to each otehr and to the standards we need for the Internet. I think there is real value in the ASID and vCARD work that will apply to the development of a Simple Agent Transfer Protocol, which woudl serve to both transfer agents around the net, and to facilitate inter-agent commnunication too. My notion is that the extension/addition of sub-attribute tagging in ABNF as used inb RFC822/MIME, et al, headers is a critical thing whcih will enrich the power of these kinds of communication. What I am worried about is that the Netscape/Microsoft fight might derail this work, or at lease distract from it and slow it down. What do you think?-)...\Stef >From your message Tue, 6 Aug 1996 22:35:34 -0700: } }Thank-u Dave... } }I actually spent [ time ] (2much) assimilating & focusing on the various terms & }views of this list, trying to find a way to speak my views such that they did't }fall into one or more factional areas. At least your reconciliation terms let me }now go back and do what I really need to do - raise h&(^ with this }specification. } }But that's me - a small part of the - solution.... } From owner-ietf-calendar Wed Aug 21 18:54:56 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id SAA10155 for ietf-calendar-bks; Wed, 21 Aug 1996 18:54:56 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from hedgehog.mcom.com (h-207-1-136-17.netscape.com [207.1.136.17]) by imc.org (8.7.4/8.7.3) with ESMTP id SAA10150 for ; Wed, 21 Aug 1996 18:54:54 -0700 (PDT) Received: from vertigo ([207.1.136.91]) by hedgehog.mcom.com (Netscape Mail Server v1.1) with SMTP id AAA27949; Wed, 21 Aug 1996 18:59:47 -0700 Message-ID: <321BBE5E.7DE1@netscape.com> Date: Wed, 21 Aug 1996 18:56:46 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.0b5aGold (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: Lewis Geer CC: "'Stef@nma.com'" , "'Paul Rarey'" , "'Dave Crocker'" , "'Ned Freed'" , "'Frank Dawson'" , "'ietf-calendar'" Subject: Re: Access Control References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Lewis Geer wrote: > > I think your idea of MIME encapsulation and sub-attribute tagging is a > good idea, if I understand it correctly ("bag and tag"). And this is > speaking as an engineer and not a behemoth ;-) This is the type of > framework that Darren's draft attempts to set up (see > ftp://ietf.org/internet-drafts/draft-shakib-mime-prop-00.txt). An > alternative would be to use or modify the MIME-DIR draft in the ASID > working group since it attempts to do very similar things for LDAP. I > also believe Dave Crocker proposed such a scheme several years ago. Using the ASID MIME-DIR draft seems like a good goal. The two drafts are very similar, and the changes required to the ASID draft would be minimal. Speaking for ASID, we'd be happy to entertain suggestions for improving the MIME-DIR draft. Seems like it would be a shame to do something completely new, when we've already got something that is basically what you want, and could be perfect with a couple of tweaks. -- Tim From owner-ietf-calendar Thu Aug 22 02:10:16 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id CAA13526 for ietf-calendar-bks; Thu, 22 Aug 1996 02:10:16 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ics.uci.edu (mmdf@ics.uci.edu [128.195.1.1]) by imc.org (8.7.4/8.7.3) with SMTP id CAA13521 for ; Thu, 22 Aug 1996 02:10:15 -0700 (PDT) Received: from nma.com by q2.ics.uci.edu id ah03459; 22 Aug 96 2:15 PDT Received: from localhost by odin.nma.com id aa25128; 21 Aug 96 21:30 PDT To: Tim Howes , Lewis Geer cc: ietf-calendar Subject: Re: Access Control In-reply-to: Your message of "Wed, 21 Aug 1996 18:56:46 PDT." <321BBE5E.7DE1@netscape.com> Reply-to: ietf-calendar@imc.org From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25123.840688237.1@odin.nma.com> Date: Wed, 21 Aug 1996 21:30:38 -0700 Message-ID: <25125.840688238@odin.nma.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk Hmmm -- I guess I need not abjectly apologize for accidently letting my intended private message to Paul Rarey get loose on the calendar mailing list,and all;-)... BLUSH;-)... It seems that some good is coming of it, all be it unexpected;-)... So, I am delighted to see this interest bloooming for CALENDAR use of the ASID-DIR work! If we can just keep this on a roll now, my mission will soon be accomplished;-)... All be it by means of an accident. Maybe this is my reward for lurking around the places where neat new stuff keeps happening. This has been my role in EMail development since I got into it in 1975. For the story, see Chapter 7 on EMail in "Where Wizards Stay Up Late: The Origins of the Internet." Publisher is Simon & Schuster. ISBN: 0-684-81201-0 It is a good read;-)... Lots of good insights into the Internet. Let me know if your bookstore does not have it in stock;-)... I am in league with the authors, as colleagues... Onward;-)...\Stef >From your message Wed, 21 Aug 1996 18:56:46 -0700: } }Lewis Geer wrote: }> }> I think your idea of MIME encapsulation and sub-attribute tagging is a }> good idea, if I understand it correctly ("bag and tag"). And this is }> speaking as an engineer and not a behemoth ;-) This is the type of }> framework that Darren's draft attempts to set up (see }> ftp://ietf.org/internet-drafts/draft-shakib-mime-prop-00.txt). An }> alternative would be to use or modify the MIME-DIR draft in the ASID }> working group since it attempts to do very similar things for LDAP. I }> also believe Dave Crocker proposed such a scheme several years ago. } }Using the ASID MIME-DIR draft seems like a good goal. The two drafts are }very similar, and the changes required to the ASID draft would be }minimal. }Speaking for ASID, we'd be happy to entertain suggestions for improving }the MIME-DIR draft. } }Seems like it would be a shame to do something completely new, when }we've already got something that is basically what you want, and could }be perfect with a couple of tweaks. -- Tim From owner-ietf-calendar Thu Aug 22 04:06:28 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id EAA14363 for ietf-calendar-bks; Thu, 22 Aug 1996 04:06:28 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from psycho.ico.net (psycho_old.ico.net [204.94.129.66]) by imc.org (8.7.4/8.7.3) with ESMTP id EAA14358 for ; Thu, 22 Aug 1996 04:06:26 -0700 (PDT) Received: from yuki.kahn.ico.com (sv-2.philippe.com [204.94.135.83]) by psycho.ico.net (8.7.5/8.7.5) with SMTP id EAA02797; Thu, 22 Aug 1996 04:12:08 -0700 Message-Id: <3.0b11.32.19960822041156.0070bcdc@mail.ico.com> X-Sender: phil0001@mail.ico.com X-Mailer: Windows Eudora Pro Version 3.0b11 (32) Date: Thu, 22 Aug 1996 04:11:59 -0700 To: ietf-calendar@imc.org From: Philippe Kahn Subject: Re: Access Control Cc: Tim Howes , Lewis Geer , ietf-calendar Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@imc.org Precedence: bulk Team, actually, this does indeed sound very promising. Why reinvent the wheel? We at Starfish would support the initiative as it seems logical and in the best interest of the customers and the market. Good deal. -Philippe- http://www.starfishsoftware.com (check it out) At 09:30 PM 8/21/96 -0700, Einar Stefferud wrote: >Hmmm -- I guess I need not abjectly apologize for accidently letting >my intended private message to Paul Rarey get loose on the calendar >mailing list,and all;-)... BLUSH;-)... > >It seems that some good is coming of it, all be it unexpected;-)... > >So, I am delighted to see this interest bloooming for CALENDAR use of >the ASID-DIR work! If we can just keep this on a roll now, my mission >will soon be accomplished;-)... All be it by means of an accident. > >Maybe this is my reward for lurking around the places where neat new >stuff keeps happening. This has been my role in EMail development >since I got into it in 1975. For the story, see Chapter 7 on EMail in >"Where Wizards Stay Up Late: The Origins of the Internet." >Publisher is Simon & Schuster. ISBN: 0-684-81201-0 > >It is a good read;-)... Lots of good insights into the Internet. >Let me know if your bookstore does not have it in stock;-)... >I am in league with the authors, as colleagues... > >Onward;-)...\Stef > >>From your message Wed, 21 Aug 1996 18:56:46 -0700: >} >}Lewis Geer wrote: >}> >}> I think your idea of MIME encapsulation and sub-attribute tagging is a >}> good idea, if I understand it correctly ("bag and tag"). And this is >}> speaking as an engineer and not a behemoth ;-) This is the type of >}> framework that Darren's draft attempts to set up (see >}> ftp://ietf.org/internet-drafts/draft-shakib-mime-prop-00.txt). An >}> alternative would be to use or modify the MIME-DIR draft in the ASID >}> working group since it attempts to do very similar things for LDAP. I >}> also believe Dave Crocker proposed such a scheme several years ago. >} >}Using the ASID MIME-DIR draft seems like a good goal. The two drafts are >}very similar, and the changes required to the ASID draft would be >}minimal. >}Speaking for ASID, we'd be happy to entertain suggestions for improving >}the MIME-DIR draft. >} >}Seems like it would be a shame to do something completely new, when >}we've already got something that is basically what you want, and could >}be perfect with a couple of tweaks. -- Tim > > From owner-ietf-calendar Thu Aug 22 11:28:08 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA00515 for ietf-calendar-bks; Thu, 22 Aug 1996 11:28:08 -0700 (PDT) Received: from nugget.scr.atm.com ([206.100.186.2]) by imc.org (8.7.4/8.7.3) with SMTP id LAA00504 for ; Thu, 22 Aug 1996 11:27:56 -0700 (PDT) Received: from mailman.scr.atm.com (mailman.scr.atm.com [206.100.186.54]) by nugget.scr.atm.com (8.6.12/8.6.9) with ESMTP id KAA23222; Thu, 22 Aug 1996 10:30:55 -0700 From: izzy@nugget.scr.atm.com (Dr. Mark K. Joseph) To: howes@netscape.com Cc: lewisg@microsoft.com, fdawson@raleigh.ibm.com, ietf-calendar@imc.org Date: Thu, 22 Aug 1996 10:19:38 -0700 MIME-Version: 1.0 Message-ID: <19960822171938.izzy@scr.atm.com> References: In-Reply-To: <321BBE5E.7DE1@netscape.com> Subject: RE[2]: Access Control Organization: Netscape Communications Corp. X-Mailer: Emissary V2.01, by Attachmate Corp. X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calend ar using -f Status: R Content-Type: multipart/mixed; boundary="=_22tW39g.bO1996u.N17d000A.r08Y.19:006c2b" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk --=_22tW39g.bO1996u.N17d000A.r08Y.19:006c2b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, 21 Aug 1996 18:56:46 -0700 Tim Howes wrote: >Using the ASID MIME-DIR draft seems like a good goal. The two drafts are >very similar, and the changes required to the ASID draft would be >minimal. >Speaking for ASID, we'd be happy to entertain suggestions for improving >the MIME-DIR draft. > >Seems like it would be a shame to do something completely new, when >we've already got something that is basically what you want, and could >be perfect with a couple of tweaks. -- Tim > I would also agree with this. However, I remember the reciption that the ASID MIME-DIR draft received in Montreal. It was unfavorable ? I was in the meeting that got pretty hot discussing how the basic vCard format (similar to vCalendar format) that was being transported in the ASID MIME-DIR structure was all wrong. So if we proceed with ASID MIME-DIR those concerns brought up in Montreal should be addressed up front. --=_22tW39g.bO1996u.N17d000A.r08Y.19:006c2b Content-Type: application/vcard Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="MJOSEPH.VCF" Content-Description: The Sender's Signature BEGIN:VCARD NOTE: vCard Format: Version 2.0(Spec-4/29/96) REV:1996-08-07T18:34:06Z N:Joseph;Mark EmissaryA.FN:Mark K. Joseph, Ph.D. MAILER:Emissary 2.01 EMAIL;work;pref;internet:izzy@scr.atm.com EMAIL;home;internet:markjoseph@delphi.com TEL;WORK;PREF;MSG:(408) 471 - 3016 TEL;WORK;FAX:(408) 471 - 3010 TEL;HOME;FAX;MSG:(408) 475 - 8805 TZ:-0800 ORG:Attachmate Corporation;Internet Products Group TITLE:Software Architect LOGO;BASE64;gif: R0lGODlhuQAwAPcAAP///+/v7+fn597e3tbW1s7OzsbGxr29va2traWlpZycnJSUlIyMjISEhHt7 e3Nzc2tra2NjY1paWlJSUkpKSkJCQjk5OTExMSkpKSEhIRgYGBAQEAgICOfe1oR7c2NaUjEpIe/n 3s7Gva2lnIyEe0pCOaWcjJyUhL2tjFpSQox7WntrShgQANbGnM69lMa1jO/WlJSEWta9e8ata3tr Qq2UUqWMSpR7OYRrKTkpAKWchIR7Y+/erefWpa2ca6WUY4x7SpyEQsalSr2cQmNSIbWUOYxzKaWE KYRrIZx7Ie+9KUo5CGtSCMaUAKV7AFpCAP/33u/nzt7WvdbOtb21nK2ljJSMc4yEa//vvXtzWnNr UmtjSufWnL2te//nnFJKMe/WhEpCKaWUWufOe861Y8atWoRzOXNjMe/OY9a1SqWMOffOUjEpEMal Oe/GQpR7KVpKGL2cMd61Oee9MffGMdatKa2MIc6lIe+9Ib2UGMacGO+9GMacENalEJRzCLWMCK2E CN6tCNalAIxrAGtSAEo5AMa9nLWla9a9Y72lUvfWY3trMbWcQnNjKefGUu/OUt69SufGSpyEMda1 Qt69QqWMMc6tOffOQta1OZyEKcalMe/GOc6tMb2cKd61KVpKEL2cIe/GKYxzGNatIbWUGN61GFJC CK2MENatEO+9EL2UCM6lCO+9COe1CO+9AOe1AN6tAL2UALWMAJx7AJRzAHNaAN7Wtb21lK2lhP/v rYR7UufWjM69c8a1a/fee2NaMe/Wc5yMSvfec6WUSufOY9a9Uox7McatQu/OSoRzKa2UKe/GIYxz EOe9GN61EIRrCN61CNatAM6lAIRrAHtjACkhAP/3zu/nvdbOpbWthN7OhNbGe7WlWs69Y1JKIXNj GL21hKWca/fnjN7Oc0I5CMbGvf//797ezsbGtbW1pefnzpSUhEpKQtbWvcbGrb29pYSEc2trWpSU e1paSnt7Y1JSQmNjSkJCMVpaQiEhGEJCKTk5IRgYCBAQAAgIAAAAACwAAAAAuQAwAAAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN hxH+6dyZ4WbBnTt93gQK1CDRfz+Jljx604JSmAGO6kSQtChBpiSx1qzw9OUEqf82VA16tatIrTS5 Wn0JVudYt2XXnjU706nckwcIRm1LFcCBA0cN/BV89C8BvQ3U6qygICECu/8qpHuLFEDOfxkaDxz8 N4DABzovFCA4QO2FvgULRMgAdIKBzQcuEB1ccMDXxYc35h0ou21l38ArCATse0JBB20jDDxaQKpn AEQNIDgqFsAGqQRB+24MfOAAvh+B//8WD1b4dPEPBl73XZ08XKLIpVZYT12gYt/ffQtUAPxCx/w7 OcAAUdy5d5RwBgp0W3DQuVeggWAJBKF+zaHHUW9kaYVWg3Jp+NRRFzRAX1AGijUhWArwB5R/AAiA 1X2VSUjUAAKNGGNGWHl4F1oO9NjjbhwGddlOxskIVDog1shUfUHu5N9eQElwQANUUhkXWZDBBUCF OwHZZJEYcamTBvYRxYCRZC1HV0EHQIAdWgpUIKecKnaolFbErRXfTsIZlM6CVsE4EIyc5ZnmRawB 1RcBOdK1YQE2vrkmZVe6hRaeRPVZp34AZBnjhBpd+qGjZkUa4YZGmbWkql0ZQJQFTXL/Kiia5GV0 nnvpbagVjDxhaOmkld64qp1rGRpZW77C5amaCWJkqn66dpUkrUjBmamoRWGbprGe/uMAs2TBOBoA yWYF6lEZ/EXtAwaIqWWslhHVE7WbvjvsoVq52h24yhK1wV+3hkbQnHNiFDCubVG7WGACJTvetffa eyerxYr3HHYA8PorUBkI4O4/CWSskwMVfAeRjf8eIJjKkWr8MMTufUZerhSTWLOWxrocIQB7KmVs wvbxnIEGNzJ0lGYE1fuPixhrXMGAYNlIo8i+sajtxvi2mqnDQMcKl9JoCeeAbUUrpDRCR0XQc5qJ AiWcdvA1Wd2WbQF5dbU3x5gzuVIV/1CvcgAcrGUAzwI+UHqa9SkUAhBU4MC4DSFAsgOoxcQABRM0 8NxFB0x+plCghy766KSXbvrpqKeuukQBSOBjj40V4MDcEfno5egkz7u6QhfQ+E96iv+DAUVRTb2Q t0tBftAGfSpu0QFgzkRVcwJ9Dt1otwMwQPYE5aTXc7cXTSP3r5E2nEEFeEk9Qs0hDQGbBuVGAPg/ Za48QR4TtJsBm/slkPEYkU1BpmMdAQokKgGYXULCMpCcRCAC0wFSTspXgAxUQDa7Kd76AKAA1igA OQ3wDlIu+L8NZKB8RtFdQTawgIyh5joGuMBXBgAaxQFGQoYDQAa+9Q/rCTAD3gNAAP9A4xnk4ch5 1smAfxrwqcYQbYFIi8oCAmCy5RgOORMIwG7Wx5WBNIdy0NncP3ynu39ULjtlq1F1XCWQkP3DOBi4 gHL+AbkBCcSCy2lMVAYygQT8gwPQ6VNPQJaxjfwjN2pSUvX+cQANIDFpN4rKty5Au3/0DzNX0eM/ kAYd/4CGj/9IxwYMt0GDdPEgS1NQjAYkgAZxUFjpgc77RCajskjokiGknUWC6EVLSihxaUwKQb4i Ib/tBylTKyUB4yXEY0roAZp5V8N8eRDkDGw5ywleT77juwlArjJVhE5jZLMApG0SAHa8SgNiiSNd ZmADAyCAA1j0SioOD23shM6ZviOqgefIZm6UJAhyCnAB0ABSQn3a5Li8dwDD/Y6eRukTQbFpmUre 8TfpCNkrf7kcB5Bpk8/hD0Ih2sP7VYQCPYpeAwaggAvcTkRnHIgAIrBO1ISwRRnYnANyuNKffKsB KlUPAFfjJQ18SyGXyeLAXEqaozagldaBaiCZ1z853XFzC+jLDn9y09159Xj9s8gAIPrVshYkJ2GV yHcCQFazupUjBwDgW+dK17qWNSAAOw== URL:http://www.atm.com LABEL;WORK;PARCEL;POSTAL;DOM;QUOTED-PRINTABLE:140 Du Bois Street, Suite C=0A= Santa Cruz, CA 95060 END:VCARD --=_22tW39g.bO1996u.N17d000A.r08Y.19:006c2b-- From owner-ietf-calendar Thu Aug 22 11:33:56 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA00515 for ietf-calendar-bks; Thu, 22 Aug 1996 11:28:08 -0700 (PDT) Received: from nugget.scr.atm.com ([206.100.186.2]) by imc.org (8.7.4/8.7.3) with SMTP id LAA00504 for ; Thu, 22 Aug 1996 11:27:56 -0700 (PDT) Received: from mailman.scr.atm.com (mailman.scr.atm.com [206.100.186.54]) by nugget.scr.atm.com (8.6.12/8.6.9) with ESMTP id KAA23222; Thu, 22 Aug 1996 10:30:55 -0700 From: izzy@nugget.scr.atm.com (Dr. Mark K. Joseph) To: howes@netscape.com Cc: lewisg@microsoft.com, fdawson@raleigh.ibm.com, ietf-calendar@imc.org Date: Thu, 22 Aug 1996 10:19:38 -0700 MIME-Version: 1.0 Message-ID: <19960822171938.izzy@scr.atm.com> References: In-Reply-To: <321BBE5E.7DE1@netscape.com> Subject: RE[2]: Access Control Organization: Netscape Communications Corp. X-Mailer: Emissary V2.01, by Attachmate Corp. X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calend ar using -f Status: R Content-Type: multipart/mixed; boundary="=_22tW39g.bO1996u.N17d000A.r08Y.19:006c2b" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk --=_22tW39g.bO1996u.N17d000A.r08Y.19:006c2b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, 21 Aug 1996 18:56:46 -0700 Tim Howes wrote: >Using the ASID MIME-DIR draft seems like a good goal. The two drafts are >very similar, and the changes required to the ASID draft would be >minimal. >Speaking for ASID, we'd be happy to entertain suggestions for improving >the MIME-DIR draft. > >Seems like it would be a shame to do something completely new, when >we've already got something that is basically what you want, and could >be perfect with a couple of tweaks. -- Tim > I would also agree with this. However, I remember the reciption that the ASID MIME-DIR draft received in Montreal. It was unfavorable ? I was in the meeting that got pretty hot discussing how the basic vCard format (similar to vCalendar format) that was being transported in the ASID MIME-DIR structure was all wrong. So if we proceed with ASID MIME-DIR those concerns brought up in Montreal should be addressed up front. --=_22tW39g.bO1996u.N17d000A.r08Y.19:006c2b Content-Type: application/vcard Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="MJOSEPH.VCF" Content-Description: The Sender's Signature BEGIN:VCARD NOTE: vCard Format: Version 2.0(Spec-4/29/96) REV:1996-08-07T18:34:06Z N:Joseph;Mark EmissaryA.FN:Mark K. Joseph, Ph.D. MAILER:Emissary 2.01 EMAIL;work;pref;internet:izzy@scr.atm.com EMAIL;home;internet:markjoseph@delphi.com TEL;WORK;PREF;MSG:(408) 471 - 3016 TEL;WORK;FAX:(408) 471 - 3010 TEL;HOME;FAX;MSG:(408) 475 - 8805 TZ:-0800 ORG:Attachmate Corporation;Internet Products Group TITLE:Software Architect LOGO;BASE64;gif: R0lGODlhuQAwAPcAAP///+/v7+fn597e3tbW1s7OzsbGxr29va2traWlpZycnJSUlIyMjISEhHt7 e3Nzc2tra2NjY1paWlJSUkpKSkJCQjk5OTExMSkpKSEhIRgYGBAQEAgICOfe1oR7c2NaUjEpIe/n 3s7Gva2lnIyEe0pCOaWcjJyUhL2tjFpSQox7WntrShgQANbGnM69lMa1jO/WlJSEWta9e8ata3tr Qq2UUqWMSpR7OYRrKTkpAKWchIR7Y+/erefWpa2ca6WUY4x7SpyEQsalSr2cQmNSIbWUOYxzKaWE KYRrIZx7Ie+9KUo5CGtSCMaUAKV7AFpCAP/33u/nzt7WvdbOtb21nK2ljJSMc4yEa//vvXtzWnNr UmtjSufWnL2te//nnFJKMe/WhEpCKaWUWufOe861Y8atWoRzOXNjMe/OY9a1SqWMOffOUjEpEMal Oe/GQpR7KVpKGL2cMd61Oee9MffGMdatKa2MIc6lIe+9Ib2UGMacGO+9GMacENalEJRzCLWMCK2E CN6tCNalAIxrAGtSAEo5AMa9nLWla9a9Y72lUvfWY3trMbWcQnNjKefGUu/OUt69SufGSpyEMda1 Qt69QqWMMc6tOffOQta1OZyEKcalMe/GOc6tMb2cKd61KVpKEL2cIe/GKYxzGNatIbWUGN61GFJC CK2MENatEO+9EL2UCM6lCO+9COe1CO+9AOe1AN6tAL2UALWMAJx7AJRzAHNaAN7Wtb21lK2lhP/v rYR7UufWjM69c8a1a/fee2NaMe/Wc5yMSvfec6WUSufOY9a9Uox7McatQu/OSoRzKa2UKe/GIYxz EOe9GN61EIRrCN61CNatAM6lAIRrAHtjACkhAP/3zu/nvdbOpbWthN7OhNbGe7WlWs69Y1JKIXNj GL21hKWca/fnjN7Oc0I5CMbGvf//797ezsbGtbW1pefnzpSUhEpKQtbWvcbGrb29pYSEc2trWpSU e1paSnt7Y1JSQmNjSkJCMVpaQiEhGEJCKTk5IRgYCBAQAAgIAAAAACwAAAAAuQAwAAAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN hxH+6dyZ4WbBnTt93gQK1CDRfz+Jljx604JSmAGO6kSQtChBpiSx1qzw9OUEqf82VA16tatIrTS5 Wn0JVudYt2XXnjU706nckwcIRm1LFcCBA0cN/BV89C8BvQ3U6qygICECu/8qpHuLFEDOfxkaDxz8 N4DABzovFCA4QO2FvgULRMgAdIKBzQcuEB1ccMDXxYc35h0ou21l38ArCATse0JBB20jDDxaQKpn AEQNIDgqFsAGqQRB+24MfOAAvh+B//8WD1b4dPEPBl73XZ08XKLIpVZYT12gYt/ffQtUAPxCx/w7 OcAAUdy5d5RwBgp0W3DQuVeggWAJBKF+zaHHUW9kaYVWg3Jp+NRRFzRAX1AGijUhWArwB5R/AAiA 1X2VSUjUAAKNGGNGWHl4F1oO9NjjbhwGddlOxskIVDog1shUfUHu5N9eQElwQANUUhkXWZDBBUCF OwHZZJEYcamTBvYRxYCRZC1HV0EHQIAdWgpUIKecKnaolFbErRXfTsIZlM6CVsE4EIyc5ZnmRawB 1RcBOdK1YQE2vrkmZVe6hRaeRPVZp34AZBnjhBpd+qGjZkUa4YZGmbWkql0ZQJQFTXL/Kiia5GV0 nnvpbagVjDxhaOmkld64qp1rGRpZW77C5amaCWJkqn66dpUkrUjBmamoRWGbprGe/uMAs2TBOBoA yWYF6lEZ/EXtAwaIqWWslhHVE7WbvjvsoVq52h24yhK1wV+3hkbQnHNiFDCubVG7WGACJTvetffa eyerxYr3HHYA8PorUBkI4O4/CWSskwMVfAeRjf8eIJjKkWr8MMTufUZerhSTWLOWxrocIQB7KmVs wvbxnIEGNzJ0lGYE1fuPixhrXMGAYNlIo8i+sajtxvi2mqnDQMcKl9JoCeeAbUUrpDRCR0XQc5qJ AiWcdvA1Wd2WbQF5dbU3x5gzuVIV/1CvcgAcrGUAzwI+UHqa9SkUAhBU4MC4DSFAsgOoxcQABRM0 8NxFB0x+plCghy766KSXbvrpqKeuukQBSOBjj40V4MDcEfno5egkz7u6QhfQ+E96iv+DAUVRTb2Q t0tBftAGfSpu0QFgzkRVcwJ9Dt1otwMwQPYE5aTXc7cXTSP3r5E2nEEFeEk9Qs0hDQGbBuVGAPg/ Za48QR4TtJsBm/slkPEYkU1BpmMdAQokKgGYXULCMpCcRCAC0wFSTspXgAxUQDa7Kd76AKAA1igA OQ3wDlIu+L8NZKB8RtFdQTawgIyh5joGuMBXBgAaxQFGQoYDQAa+9Q/rCTAD3gNAAP9A4xnk4ch5 1smAfxrwqcYQbYFIi8oCAmCy5RgOORMIwG7Wx5WBNIdy0NncP3ynu39ULjtlq1F1XCWQkP3DOBi4 gHL+AbkBCcSCy2lMVAYygQT8gwPQ6VNPQJaxjfwjN2pSUvX+cQANIDFpN4rKty5Au3/0DzNX0eM/ kAYd/4CGj/9IxwYMt0GDdPEgS1NQjAYkgAZxUFjpgc77RCajskjokiGknUWC6EVLSihxaUwKQb4i Ib/tBylTKyUB4yXEY0roAZp5V8N8eRDkDGw5ywleT77juwlArjJVhE5jZLMApG0SAHa8SgNiiSNd ZmADAyCAA1j0SioOD23shM6ZviOqgefIZm6UJAhyCnAB0ABSQn3a5Li8dwDD/Y6eRukTQbFpmUre 8TfpCNkrf7kcB5Bpk8/hD0Ih2sP7VYQCPYpeAwaggAvcTkRnHIgAIrBO1ISwRRnYnANyuNKffKsB KlUPAFfjJQ18SyGXyeLAXEqaozagldaBaiCZ1z853XFzC+jLDn9y09159Xj9s8gAIPrVshYkJ2GV yHcCQFazupUjBwDgW+dK17qWNSAAOw== URL:http://www.atm.com LABEL;WORK;PARCEL;POSTAL;DOM;QUOTED-PRINTABLE:140 Du Bois Street, Suite C=0A= Santa Cruz, CA 95060 END:VCARD --=_22tW39g.bO1996u.N17d000A.r08Y.19:006c2b-- From owner-ietf-calendar Thu Aug 22 12:05:17 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA00282 for ietf-calendar-bks; Thu, 22 Aug 1996 12:05:17 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from hedgehog.mcom.com (h-207-1-136-17.netscape.com [207.1.136.17]) by imc.org (8.7.4/8.7.3) with ESMTP id MAA00277 for ; Thu, 22 Aug 1996 12:05:14 -0700 (PDT) Received: from vertigo ([207.1.136.91]) by hedgehog.mcom.com (Netscape Mail Server v1.1) with SMTP id AAA2503; Thu, 22 Aug 1996 12:09:34 -0700 Message-ID: <321CAFB8.446B@netscape.com> Date: Thu, 22 Aug 1996 12:06:32 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.0b5aGold (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: "Dr. Mark K. Joseph" CC: lewisg@microsoft.com, fdawson@raleigh.ibm.com, ietf-calendar@imc.org Subject: Re: Access Control References: <19960822171938.izzy@scr.atm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Dr. Mark K. Joseph wrote: > > I would also agree with this. However, I remember the reciption that > the ASID MIME-DIR draft received in Montreal. It was unfavorable ? I > was in the meeting that got pretty hot discussing how the basic vCard > format (similar to vCalendar format) that was being transported in > the ASID MIME-DIR structure was all wrong. So if we proceed with ASID > MIME-DIR those concerns brought up in Montreal should be addressed up front. There are two documents here, and it's important to understand the differences. The first document, is "A MIME Content-Type for Directory Information", available here: http://ds.internic.net/internet-drafts/draft-ietf-asid-mime-direct-02.txt This document defines the general framework for carrying type/value, attribute- or property-like information in a MIME type. The second document is "An Application/Directory MIME Content-Type Electronic Business Card Profile", available here: http://ds.internic.net/internet-drafts/draft-ietf-asid-mime-vcard-00.txt This document uses the framework defined in the first document to define specific information that should be carried to represent personal contact and other information about a person. This is also known as the "vcard" document, since it is aligned with the versit consortium's vcard specification (same format inside the mime type). Our expectation is that other documents will be defined to support other applications (e.g., a document that defines a "calendaring information" profile). Like vcard, these documents use the framework defined in the framework document. In the Montreal meeting, there were several comments on the vcard draft. I've included the appropriate excerpt from the ASID minutes on this topic below. In summary, though, I don't think there was anything too controversial. -- Tim - versit/pdi vcard profile Patrik Falstrom led the discussion of a number of problems/changes he has encountered with the vcard profile and application/directory framework. The issues included: - Character set: The default is currently 7-bit ascii. The group agreed that this default could safely be changed to UTF-8, since it is a superset of 7-bit ASCII, and since there were alternate methods of selecting character set within the specification already. - Encoding mechanism: The default is currently 7-bit clean encoding. The group agreed to change the default to 8-bit encoding, with the appropriate MIME or application/directory field-specific encoding to be used if a 7-bit encoding was required. - Linebreaks: The current versit vcard draft states that CR, LF, and CRLF sequences should all work as line break sequences. Frank Dawson confirmed that the intention here was to do the same thing RFC 822 does by allowing whatever end-system representation was natural, but using a canonical representation on the network. Frank, Patrik, John Myers, and Dave Crocker agreed to come up with clarifying wording for the draft. ACTION: Frank, Patrik, John, and Dave to clarify wording in the vcard draft. In the course of the discussion, Dave Crocker volunteered to write up a separate Internet Draft describing how to handle the linebreak problem in the general case, since it appears to be something many people have run into before. ACTION: Dave to produce "how to handle linebreaks" draft. - Timezone representation: The current draft allows a number of timezone representations. The group agreed to standardize on always using the single format defined in RFC 822. ACTION: Frank and Tim to produce a new version of the vcard draft with above revisions. From owner-ietf-calendar Thu Aug 22 16:56:10 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id QAA00133 for ietf-calendar-bks; Thu, 22 Aug 1996 16:56:10 -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 QAA01361 for ; Thu, 22 Aug 1996 16:46:02 -0700 (PDT) Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA160818; Thu, 22 Aug 1996 19:49:56 -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 TAA37576 for ; Thu, 22 Aug 1996 19:49:59 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA0435; Thu, 22 Aug 96 19:49:35 -0400 Message-Id: <9608222349.AA0435@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 96DFE240D9809DDB8525638E007B8A75; Thu, 22 Aug 96 19:49:22 To: Tim Howes Cc: "Dr. Mark K. Joseph" , lewisg , fdawson , ietf-calendar From: Frank Dawson Date: 22 Aug 96 18:34:18 Subject: Re: Access Control Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Dr. Mark K. Joseph wrote: > > I would also agree with this. However, I remember the reciption that > the ASID MIME-DIR draft received in Montreal. It was unfavorable ? I > was in the meeting that got pretty hot discussing how the basic vCard > format (similar to vCalendar format) that was being transported in > the ASID MIME-DIR structure was all wrong. So if we proceed with ASID > MIME-DIR those concerns brought up in Montreal should be addressed up front. Mark: Your comments are VERY misleading. I certainly would not have thought that that is your intent here. I was also at the Montreal meeting and participated in the discussions and action items out of the meeting. As the minutes will show, the vCard profile work was addressed and progressed at the meeting. There were a short list of comments that Patrik had on the Internet-Draft. They were resolved to his satisfaction in the meeting with revisions to the specification. Not sure how this can be more clearly expressed. - - Frank Dawson From owner-ietf-calendar Thu Aug 22 18:03:53 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id SAA00495 for ietf-calendar-bks; Thu, 22 Aug 1996 18:03:53 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from nugget.scr.atm.com ([206.100.186.2]) by imc.org (8.7.4/8.7.3) with SMTP id SAA00490 for ; Thu, 22 Aug 1996 18:03:50 -0700 (PDT) Received: from mailman.scr.atm.com (mailman.scr.atm.com [206.100.186.54]) by nugget.scr.atm.com (8.6.12/8.6.9) with ESMTP id RAA24906; Thu, 22 Aug 1996 17:20:47 -0700 From: izzy@nugget.scr.atm.com (Dr. Mark K. Joseph) To: fdawson@raleigh.ibm.com Cc: howes@netscape.com, lewisg@microsoft.com, fdawson@raleigh.ibm.com, ietf-calendar@imc.org Date: Thu, 22 Aug 1996 17:09:34 -0700 MIME-Version: 1.0 Message-ID: <19960823000934.izzy@scr.atm.com> In-Reply-To: <9608222349.AA0428@rtpnsi01.raleigh.ibm.com> Subject: RE[2]: Access Control X-Mailer: Emissary V2.03, by Attachmate Corp. Content-Type: multipart/mixed; boundary="=_23tW35g.bO1996u.N00d000A.r08Y.09:0025eb" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk --=_23tW35g.bO1996u.N00d000A.r08Y.09:0025eb Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, 22 Aug 1996 11:34:18 -0700 Frank Dawson wrote: >Mark: > >Your comments are VERY misleading. I certainly would not have thought that that >is your intent here. I was also at the Montreal meeting and participated in the >discussions and action items out of the meeting. As the minutes will show, the >vCard profile work was addressed and progressed at the meeting. There were a >short list of comments that Patrik had on the Internet-Draft. They were >resolved to his satisfaction in the meeting with revisions to the >specification. > I am sorry if my comments where taken the wrong way. I like the MIME-DIR internet-drafts we have been referring to as well as the vCard format. However, I as concerned with what happened at the Montreal meeting. I did attend the ASID section and the "application/directory" spec with the vCard like format did not seem well received to me by many of the IETF Email community. Now if I misinterpreted what happened during that meeting I would appreciate being corrected. My main concern, is that I would hate to see those same concerns hurt the calendaring work done here once it reached the IETF. --=_23tW35g.bO1996u.N00d000A.r08Y.09:0025eb Content-Type: application/vcard Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="MJOSEPH.VCF" Content-Description: The Sender's Signature BEGIN:VCARD NOTE: vCard Format: Version 2.0(Spec-4/29/96) REV:1996-08-07T18:34:06Z N:Joseph;Mark EmissaryA.FN:Mark K. Joseph, Ph.D. MAILER:Emissary 2.01 EMAIL;work;pref;internet:izzy@scr.atm.com EMAIL;home;internet:markjoseph@delphi.com TEL;WORK;PREF;MSG:(408) 471 - 3016 TEL;WORK;FAX:(408) 471 - 3010 TEL;HOME;FAX;MSG:(408) 475 - 8805 TZ:-0800 ORG:Attachmate Corporation;Internet Products Group TITLE:Software Architect LOGO;BASE64;gif: R0lGODlhuQAwAPcAAP///+/v7+fn597e3tbW1s7OzsbGxr29va2traWlpZycnJSUlIyMjISEhHt7 e3Nzc2tra2NjY1paWlJSUkpKSkJCQjk5OTExMSkpKSEhIRgYGBAQEAgICOfe1oR7c2NaUjEpIe/n 3s7Gva2lnIyEe0pCOaWcjJyUhL2tjFpSQox7WntrShgQANbGnM69lMa1jO/WlJSEWta9e8ata3tr Qq2UUqWMSpR7OYRrKTkpAKWchIR7Y+/erefWpa2ca6WUY4x7SpyEQsalSr2cQmNSIbWUOYxzKaWE KYRrIZx7Ie+9KUo5CGtSCMaUAKV7AFpCAP/33u/nzt7WvdbOtb21nK2ljJSMc4yEa//vvXtzWnNr UmtjSufWnL2te//nnFJKMe/WhEpCKaWUWufOe861Y8atWoRzOXNjMe/OY9a1SqWMOffOUjEpEMal Oe/GQpR7KVpKGL2cMd61Oee9MffGMdatKa2MIc6lIe+9Ib2UGMacGO+9GMacENalEJRzCLWMCK2E CN6tCNalAIxrAGtSAEo5AMa9nLWla9a9Y72lUvfWY3trMbWcQnNjKefGUu/OUt69SufGSpyEMda1 Qt69QqWMMc6tOffOQta1OZyEKcalMe/GOc6tMb2cKd61KVpKEL2cIe/GKYxzGNatIbWUGN61GFJC CK2MENatEO+9EL2UCM6lCO+9COe1CO+9AOe1AN6tAL2UALWMAJx7AJRzAHNaAN7Wtb21lK2lhP/v rYR7UufWjM69c8a1a/fee2NaMe/Wc5yMSvfec6WUSufOY9a9Uox7McatQu/OSoRzKa2UKe/GIYxz EOe9GN61EIRrCN61CNatAM6lAIRrAHtjACkhAP/3zu/nvdbOpbWthN7OhNbGe7WlWs69Y1JKIXNj GL21hKWca/fnjN7Oc0I5CMbGvf//797ezsbGtbW1pefnzpSUhEpKQtbWvcbGrb29pYSEc2trWpSU e1paSnt7Y1JSQmNjSkJCMVpaQiEhGEJCKTk5IRgYCBAQAAgIAAAAACwAAAAAuQAwAAAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN hxH+6dyZ4WbBnTt93gQK1CDRfz+Jljx604JSmAGO6kSQtChBpiSx1qzw9OUEqf82VA16tatIrTS5 Wn0JVudYt2XXnjU706nckwcIRm1LFcCBA0cN/BV89C8BvQ3U6qygICECu/8qpHuLFEDOfxkaDxz8 N4DABzovFCA4QO2FvgULRMgAdIKBzQcuEB1ccMDXxYc35h0ou21l38ArCATse0JBB20jDDxaQKpn AEQNIDgqFsAGqQRB+24MfOAAvh+B//8WD1b4dPEPBl73XZ08XKLIpVZYT12gYt/ffQtUAPxCx/w7 OcAAUdy5d5RwBgp0W3DQuVeggWAJBKF+zaHHUW9kaYVWg3Jp+NRRFzRAX1AGijUhWArwB5R/AAiA 1X2VSUjUAAKNGGNGWHl4F1oO9NjjbhwGddlOxskIVDog1shUfUHu5N9eQElwQANUUhkXWZDBBUCF OwHZZJEYcamTBvYRxYCRZC1HV0EHQIAdWgpUIKecKnaolFbErRXfTsIZlM6CVsE4EIyc5ZnmRawB 1RcBOdK1YQE2vrkmZVe6hRaeRPVZp34AZBnjhBpd+qGjZkUa4YZGmbWkql0ZQJQFTXL/Kiia5GV0 nnvpbagVjDxhaOmkld64qp1rGRpZW77C5amaCWJkqn66dpUkrUjBmamoRWGbprGe/uMAs2TBOBoA yWYF6lEZ/EXtAwaIqWWslhHVE7WbvjvsoVq52h24yhK1wV+3hkbQnHNiFDCubVG7WGACJTvetffa eyerxYr3HHYA8PorUBkI4O4/CWSskwMVfAeRjf8eIJjKkWr8MMTufUZerhSTWLOWxrocIQB7KmVs wvbxnIEGNzJ0lGYE1fuPixhrXMGAYNlIo8i+sajtxvi2mqnDQMcKl9JoCeeAbUUrpDRCR0XQc5qJ AiWcdvA1Wd2WbQF5dbU3x5gzuVIV/1CvcgAcrGUAzwI+UHqa9SkUAhBU4MC4DSFAsgOoxcQABRM0 8NxFB0x+plCghy766KSXbvrpqKeuukQBSOBjj40V4MDcEfno5egkz7u6QhfQ+E96iv+DAUVRTb2Q t0tBftAGfSpu0QFgzkRVcwJ9Dt1otwMwQPYE5aTXc7cXTSP3r5E2nEEFeEk9Qs0hDQGbBuVGAPg/ Za48QR4TtJsBm/slkPEYkU1BpmMdAQokKgGYXULCMpCcRCAC0wFSTspXgAxUQDa7Kd76AKAA1igA OQ3wDlIu+L8NZKB8RtFdQTawgIyh5joGuMBXBgAaxQFGQoYDQAa+9Q/rCTAD3gNAAP9A4xnk4ch5 1smAfxrwqcYQbYFIi8oCAmCy5RgOORMIwG7Wx5WBNIdy0NncP3ynu39ULjtlq1F1XCWQkP3DOBi4 gHL+AbkBCcSCy2lMVAYygQT8gwPQ6VNPQJaxjfwjN2pSUvX+cQANIDFpN4rKty5Au3/0DzNX0eM/ kAYd/4CGj/9IxwYMt0GDdPEgS1NQjAYkgAZxUFjpgc77RCajskjokiGknUWC6EVLSihxaUwKQb4i Ib/tBylTKyUB4yXEY0roAZp5V8N8eRDkDGw5ywleT77juwlArjJVhE5jZLMApG0SAHa8SgNiiSNd ZmADAyCAA1j0SioOD23shM6ZviOqgefIZm6UJAhyCnAB0ABSQn3a5Li8dwDD/Y6eRukTQbFpmUre 8TfpCNkrf7kcB5Bpk8/hD0Ih2sP7VYQCPYpeAwaggAvcTkRnHIgAIrBO1ISwRRnYnANyuNKffKsB KlUPAFfjJQ18SyGXyeLAXEqaozagldaBaiCZ1z853XFzC+jLDn9y09159Xj9s8gAIPrVshYkJ2GV yHcCQFazupUjBwDgW+dK17qWNSAAOw== URL:http://www.atm.com LABEL;WORK;PARCEL;POSTAL;DOM;QUOTED-PRINTABLE:140 Du Bois Street, Suite C=0A= Santa Cruz, CA 95060 END:VCARD --=_23tW35g.bO1996u.N00d000A.r08Y.09:0025eb-- From owner-ietf-calendar Thu Aug 22 18:20:37 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id SAA00543 for ietf-calendar-bks; Thu, 22 Aug 1996 18:20:37 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id SAA00538 for ; Thu, 22 Aug 1996 18:20:36 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9057.57F52A20@yuri.microsoft.com>; Thu, 22 Aug 1996 18:25:49 -0700 Message-ID: From: "Alec Dun (Exchange)" To: "'Tim Howes'" Cc: "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Date: Thu, 22 Aug 1996 18:25:53 -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 Hi Tim, This is the follow-up to our phone conversation last Friday about merging the mime-props draft from the calendaring working group with the mime-dir draft from the asid working group. The two drafts are not that different, here are the key changes I think we need to make to encapsulate the thoughts of mime-prop into mime-dir: 1. Add an optional datatype parameter. This will allow an application to identify and handle data based on it's type. We talked about the proto parameter being used to specify a way for an application to deal with the data, so maybe we should collapse the proto paramater into the datatype parameter. I think we can also collapse "valuetypeparam" production into a url datatype. We'd also pre-define the data formats, but not limited to that which we have in the MIME-PROPS draft. See the suggested grammar below: parameter := encodingparam / charsetparam / languageparam / datatypeparam / [paramtype "="] paramvalues datatypeparam := "datatype" "=" datatype datatype := "text" / "boolean" / "datetime" / "time" / "date" / "float" / "long" / "binary" / "currency" / "url" / x-datatype / iana-datatype 2. Efficiency in repeated properties. To increase efficiency, I propose that we allow properties which have the same name to be repeated without the name. In this scheme, the repeated property would inherit the attributes from the previous property. For example: CN: Frank Arthur CN: Arthur Frank CN: Frank would become CN: Frank Arthur :Arthur Frank :Frank 3. Grouping disjoint profiles. We need to be able to assign a profile to groups of properties. For example, I am sending a meeting request, identifying all the attendees and in the same message I am identifying where the meeting is, what time it's at, etc. We thought about having a base body part that had URLs to other parts, but that has a lot of overhead, so instead we were thinking of a construct that looked more like this, allowing multiple profiles within a single body-part: begin: meetingdetails Location; datatype=text: "At the boathose" Date; datatype=date: 11 Aug 96 Time; datatype=time: 10:30:00 begin: meetingattendee CN: Frank Arthur SN: Jones Status: Required begin: meetingattendee CN: James George SN: Brown Status: Optional The grammer would be something like this: body := section [ body ] section := "begin" ":" profile CR content content := contentline CR [ content ] Thanks, Alec. >---------- >From: Internet-Drafts@ietf.org[SMTP:Internet-Drafts@ietf.org] >Sent: Wednesday, July 31, 1996 6:18 AM >To: The recipient's address is unknown. >Cc: ietf-asid@umich.edu >Subject: I-D ACTION:draft-ietf-asid-mime-direct-02.txt > ><><> > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Access, Searching and > Indexing of Directories Working Group of the IETF. > > Title : A MIME Content-Type for Directory Information > Author(s) : T. Howes, M. Smith > Filename : draft-ietf-asid-mime-direct-02.txt > Pages : 20 > Date : 07/30/1996 > >This document defines a MIME Content-Type for holding directory >information. The definition is independent of any particular directory >service. The application/directory Content-Type is defined for holding a >variety of directory information, for example, name, or email address. >The application/directory Content-Type can also be used as the root body >part in a multipart/related Content-Type for handling more complicated >situations, especially those in which non-textual information that already >has a natural MIME representation, for example, a photograph or sound, must >be represented. > >The application/directory Content-Type defines a general framework and >format for holding directory information in a simple "type: value" format. >This format is compatible with the Versit Electronic Business Card >Specification text encoding. Mechanisms are defined to specify alternate >character sets, languages, encodings and other meta-information. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-asid-mime-direct-02.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-asid-mime-direct-02.txt > >Internet-Drafts directories are located at: > > o Africa > Address: ftp.is.co.za (196.4.160.8) > > o Europe > Address: nic.nordu.net (192.36.148.17) > Address: ftp.nis.garr.it (193.205.245.10) > > o Pacific Rim > Address: munnari.oz.au (128.250.1.21) > > o US East Coast > Address: ds.internic.net (198.49.45.10) > > o US West Coast > Address: ftp.isi.edu (128.9.0.32) > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-asid-mime-direct-02.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > >For questions, please mail to Internet-Drafts@ietf.org > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. > > From owner-ietf-calendar Fri Aug 23 00:23:35 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id AAA01306 for ietf-calendar-bks; Fri, 23 Aug 1996 00:23:35 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from a4.jck.com (ns.jck.com [206.99.215.40]) by imc.org (8.7.4/8.7.3) with ESMTP id AAA01301 for ; Fri, 23 Aug 1996 00:23:17 -0700 (PDT) Received: from white-box.jck.com ("port 2029"@white-box.jck.com) by a4.jck.com (PMDF V5.0-5 #16053) id <0DWKY4264006UB@a4.jck.com>; Fri, 23 Aug 1996 03:28 -0400 (EDT) Date: Fri, 23 Aug 1996 03:28:48 -0400 (EDT) From: John C Klensin Subject: Re: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt To: "Alec Dun (Exchange)" Cc: "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" , "'Tim Howes'" Reply-to: John C Klensin Message-id: MIME-version: 1.0 X-Mailer: Simeon for Windows Version 4.1a5 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Priority: NORMAL X-Authentication: none Sender: owner-ietf-calendar@imc.org Precedence: bulk On Thu, 22 Aug 1996 18:25:53 -0700 "Alec Dun (Exchange)" wrote: >... > 2. Efficiency in repeated properties. To increase efficiency, I > propose that we allow properties which have the same name to be repeated > without the name. In this scheme, the repeated property would inherit > the attributes from the previous property. For example: > > CN: Frank Arthur > CN: Arthur Frank > CN: Frank > > would become > > CN: Frank Arthur > :Arthur Frank > :Frank Alec, >From a language design standpoint, I'd recommend against this, at least in this form. It has some slightly uncomfortable parsing properties relative for environments in which one might want to implement things by, e.g., quickly sweeping through the file using a hash on the names to insert properties in a list. More generally, one doesn't want to need to look ahead and then back up if that is avoidable. Doing things with omitted property tags implies that one needs strong ordering rules and, typically, an extra algorithmic step to guard against bad behavior from violations of those rules. One can avoid those problems by a careful choice of parsing procedures, but we try to avoid imposing that type of constraint unless it is clearly needed. As an alternative, if you want to omit repeated property names, consider introducing an iterated list, e.g., CN: { Frank Arthur, Arthur Frank, Frank } in C-ish style or Frank Arthur, Arthur Frank, Frank if HTML-ish style. I'll not comment on the other two suggestions at this time. john From owner-ietf-calendar Fri Aug 23 02:09:42 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id CAA03293 for ietf-calendar-bks; Fri, 23 Aug 1996 02:09:42 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ics.uci.edu (mmdf@ics.uci.edu [128.195.1.1]) by imc.org (8.7.4/8.7.3) with SMTP id CAA03288 for ; Fri, 23 Aug 1996 02:09:31 -0700 (PDT) Received: from nma.com by q2.ics.uci.edu id ab21382; 23 Aug 96 2:15 PDT Received: from localhost by odin.nma.com id aa27270; 23 Aug 96 0:56 PDT To: ietf-calendar Subject: An Overview and Evaluation Re: Access Control In-reply-to: Your message of "22 Aug 1996 18:34:18." <9608222349.AA0435@rtpnsi01.raleigh.ibm.com> Reply-to: ietf-calendar@imc.org From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27265.840787000.1@odin.nma.com> Date: Fri, 23 Aug 1996 00:56:41 -0700 Message-ID: <27267.840787001@odin.nma.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk I too was at the ASID WG meeting in Montreal, and I will agree with Mark that the discussions tended to be intense, but not out of character with a recognized productive WG effort. You should have seen the MHTML WG. Actually, I think that the ability of IETF WGs to get down to it and come to consensus is very powerful and a great asset. Not unlike this discussion via EMail;-)... My take is that everyone there (and here) see this as a major breakthrough in several critical areas in need of progress, with a great deal at stake in getting it right for the Internet. If this work does not yield regular and easy Application Information Object Interchange protocols for all kinds of application objects, we will have missed the boat in a big big way. So, with so much at stake, how could the discussions be anything but intense. As I read the excerpt from the minutes, I see that the issues listed are terribly critical for a whole variety of new developments, including how we get EMail and WEB applications to smoothly and regularly exchange information objects wihtout damage or ambiguity. The handling of CR, LF, and CRLF are a major issue related to a massive installed base of EMail systems which can only evolve slowly. I am eagerly awaiting Dave Crockers two deliverables as listed, since they promise to resolve the CRLF issues for lots of new protocols. Another issue is the so called choice of MIME CHARSET "default". My take was that ASID decided, and HTTP decided to no longer use "absence" to imply any default, as different transports have taken to using different semantics for "absence" of CHARSET parameters. MHTML is now seriously considering that CHARSET MUST be present in all Content-type: text/mhtml MIME parts. To fill all this out, I recall a decision somewhere, perhaps in DRUMS to make CHARSET a MUST, and to define "UNKNOWN" as the value to use when the content charset is in fact unknown. With this done, we no longer have ambiguity born of the attempt to use "absence" to mean different things in different transport contexts. That attempt was born of good will, to deal with the fact that lots of mail was being generated without MIME-version: 1.0, or any other MIMEisms, and all such mail is by (historical/hysterical) RFC822 definition, CHARSET=US-ASCII. So much for history -- We can cinch this down now by all agreeing that CHARSET no longer has ANY defaults in new MIME types. So, what I see out of Montreal was an amazing lot of consensus for a lot of issues that have been plaguing some of us for a long long time. That is my view from about 15,000 feet;-)...\Cheers...\Stef >From your message 22 Aug 96 18:34:18 : } }Dr. Mark K. Joseph wrote: }> }> I would also agree with this. However, I remember the reception that }> the ASID MIME-DIR draft received in Montreal. It was unfavorable ? I }> was in the meeting that got pretty hot discussing how the basic vCard }> format (similar to vCalendar format) that was being transported in }> the ASID MIME-DIR structure was all wrong. So if we proceed with ASID }> MIME-DIR those concerns brought up in Montreal should be addressed up front. } }Mark: } }Your comments are VERY misleading. I certainly would not have thought that that }is your intent here. I was also at the Montreal meeting and participated in the }discussions and action items out of the meeting. As the minutes will show, the }vCard profile work was addressed and progressed at the meeting. There were a }short list of comments that Patrik had on the Internet-Draft. They were }resolved to his satisfaction in the meeting with revisions to the }specification. } }Not sure how this can be more clearly expressed. } }- - Frank Dawson From owner-ietf-calendar Fri Aug 23 05:46:40 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id FAA04138 for ietf-calendar-bks; Fri, 23 Aug 1996 05:46:40 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by imc.org (8.7.4/8.7.3) with SMTP id FAA04133 for ; Fri, 23 Aug 1996 05:46:35 -0700 (PDT) From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <22024-0@domen.uninett.no>; Fri, 23 Aug 1996 14:02:39 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: "Alec Dun (Exchange)" cc: "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt In-reply-to: Your message of "Thu, 22 Aug 1996 18:25:53 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 1996 14:02:35 +0200 Message-ID: <22020.840801755@domen.uninett.no> Sender: owner-ietf-calendar@imc.org Precedence: bulk Alec, I think datatypes need to be part of the attribute definition, not of the attribute value. How would I interpret sensibly CN;datatype=currency: NOK CN;datatype=url: http://somewhere.in.cn/~zhu/myname.gif when I want to put the CN into a mailing list? The grouping needs more thought - your example of a meeting with attendees is one example of use of this. But I think the overhead compared to a bunch of separate MIME objects is actually quite low; you save about 1 line per object. Your example: begin: meetingdetails Location; datatype=text: "At the boathose" Date; datatype=date: 11 Aug 96 Time; datatype=time: 10:30:00 begin: meetingattendee CN: Frank Arthur SN: Jones Status: Required begin: meetingattendee CN: James George SN: Brown Status: Optional becomes --xx app/dir;profile=meetingdetails Location; datatype=text: "At the boathose" Date; datatype=date: 11 Aug 96 Time; datatype=time: 10:30:00 --xx app/dir;profile=meetingattendee CN: Frank Arthur SN: Jones Status: Required --xx app/dir;profile=meetingattendee CN: James George SN: Brown Status: Optional --xx-- Not a world of difference; think about whether we want the additional complexity in one parser, rather than having two of them. (I left out the links; not sure we need them) Harald A From owner-ietf-calendar Fri Aug 23 07:44:42 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id HAA04434 for ietf-calendar-bks; Fri, 23 Aug 1996 07:44:42 -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 HAA04429 for ; Fri, 23 Aug 1996 07:44:40 -0700 (PDT) Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA170110; Fri, 23 Aug 1996 10:48:30 -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 KAA54096 for ; Fri, 23 Aug 1996 10:48:24 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA0453; Fri, 23 Aug 96 10:47:55 -0400 Message-Id: <9608231447.AA0453@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id FE51657C46E3AAB08525638F004C4852; Fri, 23 Aug 96 10:47:37 To: "Dr. Mark K. Joseph" Cc: fdawson , howes , lewisg , ietf-calendar From: Frank Dawson Date: 23 Aug 96 9:54:01 Subject: Re: RE[2]: Access Control Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Mark: As both the chair of the ASID group and I commented, we think that you were off on the assessment. - - Frank From owner-ietf-calendar Fri Aug 23 09:19:19 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA04685 for ietf-calendar-bks; Fri, 23 Aug 1996 09:19:19 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from srvr1.ralden.com (rincon.ralden.com [207.18.126.2]) by imc.org (8.7.4/8.7.3) with SMTP id JAA04680 for ; Fri, 23 Aug 1996 09:19:14 -0700 (PDT) Received: by srvr1.ralden.com with Microsoft Exchange (IMC 4.0.837.3) id <01BB90D4.EE78A0D0@srvr1.ralden.com>; Fri, 23 Aug 1996 09:24:49 -0700 Message-ID: From: "Roland H. Alden" To: "'asid mailing list'" , "'ietf-calendar@imc.org'" Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Date: Fri, 23 Aug 1996 09:24:21 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk >Harald.T.Alvestrand wrote: > >I think datatypes need to be part of the attribute definition, not of >the attribute value. > I would tend to agree although I think I know where this idea is coming from, searching. If property foo is defined in spec n.n to be a time value then any implementation written to n.n can know the type of foo without further ado. The question is, when someone extends the spec with property x-bar with a time value. How interesting is it for software which does not understand *what* x-bar 'is' to manipulate its value? In the case of searching on behalf of a human client one can make an argument that it is useful. The human query "give me all records where time = xxx" might result in some silly matches, such as x-time-I-think-the-cookies-will-be-served-at-this-mtg: 14:15:00 -0800 that may or may not be useful to a human. Certainly the hit is of little value to a deterministic process which has no business fooling with data for which it has no understanding of the semantics. There is also the matter of representation. If I understand the type of x-time-I-think-the-cookies-will-be-served-at-this-mtg then I can store its value in a different, possibly more compact form, even if I don't understand what it means. If I don't understand the type I basically must commit to storing the whole property string. The question is, how valuable is it for an implementation to internalize properties which it cannot use? For an endpoint I think there is not much value, for an intermediate node which passes the data along, it's important. But of course it would probably be best to pass it along in original form too and not try to "internalize" and "regenerate" it. Another important application of typing is properties that have values that can usefully be of several types. For instance: photo ; [gif | jpeg | tiff] : Unless is always self-describing it is useful to have some sugar to pass along information on how the value has been represented. In vCard we have proposed combining representation choices with type choices in this way. For example: photo; base64; gif : While it might be consider "impure" to have made "type" and "representation" into "syntactic equals", as a practical matter software tends to need both or neither if it is going to do something useful with the value. Certainly type information is going to be needed unless all values are of only one type! So the issue becomes how to communicate it. I think that issue divides neatly into whether it is always expressed (the subtext of Alec Dun's post) or whether "defaulting" can be used to eliminate some of the verboseness of the average transaction. Personally I think that some syntax for communicating type and representation is clearly a requirement. At the same time, I think there is no reason that well-defined properties (i.e, those mentioned in version 1.0 of a spec) can't have "well-defined" default (implied) types and probably even *rules* on the allowable set of types. For example: full-name : might be syntactically allowable but disallowed because it upsets everyone's expectation on the types of computations they plan to do with "full-name". In other words, a fully flexible "mix and match" syntax will lead to a combinatorial explosion of useless productions, so a spec will wind up fixing some constrains on allowed types in certian contexts anyway; the syntax might as well benefit from those constraints. To close let me point out one problematic case. That where the value is a "pointer" such as: foo; url : http://www.foo.com/bar/gag Where it is HTTP that will return the "type" information for the object http://www.foo.com/bar/gag. The syntax might allow: photo; gif: http://www.foo.com/me.jpg Where 'gif' advised the the dereferencer of the url to expect a gif but, in fact, anything could come back from the http server (the same holds true for a 'local' reference to another MIME part). My point is that in the above example the syntax provides for two sources of potentially conflicting type information. It might be reasonable then to literally prohibit type information for URL or content-ID values on the grounds that the client should follow the pointers and use other type discovery mechanisms. -Roland From owner-ietf-calendar Fri Aug 23 09:35:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA04772 for ietf-calendar-bks; Fri, 23 Aug 1996 09:35:09 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from hedgehog.mcom.com (h-207-1-136-17.netscape.com [207.1.136.17]) by imc.org (8.7.4/8.7.3) with ESMTP id JAA04767 for ; Fri, 23 Aug 1996 09:35:06 -0700 (PDT) Received: from vertigo ([207.1.136.91]) by hedgehog.mcom.com (Netscape Mail Server v1.1) with SMTP id AAA22857; Fri, 23 Aug 1996 09:40:19 -0700 Message-ID: <321DDE3D.2781@netscape.com> Date: Fri, 23 Aug 1996 09:37:17 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.0b5aGold (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: "Alec Dun (Exchange)" CC: "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Alec Dun (Exchange) wrote: > > This is the follow-up to our phone conversation last Friday about > merging the mime-props draft from the calendaring working group with the > mime-dir draft from the asid working group. The two drafts are not that > different, here are the key changes I think we need to make to > encapsulate the thoughts of mime-prop into mime-dir: Here's my take on these proposed changes. To summarize, it wouldn't kill me one way or another on these, but they do bring up some interesting issues. > 1. Add an optional datatype parameter. This will allow an application > to identify and handle data based on it's type. We talked about the > proto parameter being used to specify a way for an application to deal > with the data, so maybe we should collapse the proto paramater into the > datatype parameter. I think we can also collapse "valuetypeparam" > production into a url datatype. We'd also pre-define the data formats, > but not limited to that which we have in the MIME-PROPS draft. See the > suggested grammar below: > > parameter := encodingparam / charsetparam > / languageparam / datatypeparam / [paramtype "="] > paramvalues > > datatypeparam := "datatype" "=" datatype > > datatype := "text" / "boolean" / "datetime" / "time" / "date" / "float" > / "long" > / "binary" / "currency" / "url" / x-datatype / > iana-datatype As Harald points out, we would need to be clear on the relationship between the use of this parameter and the implicit data type associated with an attribute name, since the two could be used in conflict. From this standpoint, it would be simpler to only do it one way. On the other hand, the datatype parameter provides a pretty simple and effective way to transmit the "syntax" of an attribute to someone who might not otherwise know it, making it a lot easier to define attributes on the fly, for use between communicating parties. The change to the doc is trivial, though. And in fact, it was always our intention to allow people to define their own parameters, since we figured we couldn't think of all the useful ones up front. Whether this gets into the core spec or ends up defined as described in Section 13 of the current draft, probably doesn't make a huge difference. Well, it doesn't make a huge difference to me, anyway. But if Harald et. al can convince Alec that this is a Bad Idea, then the whole issue becomes moot anyway, of course. > 2. Efficiency in repeated properties. To increase efficiency, I > propose that we allow properties which have the same name to be repeated > without the name. In this scheme, the repeated property would inherit > the attributes from the previous property. For example: > > CN: Frank Arthur > CN: Arthur Frank > CN: Frank > > would become > > CN: Frank Arthur > :Arthur Frank > :Frank We had a similar concept in the original draft. It was a "defaulttype" parameter on the MIME body part, the value of which would be assumed as the type in the absence of a type before the colon ':'. We did this for the same reasons Alec mentions. It was removed because people did not see the need and thought it was cruft. Alec's proposal is actually more flexible than our original one, since it allows the default type to change within the body part. I think before we start deciding how to do this, we should decide whether it's necessary. What's the application you have in mind, Alec? In the original proposal, I had in mind using these things to carry centroid or other indexing information that might contain many many values of the same type. Once we decide that, we can argue about whether to do it like this, or like John suggested, basically defining a new type that is meant to hold a bunch of values. > 3. Grouping disjoint profiles. We need to be able to assign a profile > to groups of properties. For example, I am sending a meeting request, > identifying all the attendees and in the same message I am identifying > where the meeting is, what time it's at, etc. We thought about having a > base body part that had URLs to other parts, but that has a lot of > overhead, so instead we were thinking of a construct that looked more > like this, allowing multiple profiles within a single body-part: > > begin: meetingdetails > Location; datatype=text: "At the boathose" > Date; datatype=date: 11 Aug 96 > Time; datatype=time: 10:30:00 > begin: meetingattendee > CN: Frank Arthur > SN: Jones > Status: Required > begin: meetingattendee > CN: James George > SN: Brown > Status: Optional Overhead is one concern. Another is whether the content of the body part should be able to live outside of MIME, without the structure that MIME gives it. This was one of our goals with the vcard profile, which came from a different environment and still wanted to be useful there (e.g., copy-pasted on clipboards, beamed around between PIMs, downloaded to your phone, etc.). In these environments, the overhead is a much bigger concern. And while I know our focus is on the Internet, not on these other environments, I think it would be a shame to force them to do something different from us when it would be pretty easy to adopt something useful both places. -- Tim From owner-ietf-calendar Fri Aug 23 13:03:18 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA05420 for ietf-calendar-bks; Fri, 23 Aug 1996 13:03:18 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from ics.uci.edu (mmdf@ics.uci.edu [128.195.1.1]) by imc.org (8.7.4/8.7.3) with SMTP id NAA05415 for ; Fri, 23 Aug 1996 13:03:07 -0700 (PDT) Received: from nma.com by q2.ics.uci.edu id aa21770; 23 Aug 96 13:08 PDT Received: from localhost by odin.nma.com id aa28175; 23 Aug 96 13:03 PDT To: ietf-asid@umich.edu, ietf-calendar@imc.org Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt In-reply-to: Your message of "Fri, 23 Aug 1996 03:28:48 EDT." Reply-to: ietf-calendar@imc.org From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28170.840830628.1@odin.nma.com> Date: Fri, 23 Aug 1996 13:03:49 -0700 Message-ID: <28172.840830629@odin.nma.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk I have always found, dating back to 1960, that storing or conveying attribute meaning via the absence of an explicit tag (or any other explicit clue) is a very bad idea, unless you are in a fully closed system and always know precisely what you are doing with every attribute and value. The Internet is NOT one of these closed systems! Defaulting must be done with extreme care in the Internet, if it is done at all. So, I endorse John suggestion to use a multi-valued attribute in place of a sequence (or set, or list) of individual attributes that use absence defaulting for all but the first of these line-separated attributes. Indeed, one breakthrough aspect of ASID-DIR and ASID-vCARD is exactly this concept of multivaluesd attributes with convenient and short sub-attribute tagging within multi valued attributes. In Internet Standards, this becomes excrutiating. Look at the problems we now have with MIME CHARSET as a prime example of what comes of "efficiencies" like omission of tags, such that default meaning is attributed to absence of explicit tags. Alec is saving 2 characters per attribute. May I ask what Alec is going to do with these savings? We may have already spent the next ten years of accumulated savings in this brief discussion. And who is going to pay for all the extra software effort required to achieve his saving, and for all the confusion that is likely to follow as this technology continues to be extended? For my money, it has to be a lot easier to deal with a set of names that are being defined as equivalent to each other by putting them all in one well labeled attribute. Now I have no need to be concerned with all those implied inter-attribute relationships Cheers...\Stef >From Klensin's message Fri, 23 Aug 1996 03:28:48 -0400 (EDT): } } }On Thu, 22 Aug 1996 18:25:53 -0700 "Alec Dun (Exchange)" } wrote: }>... }> 2. Efficiency in repeated properties. To increase efficiency, I }> propose that we allow properties which have the same name to be repeated }> without the name. In this scheme, the repeated property would inherit }> the attributes from the previous property. For example: }> }> CN: Frank Arthur }> CN: Arthur Frank }> CN: Frank }> }> would become }> }> CN: Frank Arthur }> :Arthur Frank }> :Frank } }Alec, } }From a language design standpoint, I'd recommend against this, }at least in this form. It has some slightly uncomfortable }parsing properties relative for environments in which one might }want to implement things by, e.g., quickly sweeping through the }file using a hash on the names to insert properties in a list. }More generally, one doesn't want to need to look ahead and then }back up if that is avoidable. Doing things with omitted }property tags implies that one needs strong ordering rules and, }typically, an extra algorithmic step to guard against bad }behavior from violations of those rules. One can avoid those }problems by a careful choice of parsing procedures, but we try }to avoid imposing that type of constraint unless it is clearly }needed. } }As an alternative, if you want to omit repeated property names, }consider introducing an iterated list, e.g., } CN: { Frank Arthur, Arthur Frank, } Frank } }in C-ish style or } Frank Arthur, Arthur Frank, Frank }if HTML-ish style. } }I'll not comment on the other two suggestions at this time. } } john } } } } From owner-ietf-calendar Fri Aug 23 13:17:08 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA05457 for ietf-calendar-bks; Fri, 23 Aug 1996 13:17:08 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id NAA05452 for ; Fri, 23 Aug 1996 13:17:06 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB90F6.1EE46620@yuri.microsoft.com>; Fri, 23 Aug 1996 13:22:23 -0700 Message-ID: From: "Alec Dun (Exchange)" To: "'Harald.T.Alvestrand@uninett.no'" Cc: "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Date: Fri, 23 Aug 1996 13:22:34 -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 On the datatypes issue: the key reason I want the datatype parameter is to enable generic property handling code to be written. For example, imagine that I have a bunch of messages containing mime-dir body parts. Now I want to write a generic piece of code that searches for items where a specified property (for example meetingdate) has Date > 1 Aug 96 and Date < 31 Aug 96 in each message. I could write the search code one of two ways. a. I could have the search code implicitly understand every field, what it means, and how to interpret it. If new profiles and fields get defined, I need to modify the code to be able to do the search. b. I could have generic search code that only needs to understand how to do comparisons on a given datatype. If new fields get defined, I don't need to modify the search code at all. >How would I interpret sensibly > >CN;datatype=currency: NOK >CN;datatype=url: http://somewhere.in.cn/~zhu/myname.gif I would expect CN to always be of datatype=text. The added value of clearly identifying the datatype=text is that you allow serach/sort/storage/etc code to handle the property generically without having to special-case the type of each property. On the grouping issue, I'm not so worried about the simple case that you point out, but what if there are a lot of parameters on the body part header? Is the "Content-Type:" optional? >--xx >app/dir;profile=meetingdetails > >Location; datatype=text: "At the boathose" >Date; datatype=date: 11 Aug 96 >Time; datatype=time: 10:30:00 could look like: >--xx Content-Type: application/directory; charset=iso-8859-1; > language=german; profile=meetingdetails > >Location; datatype=text: "At the boathose" >Date; datatype=date: 11 Aug 96 >Time; datatype=time: 10:30:00 Also, what do you think about "properties/" (ie. "properties/directory" and "properties/appointment") as a top level mime type? Thanks, Alec. >---------- >From: Harald.T.Alvestrand@uninett.no[SMTP:Harald.T.Alvestrand@uninett.no] >Sent: Friday, August 23, 1996 5:02 AM >To: Alec Dun (Exchange) >Cc: 'Tim Howes'; 'ietf-asid@umich.edu'; 'ietf-calendar@imc.org' >Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt > >Alec, > >I think datatypes need to be part of the attribute definition, not of >the attribute value. > >How would I interpret sensibly > >CN;datatype=currency: NOK >CN;datatype=url: http://somewhere.in.cn/~zhu/myname.gif > >when I want to put the CN into a mailing list? > >The grouping needs more thought - your example of a meeting with >attendees is one example of use of this. But I think the overhead >compared to a bunch of separate MIME objects is actually quite low; >you save about 1 line per object. > >Your example: > >begin: meetingdetails >Location; datatype=text: "At the boathose" >Date; datatype=date: 11 Aug 96 >Time; datatype=time: 10:30:00 >begin: meetingattendee >CN: Frank Arthur >SN: Jones >Status: Required >begin: meetingattendee >CN: James George >SN: Brown >Status: Optional > >becomes > >--xx >app/dir;profile=meetingdetails > >Location; datatype=text: "At the boathose" >Date; datatype=date: 11 Aug 96 >Time; datatype=time: 10:30:00 >--xx >app/dir;profile=meetingattendee > >CN: Frank Arthur >SN: Jones >Status: Required >--xx >app/dir;profile=meetingattendee > >CN: James George >SN: Brown >Status: Optional >--xx-- > >Not a world of difference; think about whether we want the additional >complexity in one parser, rather than having two of them. >(I left out the links; not sure we need them) > > Harald A > > > From owner-ietf-calendar Fri Aug 23 13:57:41 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA05545 for ietf-calendar-bks; Fri, 23 Aug 1996 13:57:41 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by imc.org (8.7.4/8.7.3) with SMTP id NAA05540 for ; Fri, 23 Aug 1996 13:57:39 -0700 (PDT) Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16466(3)>; Fri, 23 Aug 1996 14:02:50 PDT Received: by golden.parc.xerox.com id <2757>; Fri, 23 Aug 1996 14:02:29 PDT To: ralden@ralden.com CC: ietf-asid@umich.edu, ietf-calendar@imc.org In-reply-to: Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt From: Larry Masinter Message-Id: <96Aug23.140229pdt."2757"@golden.parc.xerox.com> Date: Fri, 23 Aug 1996 14:02:29 PDT Sender: owner-ietf-calendar@imc.org Precedence: bulk check out draft-masinter-url-data-* for one way to represent typed data inline. Maybe you could just make your data into URLs, and then use "data:" URLs if you want it inline. Harald sent me a bunch of comments on the "data:" URL draft; I need to update it before it progresses, but it might be useful for you. Larry From owner-ietf-calendar Fri Aug 23 15:29:45 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id PAA05828 for ietf-calendar-bks; Fri, 23 Aug 1996 15:29:45 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id PAA05823 for ; Fri, 23 Aug 1996 15:29:43 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9108.AAD25EA0@yuri.microsoft.com>; Fri, 23 Aug 1996 15:35:09 -0700 Message-ID: From: "Alec Dun (Exchange)" To: "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Date: Fri, 23 Aug 1996 15:35:19 -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 My 2 character example was not very good, especially considering the crux of my argument is space-savings. I do like John's proposal of enclosing the multiple values in { braces }. The only issue I see is how do we handle different modifiers on multi-valued properties. For example, in MIME-dir I can have: Common-Name; Language=de: Burgermeister Common-Name; Language=en: Burgerman Common-Name; Language=en: Burgerdude If we go with the { braces } idea, would we do it this way? Common-Name: { Language=de: Burgermeister, Language=en: Burgerman, Language=en: Burgerdude } ...or would we only allow properties with the same attributes to be repeated within the braces? Common-Name; Language=de: Burgermeister Common-Name; Language=en: { Burgerman, Burgerdude } The other thing I wanted to propose on this topic is that it would be good to require that multi-valued properties be sequential in the mime-dir message body. This would allow me to search for a property and end the search when I hit the last copy of the property rather than requiring that the entire body be parsed. So this would be legal: HomePhone: 1-800-555-1234 Common-Name; Language=de: Burgermeister Common-Name; Language=en: Burgerman but this would not: Common-Name; Language=de: Burgermeister HomePhone: 1-800-555-1234 Common-Name; Language=en: Burgerman Thanks, Alec. >---------- >From: Einar Stefferud[SMTP:Stef@nma.com] >Sent: Friday, August 23, 1996 1:03 PM >To: ietf-asid@umich.edu; ietf-calendar@imc.org >Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt > >I have always found, dating back to 1960, that storing or conveying >attribute meaning via the absence of an explicit tag (or any other >explicit clue) is a very bad idea, unless you are in a fully closed >system and always know precisely what you are doing with every >attribute and value. > >The Internet is NOT one of these closed systems! Defaulting must be >done with extreme care in the Internet, if it is done at all. So, I >endorse John suggestion to use a multi-valued attribute in place of a >sequence (or set, or list) of individual attributes that use absence >defaulting for all but the first of these line-separated attributes. > >Indeed, one breakthrough aspect of ASID-DIR and ASID-vCARD is exactly >this concept of multivaluesd attributes with convenient and short >sub-attribute tagging within multi valued attributes. > >In Internet Standards, this becomes excrutiating. Look at the >problems we now have with MIME CHARSET as a prime example of what >comes of "efficiencies" like omission of tags, such that default >meaning is attributed to absence of explicit tags. > >Alec is saving 2 characters per attribute. May I ask what Alec is >going to do with these savings? We may have already spent the next >ten years of accumulated savings in this brief discussion. And who is >going to pay for all the extra software effort required to achieve his >saving, and for all the confusion that is likely to follow as this >technology continues to be extended? > >For my money, it has to be a lot easier to deal with a set of names >that are being defined as equivalent to each other by putting them all >in one well labeled attribute. Now I have no need to be concerned >with all those implied inter-attribute relationships > >Cheers...\Stef > >From Klensin's message Fri, 23 Aug 1996 03:28:48 -0400 (EDT): >} >} >}On Thu, 22 Aug 1996 18:25:53 -0700 "Alec Dun (Exchange)" >} wrote: >}>... >}> 2. Efficiency in repeated properties. To increase efficiency, I >}> propose that we allow properties which have the same name to be repeated >}> without the name. In this scheme, the repeated property would inherit >}> the attributes from the previous property. For example: >}> >}> CN: Frank Arthur >}> CN: Arthur Frank >}> CN: Frank >}> >}> would become >}> >}> CN: Frank Arthur >}> :Arthur Frank >}> :Frank >} >}Alec, >} >}From a language design standpoint, I'd recommend against this, >}at least in this form. It has some slightly uncomfortable >}parsing properties relative for environments in which one might >}want to implement things by, e.g., quickly sweeping through the >}file using a hash on the names to insert properties in a list. >}More generally, one doesn't want to need to look ahead and then >}back up if that is avoidable. Doing things with omitted >}property tags implies that one needs strong ordering rules and, >}typically, an extra algorithmic step to guard against bad >}behavior from violations of those rules. One can avoid those >}problems by a careful choice of parsing procedures, but we try >}to avoid imposing that type of constraint unless it is clearly >}needed. >} >}As an alternative, if you want to omit repeated property names, >}consider introducing an iterated list, e.g., >} CN: { Frank Arthur, Arthur Frank, >} Frank } >}in C-ish style or >} Frank Arthur, Arthur Frank, Frank >}if HTML-ish style. >} >}I'll not comment on the other two suggestions at this time. >} >} john >} >} >} >} > From owner-ietf-calendar Fri Aug 23 17:06:04 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id RAA06079 for ietf-calendar-bks; Fri, 23 Aug 1996 17:06:04 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from dolphin.automatrix.com (dolphin.automatrix.com [198.69.29.254]) by imc.org (8.7.4/8.7.3) with SMTP id RAA06074 for ; Fri, 23 Aug 1996 17:05:58 -0700 (PDT) Received: (from skip@localhost) by dolphin.automatrix.com (8.6.12/8.6.12) id UAA07385; Fri, 23 Aug 1996 20:11:43 -0400 Date: Fri, 23 Aug 1996 20:11:43 -0400 From: Skip Montanaro Message-Id: <199608240011.UAA07385@dolphin.automatrix.com> To: "Alec Dun (Exchange)" Cc: "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt In-Reply-To: References: Reply-To: skip@calendar.com (Skip Montanaro) Sender: owner-ietf-calendar@imc.org Precedence: bulk Please forgive me for barging into this discussion in the middle and probably missing the point. I'm on the ietf-calendar list. I don't believe we were all privy to the ietf-asid discussion that went on before ietf-calendar was added to the CC: of this thread. At least it seemed that way to me. Would Common-Name; Language=en: Burgerman Common-Name; Language=en: Burgerdude have the same semantics as Common-Name; Language=en: { Burgerman, Burgerdude } or Common-Name: { Language=en; Burgerman, Language=en; Burgerdude } The thing that made this pop into my head is the Netscape Cookie: header. I know the Apache folks had some problems and had to special-case Cookie: different than other HTTP headers. Deciding whether or not it was beneficial to have multiple occurrences of Common-Name. Mixing my RFC metaphors a bit, I could see where you might legitimately have multiple Received: headers (mix in a little RFC-822) while allowing only a single Cookie: header (toss in a a little HTTP), but that it could be multi-valued (in the sense of lists or associative arrays) using one of the second or third forms above. Skip Montanaro | Musi-Cal: http://concerts.calendar.com/ skip@calendar.com | Conference Calendar: http://conferences.calendar.com/ (518)372-5583 | Python: http://www.python.org/ From owner-ietf-calendar Sun Aug 25 13:40:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA00549 for ietf-calendar-bks; Sun, 25 Aug 1996 13:40:09 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id NAA00544 for ; Sun, 25 Aug 1996 13:40:06 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB928B.AE1016A0@yuri.microsoft.com>; Sun, 25 Aug 1996 13:45:30 -0700 Message-ID: From: "Alec Dun (Exchange)" To: "'Harald.T.Alvestrand@uninett.no'" Cc: "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Date: Sun, 25 Aug 1996 13:45:31 -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 It's more a question of logistics than of extra code. If there is a schema/config file, then I have to update a config file every time there is an updated/changed profile. What if I'm writing a piece of pass-thru code that translates, sorts, searches, or otherwise operates on the data (without understanding it) and passes it along to an application that does understand the profile. The generic code may ship separately from the application code. So now I have to upgrade the generic handling tables and the application software rather than just having to update the application software when the profile changes. We can avoid the problem of endless permutations by requiring that the datatype(s) of a property are defined along with the property itself. For example, I would define "Location" (in the appointment profile) to always be of type text. If the application on the other end understands the appointment profile it can assume "Location" is of type text without even looking at the datatype parameter. Folks that are writing generic code can use the datatype parameter to deal with the property without needing inherent knowledge of the schema and type of the property within that schema. Thanks, Alec. >---------- >From: Harald.T.Alvestrand@uninett.no[SMTP:Harald.T.Alvestrand@uninett.no] >Sent: Sunday, August 25, 1996 12:58 PM >To: Alec Dun (Exchange) >Cc: 'Tim Howes'; 'ietf-asid@umich.edu'; 'ietf-calendar@imc.org' >Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt > >The intermediate mode is to have code that has generic handling >for your datatypes, and a config file that lists the type for >each field. Not much extra code there. > >The irritating thing about having fieldname + datatype is that >EVERYONE has to handle every combination of those that isn't >explicitly outlawed by the specs - the number of silly states >is rather high. > >Grouping: You will get lots of parameters on the datatype line if >there are lots of interesting properties of the data. If you need >them, you need to provide a place for them in the other scheme too: > >Location; datatype=text; language=german; charset=iso-8859-1: > "at the boathouse" > >Things get complex if we need them to be complex, or if we don't clean >them up by thinking hard about what we REALLY need. > >IMHO, Properties doesn't have the guts to be a top level MIME type. >"Not interesting enough", I would say. > > > Harald A > > > From owner-ietf-calendar Sun Aug 25 13:43:07 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA00563 for ietf-calendar-bks; Sun, 25 Aug 1996 13:43:07 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by imc.org (8.7.4/8.7.3) with SMTP id NAA00558 for ; Sun, 25 Aug 1996 13:43:05 -0700 (PDT) From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <07777-0@domen.uninett.no>; Sun, 25 Aug 1996 21:58:40 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: "Alec Dun (Exchange)" cc: "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt In-reply-to: Your message of "Fri, 23 Aug 1996 13:22:34 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Aug 1996 21:58:37 +0200 Message-ID: <7774.841003117@domen.uninett.no> Sender: owner-ietf-calendar@imc.org Precedence: bulk The intermediate mode is to have code that has generic handling for your datatypes, and a config file that lists the type for each field. Not much extra code there. The irritating thing about having fieldname + datatype is that EVERYONE has to handle every combination of those that isn't explicitly outlawed by the specs - the number of silly states is rather high. Grouping: You will get lots of parameters on the datatype line if there are lots of interesting properties of the data. If you need them, you need to provide a place for them in the other scheme too: Location; datatype=text; language=german; charset=iso-8859-1: "at the boathouse" Things get complex if we need them to be complex, or if we don't clean them up by thinking hard about what we REALLY need. IMHO, Properties doesn't have the guts to be a top level MIME type. "Not interesting enough", I would say. Harald A From owner-ietf-calendar Mon Aug 26 10:07:26 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA05849 for ietf-calendar-bks; Mon, 26 Aug 1996 10:07:26 -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 KAA05837 for ; Mon, 26 Aug 1996 10:06:16 -0700 (PDT) Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA125874; Mon, 26 Aug 1996 13:10:07 -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 NAA11106 for ; Mon, 26 Aug 1996 13:10:06 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA2686; Mon, 26 Aug 96 13:09:38 -0400 Message-Id: <9608261709.AA2686@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 92FF761BFC1C5B0685256392005CE5ED; Mon, 26 Aug 96 13:09:30 To: Larry Masinter Cc: ralden , ietf-asid , ietf-calendar From: Frank Dawson Date: 26 Aug 96 12:56:18 Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Larry: You wrote: >>>Maybe you could just make your data into URLs, and then use "data:" >>>URLs if you want it inline. I don't think that a URL satsifies all of the data exchange requirements. However, including a URL reference within the data in order to be able to refresh from the source does seem to make sense. - - Frank Dawson From owner-ietf-calendar Mon Aug 26 12:27:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA06267 for ietf-calendar-bks; Mon, 26 Aug 1996 12:27:09 -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 MAA06262 for ; Mon, 26 Aug 1996 12:27:06 -0700 (PDT) Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA89960; Mon, 26 Aug 1996 15:31:08 -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 PAA226380 for ; Mon, 26 Aug 1996 15:31:06 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA4240; Mon, 26 Aug 96 15:30:40 -0400 Message-Id: <9608261930.AA4240@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 60F104B311A4074285256392005F2AC9; Mon, 26 Aug 96 15:30:37 To: ietf-asid , ietf-calendar From: Frank Dawson Date: 26 Aug 96 13:20:03 Subject: Examples Are Somewhat Confusing Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Alec: I am somewhat confused by your examples...or at least not sure of the extent they may imply in terms of your proposals. Are they meant to be another PROFILE type? They are not PROFILE=vCard based. This is somewhat confusing. What is the complete gist of your discussions? Are you also in this discussion proposing changes to the vCard profile? Are you proposing yet another profile? You used the example: >> Common-Name; Language=de: Burgermeister >> Common-Name; Language=en: Burgerman This used type parameter construct (ie, "LANGUAGE=en)". Why then did you not use the same construct on the telephone number (ie, "TEL;TYPE=HOME:1-800-555-1234), when you used "HOMEPHONE:1-800-5555-1234"? This was very confusing to allow type parameters on one type and not use it on another. How would all the other characteristics of a telephone number be specified. Hopefully, not with additional types (eg, not with WORKPHONE, OTHERWORKPHONE, PREFERREDWORKPHONE, GSMCELLULARPHONE, CARPHONE, etc). In addition, the minimal solution, with least astonishment appears to be that of specifying a property multiple times rather than a more complex grammar with value field delimiters for multiple values (ie, not TEL:{800-555-1234; 800-999-9876} but rather TEL:800-555-1234 CRLF TEL:800-999-9876). This would also apply to the case of multiple values for the formatted name or the structured name properties. It would be good to make use one of the existing profiles for your examples, so that the discussion is not clouded by the possible confusion with cross issues such as this. You also proposed: >> The other thing I wanted to propose on this topic is that it would be >> good to require that multi-valued properties be sequential in the >> mime-dir message body. This would allow me to search for a property and >> end the search when I hit the last copy of the property rather than >> requiring that the entire body be parsed. So this would be legal: This type of sequencing mandate for content is putting us on a very slippery slope. I don't believe that this is very efficient or useful to a broad class of originating or receiving applications for this data. One should be able to sequence the properties within the body of such a content type as one finds efficient or even convenient. I don't agree with this type of limitation on creating a data stream. I don't even understand how you will know that you have "hit the last copy of the property" until you have parsed the complete content information. This isn't a good idea to me. Cheers. - - Frank Dawson From owner-ietf-calendar Mon Aug 26 12:32:41 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA06296 for ietf-calendar-bks; Mon, 26 Aug 1996 12:32:41 -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 MAA06291 for ; Mon, 26 Aug 1996 12:32:37 -0700 (PDT) Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA42204; Mon, 26 Aug 1996 15:36: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 PAA29276 for ; Mon, 26 Aug 1996 15:36:36 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA4330; Mon, 26 Aug 96 15:36:05 -0400 Message-Id: <9608261936.AA4330@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 2667D212AF07DB3E85256392005D29B8; Mon, 26 Aug 96 15:35:53 To: "Alec Dun (Exchange)" Cc: "'Harald.T.Alvestrand@uninett.no'" , "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" From: Frank Dawson Date: 26 Aug 96 13:05:30 Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Alex: One of my concerns with this generic approach is that it makes every problem look like a "nail"; 'cause what you have as a tool is a "hammer". If I only have INTEGER, STRING, FLOAT, CURRENCY, DATETIME data types, then we are inclined by the constraints to solve our problem using these elementary types rather than the natural object types of the problem domain (ie, all problems look like a "nail" problem). This is not to say that adding a DATATYPE type parameter does not make some sense. It just should not be mandated. The other concern is that MIME content types are now being used outside of a MIME email transport environment. This is great! However, it also places additional design considerations on our work. All problems are not just solved by a "hammer" or in this case an email solution domain. Cheers. - - Frank Dawson To: Harald.T.Alvestrand @ uninett.no ("'Harald.T.Alvestrand@uninett.no'") @ RTPSMTP cc: howes @ netscape.com ("'Tim Howes'") @ RTPSMTP, ietf-asid @ umich.edu ("'ietf-asid@umich.edu'") @ RTPSMTP, ietf-calendar @ imc.org ("'ietf-calendar@imc.org'") @ RTPSMTP (bcc: Frank Dawson) From: AlecDu @ exchange.microsoft.com ("Alec Dun (Exchange)") @ RTPSMTP Date: 08/23/96 01:22:34 PM Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Security: On the datatypes issue: the key reason I want the datatype parameter is to enable generic property handling code to be written. For example, imagine that I have a bunch of messages containing mime-dir body parts. Now I want to write a generic piece of code that searches for items where a specified property (for example meetingdate) has Date > 1 Aug 96 and Date < 31 Aug 96 in each message. I could write the search code one of two ways. a. I could have the search code implicitly understand every field, what it means, and how to interpret it. If new profiles and fields get defined, I need to modify the code to be able to do the search. b. I could have generic search code that only needs to understand how to do comparisons on a given datatype. If new fields get defined, I don't need to modify the search code at all. >How would I interpret sensibly > >CN;datatype=currency: NOK >CN;datatype=url: http://somewhere.in.cn/~zhu/myname.gif I would expect CN to always be of datatype=text. The added value of clearly identifying the datatype=text is that you allow serach/sort/storage/etc code to handle the property generically without having to special-case the type of each property. On the grouping issue, I'm not so worried about the simple case that you point out, but what if there are a lot of parameters on the body part header? Is the "Content-Type:" optional? >--xx >app/dir;profile=meetingdetails > >Location; datatype=text: "At the boathose" >Date; datatype=date: 11 Aug 96 >Time; datatype=time: 10:30:00 could look like: >--xx Content-Type: application/directory; charset=iso-8859-1; > language=german; profile=meetingdetails > >Location; datatype=text: "At the boathose" >Date; datatype=date: 11 Aug 96 >Time; datatype=time: 10:30:00 Also, what do you think about "properties/" (ie. "properties/directory" and "properties/appointment") as a top level mime type? Thanks, Alec. >---------- >From: Harald.T.Alvestrand@uninett.no[SMTP:Harald.T.Alvestrand@uninett.no] >Sent: Friday, August 23, 1996 5:02 AM >To: Alec Dun (Exchange) >Cc: 'Tim Howes'; 'ietf-asid@umich.edu'; 'ietf-calendar@imc.org' >Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt > >Alec, > >I think datatypes need to be part of the attribute definition, not of >the attribute value. > >How would I interpret sensibly > >CN;datatype=currency: NOK >CN;datatype=url: http://somewhere.in.cn/~zhu/myname.gif > >when I want to put the CN into a mailing list? > >The grouping needs more thought - your example of a meeting with >attendees is one example of use of this. But I think the overhead >compared to a bunch of separate MIME objects is actually quite low; >you save about 1 line per object. > >Your example: > >begin: meetingdetails >Location; datatype=text: "At the boathose" >Date; datatype=date: 11 Aug 96 >Time; datatype=time: 10:30:00 >begin: meetingattendee >CN: Frank Arthur >SN: Jones >Status: Required >begin: meetingattendee >CN: James George >SN: Brown >Status: Optional > >becomes > >--xx >app/dir;profile=meetingdetails > >Location; datatype=text: "At the boathose" >Date; datatype=date: 11 Aug 96 >Time; datatype=time: 10:30:00 >--xx >app/dir;profile=meetingattendee > >CN: Frank Arthur >SN: Jones >Status: Required >--xx >app/dir;profile=meetingattendee > >CN: James George >SN: Brown >Status: Optional >--xx-- > >Not a world of difference; think about whether we want the additional >complexity in one parser, rather than having two of them. >(I left out the links; not sure we need them) > > Harald A > > > From owner-ietf-calendar Mon Aug 26 17:19:59 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id RAA00644 for ietf-calendar-bks; Mon, 26 Aug 1996 17:19:59 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id RAA00639 for ; Mon, 26 Aug 1996 17:19:55 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9373.930C0060@yuri.microsoft.com>; Mon, 26 Aug 1996 17:25:28 -0700 Message-ID: From: "Alec Dun (Exchange)" To: "'ietf-asid'" , "'ietf-calendar'" , "'Frank Dawson'" Subject: RE: Examples Are Somewhat Confusing Date: Mon, 26 Aug 1996 17:25:34 -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 Frank, Actually, I was trying to focus on discussing the mime-dir draft (which is not schema specific). My examples are just that, random examples illustrating various points. According to the current mime-dir-02 draft, the following (schema independent) are legal ways to represent a phone number in a schema. >1. TEL; TYPE=HOME: 1-800-555-1234 >2. HOMEPHONE: 1-800-5555-1234 3. TEL; HOME, CELL: 1-800-555-1234 4. THIS-IS-JUST-AN-EXAMPLE: 1-800-555-1234 So I don't believe there is any problem representing a current v-card phone number as a property in MIME-DIR. >>> The other thing I wanted to propose on this topic is that it would be >>> good to require that multi-valued properties be sequential in the >>> mime-dir message body. This would allow me to search for a property and >>> end the search when I hit the last copy of the property rather than >>> requiring that the entire body be parsed. So this would be legal: > >This type of sequencing mandate for content is putting us on a very slippery >slope. I don't believe that this is very efficient or useful to a broad class >of originating or receiving applications for this data. One should be able to >sequence the properties within the body of such a content type as one finds >efficient or even convenient. I don't agree with this type of limitation on >creating a data stream. I don't even understand how you will know that you >have >"hit the last copy of the property" until you have parsed the complete >content >information. This isn't a good idea to me. The reason I proposed this was because if I am searching thru properties, I must search thru all the properties in the body part to determine if I have the complete set of TEL properties, instead of being able to quit when I hit the last TEL property. This saves time for a linear search engine. If you're searching thru a lot of items, this savings will become a large additive time/resource savings. I think I understand where you're coming from. There may be v-card backward compatibility issues here where some existing v-cards are in a random order. Also, I don't know if v-card encourages this, but if people enter these manually, then that may be a problem too. How about this. When they're outside MIME-DIR, v-cards stay like they are (random order). When they get put inside a MIME-DIR body part, they must be grouped, fixed-order. Since MIME-DIR is not yet a standard, nobody has code to put v-card in a MIME-DIR body part and we don't have to worry about people re-implementing things. The format is forward compatible because all the old v-card reading code can handle random or fixed order. Does this make sense? Thanks, Alec. >---------- >From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] >Sent: Monday, August 26, 1996 6:20 AM >To: ietf-asid; ietf-calendar >Subject: Examples Are Somewhat Confusing > >Alec: > >I am somewhat confused by your examples...or at least not sure of the extent >they may imply in terms of your proposals. > >Are they meant to be another PROFILE type? They are not PROFILE=vCard based. >This is somewhat confusing. What is the complete gist of your discussions? >Are >you also in this discussion proposing changes to the vCard profile? Are you >proposing yet another profile? > >You used the example: > >>> Common-Name; Language=de: Burgermeister >>> Common-Name; Language=en: Burgerman > >This used type parameter construct (ie, "LANGUAGE=en)". Why then did you not >use the same construct on the telephone number (ie, >"TEL;TYPE=HOME:1-800-555-1234), when you used "HOMEPHONE:1-800-5555-1234"? >This >was very confusing to allow type parameters on one type and not use it on >another. How would all the other characteristics of a telephone number be >specified. Hopefully, not with additional types (eg, not with WORKPHONE, >OTHERWORKPHONE, PREFERREDWORKPHONE, GSMCELLULARPHONE, CARPHONE, etc). > >In addition, the minimal solution, with least astonishment appears to be that >of specifying a property multiple times rather than a more complex grammar >with >value field delimiters for multiple values (ie, not TEL:{800-555-1234; >800-999-9876} but rather TEL:800-555-1234 CRLF TEL:800-999-9876). This would >also apply to the case of multiple values for the formatted name or the >structured name properties. > >It would be good to make use one of the existing profiles for your examples, >so >that the discussion is not clouded by the possible confusion with cross >issues >such as this. > >You also proposed: > >>> The other thing I wanted to propose on this topic is that it would be >>> good to require that multi-valued properties be sequential in the >>> mime-dir message body. This would allow me to search for a property and >>> end the search when I hit the last copy of the property rather than >>> requiring that the entire body be parsed. So this would be legal: > >This type of sequencing mandate for content is putting us on a very slippery >slope. I don't believe that this is very efficient or useful to a broad class >of originating or receiving applications for this data. One should be able to >sequence the properties within the body of such a content type as one finds >efficient or even convenient. I don't agree with this type of limitation on >creating a data stream. I don't even understand how you will know that you >have >"hit the last copy of the property" until you have parsed the complete >content >information. This isn't a good idea to me. > >Cheers. > >- - Frank Dawson > > > From owner-ietf-calendar Mon Aug 26 17:57:41 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id RAA00745 for ietf-calendar-bks; Mon, 26 Aug 1996 17:57:41 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id RAA00740 for ; Mon, 26 Aug 1996 17:57:36 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9378.DC00D020@yuri.microsoft.com>; Mon, 26 Aug 1996 18:03:17 -0700 Message-ID: From: "Alec Dun (Exchange)" To: "'Frank Dawson'" Cc: "'Harald.T.Alvestrand@uninett.no'" , "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Date: Mon, 26 Aug 1996 18:03:20 -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 Frank, The datatype parameter is optional. New datatypes can be defined using IANA or X-. The analogy of a "making every problem look like a nail to a hammer" could be applied to almost any internet standard. For example: RFC 1521 defines the definition/syntax of a mime body part which makes all body parts look like a nail to a MIME body-part parser (hammer). Another example: v-card defines a generic way to represent a contact, all v-card contacts look like nails to a v-card contact parser (hammer). Although I understand the nail/hammer anology, I'm unclear why you think pushing for standards (definitions of nails and how hammers should hit them) is a bad thing. If you have a specific need, just say what it is so your needs for the shape of the nail/hammer can be accomodated by the working group. Thanks, Alec. >---------- >From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] >Sent: Monday, August 26, 1996 6:05 AM >To: Alec Dun (Exchange) >Cc: 'Harald.T.Alvestrand@uninett.no'; 'Tim Howes'; 'ietf-asid@umich.edu'; >'ietf-calendar@imc.org' >Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt > >Alex: > >One of my concerns with this generic approach is that it makes every problem >look like a "nail"; 'cause what you have as a tool is a "hammer". > >If I only have INTEGER, STRING, FLOAT, CURRENCY, DATETIME data types, then we >are inclined by the constraints to solve our problem using these elementary >types rather than the natural object types of the problem domain (ie, all >problems look like a "nail" problem). > >This is not to say that adding a DATATYPE type parameter does not make some >sense. It just should not be mandated. > >The other concern is that MIME content types are now being used outside of a >MIME email transport environment. This is great! However, it also places >additional design considerations on our work. All problems are not just >solved >by a "hammer" or in this case an email solution domain. > >Cheers. > >- - Frank Dawson > > > > > >To: Harald.T.Alvestrand @ uninett.no ("'Harald.T.Alvestrand@uninett.no'") @ >RTPSMTP >cc: howes @ netscape.com ("'Tim Howes'") @ RTPSMTP, ietf-asid @ umich.edu >("'ietf-asid@umich.edu'") @ RTPSMTP, ietf-calendar @ imc.org >("'ietf-calendar@imc.org'") @ RTPSMTP (bcc: Frank Dawson) >From: AlecDu @ exchange.microsoft.com ("Alec Dun (Exchange)") @ RTPSMTP >Date: 08/23/96 01:22:34 PM >Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt >Security: > >On the datatypes issue: the key reason I want the datatype parameter is >to enable generic property handling code to be written. > >For example, imagine that I have a bunch of messages containing mime-dir >body parts. Now I want to write a generic piece of code that searches >for items where a specified property (for example meetingdate) has Date >> 1 Aug 96 and Date < 31 Aug 96 in each message. I could write the >search code one of two ways. > >a. I could have the search code implicitly understand every field, what >it means, and how to interpret it. If new profiles and fields get >defined, I need to modify the code to be able to do the search. > >b. I could have generic search code that only needs to understand how >to do comparisons on a given datatype. If new fields get defined, I >don't need to modify the search code at all. > >>How would I interpret sensibly >> >>CN;datatype=currency: NOK >>CN;datatype=url: http://somewhere.in.cn/~zhu/myname.gif > >I would expect CN to always be of datatype=text. The added value of >clearly identifying the datatype=text is that you allow >serach/sort/storage/etc code to handle the property generically without >having to special-case the type of each property. > > > >On the grouping issue, I'm not so worried about the simple case that you >point out, but what if there are a lot of parameters on the body part >header? Is the "Content-Type:" optional? > >>--xx >>app/dir;profile=meetingdetails >> >>Location; datatype=text: "At the boathose" >>Date; datatype=date: 11 Aug 96 >>Time; datatype=time: 10:30:00 > >could look like: > >>--xx >Content-Type: application/directory; charset=iso-8859-1; >> language=german; profile=meetingdetails >> >>Location; datatype=text: "At the boathose" >>Date; datatype=date: 11 Aug 96 >>Time; datatype=time: 10:30:00 > > >Also, what do you think about "properties/" (ie. >"properties/directory" and "properties/appointment") as a top level mime >type? > >Thanks, >Alec. > >>---------- >>From: Harald.T.Alvestrand@uninett.no[SMTP:Harald.T.Alvestrand@uninett.no] >>Sent: Friday, August 23, 1996 5:02 AM >>To: Alec Dun (Exchange) >>Cc: 'Tim Howes'; 'ietf-asid@umich.edu'; 'ietf-calendar@imc.org' >>Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt >> >>Alec, >> >>I think datatypes need to be part of the attribute definition, not of >>the attribute value. >> >>How would I interpret sensibly >> >>CN;datatype=currency: NOK >>CN;datatype=url: http://somewhere.in.cn/~zhu/myname.gif >> >>when I want to put the CN into a mailing list? >> >>The grouping needs more thought - your example of a meeting with >>attendees is one example of use of this. But I think the overhead >>compared to a bunch of separate MIME objects is actually quite low; >>you save about 1 line per object. >> >>Your example: >> >>begin: meetingdetails >>Location; datatype=text: "At the boathose" >>Date; datatype=date: 11 Aug 96 >>Time; datatype=time: 10:30:00 >>begin: meetingattendee >>CN: Frank Arthur >>SN: Jones >>Status: Required >>begin: meetingattendee >>CN: James George >>SN: Brown >>Status: Optional >> >>becomes >> >>--xx >>app/dir;profile=meetingdetails >> >>Location; datatype=text: "At the boathose" >>Date; datatype=date: 11 Aug 96 >>Time; datatype=time: 10:30:00 >>--xx >>app/dir;profile=meetingattendee >> >>CN: Frank Arthur >>SN: Jones >>Status: Required >>--xx >>app/dir;profile=meetingattendee >> >>CN: James George >>SN: Brown >>Status: Optional >>--xx-- >> >>Not a world of difference; think about whether we want the additional >>complexity in one parser, rather than having two of them. >>(I left out the links; not sure we need them) >> >> Harald A >> >> >> > > > > > From owner-ietf-calendar Mon Aug 26 18:14:11 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id SAA00823 for ietf-calendar-bks; Mon, 26 Aug 1996 18:14:11 -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 SAA00818 for ; Mon, 26 Aug 1996 18:14:06 -0700 (PDT) Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA23688; Mon, 26 Aug 1996 21:18:04 -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 VAA39048 for ; Mon, 26 Aug 1996 21:18:02 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA6405; Mon, 26 Aug 96 21:17:35 -0400 Message-Id: <9608270117.AA6405@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 87C20DDF8A43C2BB852563930005CE26; Mon, 26 Aug 96 21:17:30 To: "Alec Dun (Exchange)" Cc: "'ietf-asid'" , "'ietf-calendar'" , "'Frank Dawson'" From: Frank Dawson Date: 26 Aug 96 21:11:59 Subject: RE: Examples Are Somewhat Confusing Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Alec: I appreciate your answering my questions. Thanks. The required sequencing of the content information beyond boundary sentinels seem somewhat harsh. You have made a point that a search engine can be optimized if it predictable that the vCard or other application/directory content has such a sequencing order. It just seems an unnecessarily restrictive a request. Saying the header must appear before the body, and in the body, the body header must appear before the body content is an appropriate level of required ordering. But beyond that, it might be a bit restrictive. The size of these things are not really very large. For a vCard, we see less than 500 bytes on average. That is really small. This ordering is not going to improve efficiency to the point of paying for the restriction on generating these content portions. - - Frank Dawson From owner-ietf-calendar Mon Aug 26 18:37:16 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id SAA00880 for ietf-calendar-bks; Mon, 26 Aug 1996 18:37:16 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id SAA00875 for ; Mon, 26 Aug 1996 18:37:15 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB937E.664A7A60@yuri.microsoft.com>; Mon, 26 Aug 1996 18:42:57 -0700 Message-ID: From: "Alec Dun (Exchange)" To: "'Frank Dawson'" Cc: "'ietf-asid'" , "'ietf-calendar'" Subject: RE: Examples Are Somewhat Confusing Date: Mon, 26 Aug 1996 18:43:03 -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 Hi Frank, The vCard may be 500 bytes, but I may have 10,000 of them. That's 5Mb of data I have to look thru (if I'm doing a linear search), and if, on average, I can stop searching 1/2 way thru a v-card because I found all the properties that I need to do the comparison, I can avoid parsing 2.5Mb of data. What specifically is the down-side here that worries you? Thanks, Alec. >---------- >From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] >Sent: Monday, August 26, 1996 2:11 PM >To: Alec Dun (Exchange) >Cc: 'ietf-asid'; 'ietf-calendar'; 'Frank Dawson' >Subject: RE: Examples Are Somewhat Confusing > >Alec: > >I appreciate your answering my questions. Thanks. > >The required sequencing of the content information beyond boundary sentinels >seem somewhat harsh. You have made a point that a search engine can be >optimized if it predictable that the vCard or other application/directory >content has such a sequencing order. > >It just seems an unnecessarily restrictive a request. Saying the header must >appear before the body, and in the body, the body header must appear before >the >body content is an appropriate level of required ordering. But beyond that, >it >might be a bit restrictive. > >The size of these things are not really very large. For a vCard, we see less >than 500 bytes on average. That is really small. This ordering is not going >to >improve efficiency to the point of paying for the restriction on generating >these content portions. > >- - Frank Dawson > From owner-ietf-calendar Mon Aug 26 18:45:46 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id SAA00904 for ietf-calendar-bks; Mon, 26 Aug 1996 18:45:46 -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 SAA00899 for ; Mon, 26 Aug 1996 18:45:37 -0700 (PDT) Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA77474; Mon, 26 Aug 1996 21:49:44 -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 VAA36460 for ; Mon, 26 Aug 1996 21:49:44 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA6521; Mon, 26 Aug 96 21:49:15 -0400 Message-Id: <9608270149.AA6521@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id EC75CDBEB7876A43852563930006F8DB; Mon, 26 Aug 96 21:49:02 To: "Alec Dun (Exchange)" Cc: "'Frank Dawson'" , "'Harald.T.Alvestrand @uninett.no'" , "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar @imc.org'" From: Frank Dawson Date: 26 Aug 96 21:45:38 Subject: I've Got A Hammer... Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Alec: The data typing seems to require that the type definitions (ie, new properties) be cast as: 1. One of these proprosed standardized data types (eg, INTEGER, FLOAT, etc), or 2. As a new registered data type (ie, via IANA processing), or 3. As a non-standard data type (eg, X-xyz-FOOTYPE). This will make it somewhat cumbersome to define a new type such a structured or multi-valued type (eg, a property with the form of: FOOTYPE:myname;me@host;OWNER;CONFIRMED or BARTYPE:date;date;date;date). Now, most folks are just not going to go to the trouble of defining a new data type with the IANA. This is a pain. They will also realize that the non-standardized data types have a small hope in being accepted by implementations. This leaves the low easier approach which is to use the existing "nail" to solve the data representation problem. Who have we helped here? It seems to me we have just limited our data definition capabilities. That is why data representation grammars go to the lengths that they do to allow for constructed types. Now if we go down that line of thinking, we are back to using NDL, ASN.1, Crocker's STIF, etc. But, this does not seem like a low cost, low chat approach to this problem. In the "application/directory" domain we already have LDAP to address this. So...that is the thoughts behind my reference to the "nail" and "hammer". Cheers. - - Frank Dawson From owner-ietf-calendar Mon Aug 26 18:54:56 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id SAA00932 for ietf-calendar-bks; Mon, 26 Aug 1996 18:54:56 -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 SAA00927 for ; Mon, 26 Aug 1996 18:54:41 -0700 (PDT) Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA128000; Mon, 26 Aug 1996 21:58:47 -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 VAA97666 for ; Mon, 26 Aug 1996 21:58:44 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA6562; Mon, 26 Aug 96 21:58:18 -0400 Message-Id: <9608270158.AA6562@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 85D9EEA783EB51E9852563930009C59D; Mon, 26 Aug 96 21:58:10 To: "Alec Dun (Exchange)" Cc: "'Frank Dawson'" , "'ietf-asid'" , "'ietf-calendar'" From: Frank Dawson Date: 26 Aug 96 21:52:25 Subject: RE: Examples Are Somewhat Confusing Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Alec: Isn't your engine going to be sorting on the message headers and the body headers? I doubt that your server will be sorting on the information in the content body. That is like sorting my in-basket based on the first 5 words in each message. I seriously doubt this. I don't think this a realistic argument for this. Cheers. -- Frank Dawson From owner-ietf-calendar Mon Aug 26 19:47:47 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id TAA01115 for ietf-calendar-bks; Mon, 26 Aug 1996 19:47:47 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id TAA01110 for ; Mon, 26 Aug 1996 19:47:45 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9388.40042770@yuri.microsoft.com>; Mon, 26 Aug 1996 19:53:28 -0700 Message-ID: From: "Alec Dun (Exchange)" To: "'Frank Dawson'" Cc: "'ietf-asid'" , "'ietf-calendar'" Subject: RE: Examples Are Somewhat Confusing Date: Mon, 26 Aug 1996 19:53:34 -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 Frank, I wouldn't do a plain text search thru the body like you are suggesting, I'd look in the mime body part and search for specific properties and deteremine if they matched a specific value that I was searching for. If the objects were contacts, and I was writing a piece of contact management software, I'd provide my users with a way to sort the contacts by last name or first name or switch between them. I'd also want them to be able to search based on the company I worked at. For example, I want to see everyone where "CN" = "Frank" and "Company" = "IBM". Thanks, Alec. >---------- >From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] >Sent: Monday, August 26, 1996 2:52 PM >To: Alec Dun (Exchange) >Cc: 'Frank Dawson'; 'ietf-asid'; 'ietf-calendar' >Subject: RE: Examples Are Somewhat Confusing > >Alec: > >Isn't your engine going to be sorting on the message headers and the body >headers? I doubt that your server will be sorting on the information in the >content body. That is like sorting my in-basket based on the first 5 words in >each message. I seriously doubt this. > >I don't think this a realistic argument for this. > >Cheers. > >-- Frank Dawson > From owner-ietf-calendar Mon Aug 26 20:13:27 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id UAA01258 for ietf-calendar-bks; Mon, 26 Aug 1996 20:13:27 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id UAA01253 for ; Mon, 26 Aug 1996 20:13:25 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB938B.D6083560@yuri.microsoft.com>; Mon, 26 Aug 1996 20:19:08 -0700 Message-ID: From: "Alec Dun (Exchange)" To: "'Frank Dawson'" Cc: "'Harald.T.Alvestrand@uninett.no'" , "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: RE: I've Got A Hammer... Date: Mon, 26 Aug 1996 20:19:14 -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 If you want the following data to interopreate with other apps: >FOOTYPE:myname;me@host;OWNER;CONFIRMED BARTYPE:date;date;date;date ...then you have to coordinate with others on the format of the data and schema, right? ...otherwise my app won't have a clue how to interpret your data. Ideally, the way to coordinate the format of the data and schema with others is thru IETF or IANA. During approval, the format of the data needs to be explicitly layed out to ensure people know how to send and interpret the data. I think people defining a new property with a special datatype actually would want to go out of your way to go thru IANA and IETF, if they are interested in interoperating, right? For those that don't care about interoperating with others, there is the x-fooproptype, right? All the properties in a schema must be strongly typed. btw, do you realize that the way mime-dir-02 is defined today you'd have to go thru IANA to get an additional v-card property added to a v-card profile? For example, if I wanted to add "BARTYPE:date;date;date;date" to the v-card profile, I'd have to go thru IANA to add "BARTYPE". If you want to skip IANA, you'd have to make this "x-BARTYPE:date;date;date;date". Thanks, Alec. >---------- >From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] >Sent: Monday, August 26, 1996 2:45 PM >To: Alec Dun (Exchange) >Cc: 'Frank Dawson'; 'Harald.T.Alvestrand@uninett.no'; 'Tim Howes'; >'ietf-asid@umich.edu'; 'ietf-calendar@imc.org' >Subject: I've Got A Hammer... > >Alec: > >The data typing seems to require that the type definitions (ie, new >properties) >be cast as: > >1. One of these proprosed standardized data types (eg, INTEGER, FLOAT, etc), >or >2. As a new registered data type (ie, via IANA processing), or >3. As a non-standard data type (eg, X-xyz-FOOTYPE). > >This will make it somewhat cumbersome to define a new type such a structured >or >multi-valued type (eg, a property with the form of: >FOOTYPE:myname;me@host;OWNER;CONFIRMED or BARTYPE:date;date;date;date). > >Now, most folks are just not going to go to the trouble of defining a new >data >type with the IANA. This is a pain. They will also realize that the >non-standardized data types have a small hope in being accepted by >implementations. This leaves the low easier approach which is to use the >existing "nail" to solve the data representation problem. > >Who have we helped here? It seems to me we have just limited our data >definition capabilities. That is why data representation grammars go to the >lengths that they do to allow for constructed types. Now if we go down that >line of thinking, we are back to using NDL, ASN.1, Crocker's STIF, etc. But, >this does not seem like a low cost, low chat approach to this problem. In the >"application/directory" domain we already have LDAP to address this. > >So...that is the thoughts behind my reference to the "nail" and "hammer". > >Cheers. > >- - Frank Dawson > From owner-ietf-calendar Tue Aug 27 06:50:45 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id GAA05162 for ietf-calendar-bks; Tue, 27 Aug 1996 06:50:45 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from europe.std.com ([199.172.62.20]) by imc.org (8.7.4/8.7.3) with ESMTP id GAA05157 for ; Tue, 27 Aug 1996 06:50:39 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id JAA19312; Tue, 27 Aug 1996 09:56:29 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA10328; Tue, 27 Aug 1996 09:56:28 -0400 Date: Tue, 27 Aug 1996 09:56:28 -0400 From: hanna@world.std.com (Stephen R Hanna) Message-Id: <199608271356.AA10328@world.std.com> To: ietf-calendar@imc.org Subject: Architectural issues Sender: owner-ietf-calendar@imc.org Precedence: bulk All this discussion of data representation is great. I'm glad to see things converging on a simple set of property-value pairs. As I understand the discussion in July, the group decided to start several simultaneous efforts. One would focus on defining a format for representing C&S objects. Another would focus on defining a set of verbs which can be used to manipulate these objects. A third effort would define the architecture of the system, focusing on agents and roles. Others were working on the charter for the proposed WG. Where do these other projects stand? I'm most interested in the verbs and architecture (agents/roles) discussions. Anybody care to chat about those? *Architecture (agents/roles)* For architecture (agents/roles), I would suggest that we allow for several usage scenarios: Client-server: A protocol is defined that allows a client to receive appointments from a server and send appointments to others via the server. This would allow any client to be compatible with any server, like POP3 or IMAP. Interoperability: A protocol is defined that allows one scheduling system to send appointments to another scheduling system or respond to proposals previously received. This will allow scheduling systems to interoperate so that appointments may easily be sent to any one, regardless of what scheduling system they use. Changes to appointments and responses to appointments may be sent the same way. Free-form: The same objects used in the previous scenarios (appointments with verbs) may be stored or transmitted via any mechanism (email, WWW, or floppy disk). The user may deliver an appointment object via drag and drop, clipboard, or other mechanism and it can be incorporated into their calendar. Optionally, the protocol described in the interoperability scenario above may be used to establish a link between the user's calendar and the appointment's originator so that appointment changes and responses may be exchanged. *Verbs* For verbs, I would throw out the following as a first pass: appt-announce: Announces an appointment. May also be used to announce changes to an appointment. This verb would be used in all three scenarios. In client-server, clients announce new or changed appointments to their server and the server announces new or changed appointments received from elsewhere to the client. In interoperability, scheduling systems announce new or changed appointments to each other. In free-form, most objects will use the appt-announce verb because there may be no protocol for following up with other verbs. appt-respond: Responds to an appointment. May be used to indicate that an attendee will or will not be able to attend or to supply comments from an attendee. Actually, this verb could be subsumed by the appt-change-request verb. See that verb for more details. appt-change-request: Requests a change to an appointment. This verb could be used both to replace the appt-respond verb described above and to allow the client to change an appointment in the client-server scenario. Objects with this verb should probably include only the properties that are being requested to be changed (and any other properties required to establish the object's identity). In the client-server scenario, clients can send appt-change-requests to their server to change appointments. In the interoperability scenario, one system can request a change to an appointment that is owned by another, but this request may be denied based on the identity of the requester and the changes requested. In the free-form scenario, objects with appt-change-request verbs may be created and sent, but there is no defined protocol for transmitting them or receiving any appt-announce verbs that might indicate whether the changes were accepted. *Architectural Concerns* I believe that we may be operating under different assumptions about what an appointment is. I'm sure that the architectural model of our product (Meeting Maker XP) has a profound effect on my understanding of the problems we're trying to address and the solutions we choose to use. In the interests of openness, I'll share these assumptions with the rest of you and ask that you do the same for me. For our product, an appointment is an event with at least one time associated with it. It may have a title, an agenda, a guest list (including resources such as a slide projector), one or more locations, etc. I want to focus on the roles/agents of our model, so I'll skip any more discussion of event-specific data. One of our key customer requirements is that we manage access to this appointment, allowing authorized users to make changes to the appointment and making sure that all guests (including CC guests) are informed of these changes. This model has several implications. In order to track changes to an appointment, we assign each appointment a globally unique id. This allows anyone to receive changes to an appointment and match them up with the old version of the appointment. I believe that the concept of a unique appointment id will serve us well in defining a standard for communicating about appointments. In order to control access to an appointment and maintain a single authoritative copy of its properties, each appointment has a single owner that receives change requests from other agents and announces changes to all interested agents. These two concepts (object identity and object ownership) are crucial to our model of how appointments are managed. We use a client-server model with distributed object databases connected via RPCs, but I believe that these two concepts are generally applicable in this problem domain. I would be interested to hear from others whether they consider these concepts equally important. Looking forward to some interesting discussions, Steve Hanna ON Technology Corporation hanna@world.std.com (617) 692-3153 From owner-ietf-calendar Tue Aug 27 09:04:42 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA05633 for ietf-calendar-bks; Tue, 27 Aug 1996 09:04:42 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from nugget.scr.atm.com ([206.100.186.2]) by imc.org (8.7.4/8.7.3) with SMTP id JAA05627 for ; Tue, 27 Aug 1996 09:04:30 -0700 (PDT) Received: from mailman.scr.atm.com (mailman.scr.atm.com [206.100.186.54]) by nugget.scr.atm.com (8.6.12/8.6.9) with ESMTP id JAA06532 for ; Tue, 27 Aug 1996 09:15:06 -0700 From: izzy@nugget.scr.atm.com (Dr. Mark K. Joseph) To: hanna@world.std.com Cc: ietf-calendar@imc.org Date: Tue, 27 Aug 1996 09:03:06 -0700 MIME-Version: 1.0 Message-ID: <19960827160306.izzy@scr.atm.com> In-Reply-To: <199608271356.AA10328@world.std.com> Subject: RE: Architectural issues X-Mailer: Emissary V2.01, by Attachmate Corp. Content-Type: multipart/mixed; boundary="=_27tW07g.bO1996u.N16d000A.r08Y.03:005c56" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk --=_27tW07g.bO1996u.N16d000A.r08Y.03:005c56 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 27 Aug 1996 06:56:28 -0700 Stephen R Hanna wrote: > >*Architecture (agents/roles)* > >For architecture (agents/roles), I would suggest that we allow for >several usage scenarios: > >Client-server: A protocol is defined that allows a client to receive >appointments from a server and send appointments to others via the >server. This would allow any client to be compatible with any server, >like POP3 or IMAP. > I would like to add in addition to client-server the additional usage scenario of: Client-Client: via Email or other standard protocol one client can query and send information to another client to set up appointments. For example, my client could send out a verb asking several people for all their free time next week so my scheduling program on my client can set up a common appointment time. A special scheduling server should not be required. --=_27tW07g.bO1996u.N16d000A.r08Y.03:005c56 --=_27tW07g.bO1996u.N16d000A.r08Y.03:005c56-- From owner-ietf-calendar Tue Aug 27 09:11:00 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA05657 for ietf-calendar-bks; Tue, 27 Aug 1996 09:11:00 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from nugget.scr.atm.com ([206.100.186.2]) by imc.org (8.7.4/8.7.3) with SMTP id JAA05652 for ; Tue, 27 Aug 1996 09:10:49 -0700 (PDT) Received: from mailman.scr.atm.com (mailman.scr.atm.com [206.100.186.54]) by nugget.scr.atm.com (8.6.12/8.6.9) with ESMTP id JAA06578 for ; Tue, 27 Aug 1996 09:21:37 -0700 From: izzy@nugget.scr.atm.com (Dr. Mark K. Joseph) To: hanna@world.std.com Cc: ietf-calendar@imc.org Date: Tue, 27 Aug 1996 09:09:37 -0700 MIME-Version: 1.0 Message-ID: <19960827160937.izzy@scr.atm.com> In-Reply-To: <199608271356.AA10328@world.std.com> Subject: RE: Architectural issues X-Mailer: Emissary V2.01, by Attachmate Corp. Content-Type: multipart/mixed; boundary="=_27tW38g.bO1996u.N16d000A.r08Y.09:006153" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk --=_27tW38g.bO1996u.N16d000A.r08Y.09:006153 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 27 Aug 1996 06:56:28 -0700 Stephen R Hanna wrote: > >*Verbs* > >For verbs, I would throw out the following as a first pass: > >appt-announce: Announces an appointment. May also be used to announce >changes to an appointment. This verb would be used in all three >scenarios. > >appt-respond: Responds to an appointment. May be used to indicate that >an attendee will or will not be able to attend or to supply comments >from an attendee. Actually, this verb could be subsumed by the >appt-change-request verb. See that verb for more details. > >appt-change-request: Requests a change to an appointment. This verb >could be used both to replace the appt-respond verb described above >and to allow the client to change an appointment in the client-server >scenario. Objects with this verb should probably include only the >properties that are being requested to be changed (and any other >properties required to establish the object's identity). > For client-client cases how about adding: appt-query-freetime: one client requests the other client to provide chunks of free time in a specific time interval, say one week, one month, etc. And in general: appt-update: provides the attendee with additional or revised information that does not affect the time and location of the meeting but the content of the meeting like an updated agenda. --=_27tW38g.bO1996u.N16d000A.r08Y.09:006153 Content-Type: application/vcard Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="MJOSEPH.VCF" Content-Description: The Sender's Signature BEGIN:VCARD NOTE: vCard Format: Version 2.0(Spec-4/29/96) REV:1996-08-07T18:34:06Z N:Joseph;Mark EmissaryA.FN:Mark K. Joseph, Ph.D. MAILER:Emissary 2.01 EMAIL;work;pref;internet:izzy@scr.atm.com EMAIL;home;internet:markjoseph@delphi.com TEL;WORK;PREF;MSG:(408) 471 - 3016 TEL;WORK;FAX:(408) 471 - 3010 TEL;HOME;FAX;MSG:(408) 475 - 8805 TZ:-0800 ORG:Attachmate Corporation;Internet Products Group TITLE:Software Architect LOGO;BASE64;gif: R0lGODlhuQAwAPcAAP///+/v7+fn597e3tbW1s7OzsbGxr29va2traWlpZycnJSUlIyMjISEhHt7 e3Nzc2tra2NjY1paWlJSUkpKSkJCQjk5OTExMSkpKSEhIRgYGBAQEAgICOfe1oR7c2NaUjEpIe/n 3s7Gva2lnIyEe0pCOaWcjJyUhL2tjFpSQox7WntrShgQANbGnM69lMa1jO/WlJSEWta9e8ata3tr Qq2UUqWMSpR7OYRrKTkpAKWchIR7Y+/erefWpa2ca6WUY4x7SpyEQsalSr2cQmNSIbWUOYxzKaWE KYRrIZx7Ie+9KUo5CGtSCMaUAKV7AFpCAP/33u/nzt7WvdbOtb21nK2ljJSMc4yEa//vvXtzWnNr UmtjSufWnL2te//nnFJKMe/WhEpCKaWUWufOe861Y8atWoRzOXNjMe/OY9a1SqWMOffOUjEpEMal Oe/GQpR7KVpKGL2cMd61Oee9MffGMdatKa2MIc6lIe+9Ib2UGMacGO+9GMacENalEJRzCLWMCK2E CN6tCNalAIxrAGtSAEo5AMa9nLWla9a9Y72lUvfWY3trMbWcQnNjKefGUu/OUt69SufGSpyEMda1 Qt69QqWMMc6tOffOQta1OZyEKcalMe/GOc6tMb2cKd61KVpKEL2cIe/GKYxzGNatIbWUGN61GFJC CK2MENatEO+9EL2UCM6lCO+9COe1CO+9AOe1AN6tAL2UALWMAJx7AJRzAHNaAN7Wtb21lK2lhP/v rYR7UufWjM69c8a1a/fee2NaMe/Wc5yMSvfec6WUSufOY9a9Uox7McatQu/OSoRzKa2UKe/GIYxz EOe9GN61EIRrCN61CNatAM6lAIRrAHtjACkhAP/3zu/nvdbOpbWthN7OhNbGe7WlWs69Y1JKIXNj GL21hKWca/fnjN7Oc0I5CMbGvf//797ezsbGtbW1pefnzpSUhEpKQtbWvcbGrb29pYSEc2trWpSU e1paSnt7Y1JSQmNjSkJCMVpaQiEhGEJCKTk5IRgYCBAQAAgIAAAAACwAAAAAuQAwAAAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN hxH+6dyZ4WbBnTt93gQK1CDRfz+Jljx604JSmAGO6kSQtChBpiSx1qzw9OUEqf82VA16tatIrTS5 Wn0JVudYt2XXnjU706nckwcIRm1LFcCBA0cN/BV89C8BvQ3U6qygICECu/8qpHuLFEDOfxkaDxz8 N4DABzovFCA4QO2FvgULRMgAdIKBzQcuEB1ccMDXxYc35h0ou21l38ArCATse0JBB20jDDxaQKpn AEQNIDgqFsAGqQRB+24MfOAAvh+B//8WD1b4dPEPBl73XZ08XKLIpVZYT12gYt/ffQtUAPxCx/w7 OcAAUdy5d5RwBgp0W3DQuVeggWAJBKF+zaHHUW9kaYVWg3Jp+NRRFzRAX1AGijUhWArwB5R/AAiA 1X2VSUjUAAKNGGNGWHl4F1oO9NjjbhwGddlOxskIVDog1shUfUHu5N9eQElwQANUUhkXWZDBBUCF OwHZZJEYcamTBvYRxYCRZC1HV0EHQIAdWgpUIKecKnaolFbErRXfTsIZlM6CVsE4EIyc5ZnmRawB 1RcBOdK1YQE2vrkmZVe6hRaeRPVZp34AZBnjhBpd+qGjZkUa4YZGmbWkql0ZQJQFTXL/Kiia5GV0 nnvpbagVjDxhaOmkld64qp1rGRpZW77C5amaCWJkqn66dpUkrUjBmamoRWGbprGe/uMAs2TBOBoA yWYF6lEZ/EXtAwaIqWWslhHVE7WbvjvsoVq52h24yhK1wV+3hkbQnHNiFDCubVG7WGACJTvetffa eyerxYr3HHYA8PorUBkI4O4/CWSskwMVfAeRjf8eIJjKkWr8MMTufUZerhSTWLOWxrocIQB7KmVs wvbxnIEGNzJ0lGYE1fuPixhrXMGAYNlIo8i+sajtxvi2mqnDQMcKl9JoCeeAbUUrpDRCR0XQc5qJ AiWcdvA1Wd2WbQF5dbU3x5gzuVIV/1CvcgAcrGUAzwI+UHqa9SkUAhBU4MC4DSFAsgOoxcQABRM0 8NxFB0x+plCghy766KSXbvrpqKeuukQBSOBjj40V4MDcEfno5egkz7u6QhfQ+E96iv+DAUVRTb2Q t0tBftAGfSpu0QFgzkRVcwJ9Dt1otwMwQPYE5aTXc7cXTSP3r5E2nEEFeEk9Qs0hDQGbBuVGAPg/ Za48QR4TtJsBm/slkPEYkU1BpmMdAQokKgGYXULCMpCcRCAC0wFSTspXgAxUQDa7Kd76AKAA1igA OQ3wDlIu+L8NZKB8RtFdQTawgIyh5joGuMBXBgAaxQFGQoYDQAa+9Q/rCTAD3gNAAP9A4xnk4ch5 1smAfxrwqcYQbYFIi8oCAmCy5RgOORMIwG7Wx5WBNIdy0NncP3ynu39ULjtlq1F1XCWQkP3DOBi4 gHL+AbkBCcSCy2lMVAYygQT8gwPQ6VNPQJaxjfwjN2pSUvX+cQANIDFpN4rKty5Au3/0DzNX0eM/ kAYd/4CGj/9IxwYMt0GDdPEgS1NQjAYkgAZxUFjpgc77RCajskjokiGknUWC6EVLSihxaUwKQb4i Ib/tBylTKyUB4yXEY0roAZp5V8N8eRDkDGw5ywleT77juwlArjJVhE5jZLMApG0SAHa8SgNiiSNd ZmADAyCAA1j0SioOD23shM6ZviOqgefIZm6UJAhyCnAB0ABSQn3a5Li8dwDD/Y6eRukTQbFpmUre 8TfpCNkrf7kcB5Bpk8/hD0Ih2sP7VYQCPYpeAwaggAvcTkRnHIgAIrBO1ISwRRnYnANyuNKffKsB KlUPAFfjJQ18SyGXyeLAXEqaozagldaBaiCZ1z853XFzC+jLDn9y09159Xj9s8gAIPrVshYkJ2GV yHcCQFazupUjBwDgW+dK17qWNSAAOw== URL:http://www.atm.com LABEL;WORK;PARCEL;POSTAL;DOM;QUOTED-PRINTABLE:140 Du Bois Street, Suite C=0A= Santa Cruz, CA 95060 END:VCARD --=_27tW38g.bO1996u.N16d000A.r08Y.09:006153-- From owner-ietf-calendar Tue Aug 27 11:17:18 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA06283 for ietf-calendar-bks; Tue, 27 Aug 1996 11:17:18 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by imc.org (8.7.4/8.7.3) with SMTP id LAA06277 for ; Tue, 27 Aug 1996 11:17:05 -0700 (PDT) Received: from trhm10.or.uninett.no by domen.uninett.no with SMTP (PP) id <05400-0@domen.uninett.no>; Tue, 27 Aug 1996 18:15:16 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id JAA01558; Tue, 27 Aug 1996 09:12:53 +0200 From: Harald.T.Alvestrand@uninett.no To: "Alec Dun (Exchange)" cc: "'Frank Dawson'" , "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt In-reply-to: Your message of "Mon, 26 Aug 1996 18:03:20 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1554.841129973.1@dale.uninett.no> Date: Tue, 27 Aug 1996 09:12:53 +0200 Message-ID: <1556.841129973@dale.uninett.no> Sender: owner-ietf-calendar@imc.org Precedence: bulk Making the datatype parameter optional makes it useless. If it's optional, your "generic tool" must be able to handle data both with and without it, meaning that you have to handle the special case of no datatype, so why would you bother to do anything with the type except to check it? I must have misunderstood..... Harald A From owner-ietf-calendar Tue Aug 27 14:33:28 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id OAA00212 for ietf-calendar-bks; Tue, 27 Aug 1996 14:33:28 -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 OAA00207 for ; Tue, 27 Aug 1996 14:33:26 -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 OAA07623; Tue, 27 Aug 1996 14:39:09 -0700 Message-ID: <32234C93.2B4@clearblue.com> Date: Tue, 27 Aug 1996 12:29:23 -0700 From: "Peter O'Leary" Reply-To: poleary@clearblue.com Organization: Clear Blue Network Systems, Inc. X-Mailer: Mozilla 3.0b6 (Win95; I) MIME-Version: 1.0 To: "Alec Dun (Exchange)" CC: "'Frank Dawson'" , "'ietf-asid'" , "'ietf-calendar'" Subject: Cool Features - Was: (Re: Examples Are Somewhat Confusing) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk > If the objects were contacts, and I was writing a piece of contact > management software, I'd provide my users with a way to sort the > contacts by last name or first name or switch between them. I'd also > want them to be able to search based on the company I worked at. For > example, I want to see everyone where "CN" = "Frank" and "Company" = > "IBM". Frank, Alec, et. al. I understand the utility of applying type parameters to properties in general. But, are we talking about doing this soley for the purpose of being able to do the sorting and searching that Alec is referring to? If so, I would like to point out that this is just one feature (granted, a very cool one) among *many* that might be useful for Calendaring and Scheduling. However, IMNSHO, it is not in the top 10 important features that we *need* to have. If I remember correctly, you were charged by the group with resolving your differences so that we might arrive at a useful format for sharing Calendaring and Scheduling information. If this is the only, or perhaps the largest, issue that needs to be resolved between you, then my vote would be to drop this *feature* altogether. We need consensus on this important piece of work *way* more than just about anything else. There will be time enough in the future to add features. Pete. From owner-ietf-calendar Tue Aug 27 15:34:40 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id PAA00464 for ietf-calendar-bks; Tue, 27 Aug 1996 15:34:40 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from starfish.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 PAA00459 for ; Tue, 27 Aug 1996 15:34:38 -0700 (PDT) Received: from eng.mcom.com (h-207-1-142-137.mcom.com [207.1.142.137]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id PAA03802; Tue, 27 Aug 1996 15:40:10 -0700 (PDT) Message-ID: <32237949.4EED@netscape.com> Date: Tue, 27 Aug 1996 15:40:09 -0700 From: Mike Weston Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.0b8Gold (Win95; I) MIME-Version: 1.0 To: "Alec Dun (Exchange)" CC: "'Frank Dawson'" , "'ietf-asid'" , "'ietf-calendar'" Subject: Re: Examples Are Somewhat Confusing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk If the 2.5MB you are parsing is coming from a disk, and is alternately interspersed between the 2.5MB that you are potentially skipping, the reduced parsing time will be dwarfed by the time to read the data from the disk. If the data is coming over a network, the situation is probably similar. It seems like we're talking about single digit percentage performance issues, at a non-trivial cost in terms of code for some simple applications. -- Mike Weston Alec Dun (Exchange) wrote: > > Hi Frank, > > The vCard may be 500 bytes, but I may have 10,000 of them. That's 5Mb > of data I have to look thru (if I'm doing a linear search), and if, on > average, I can stop searching 1/2 way thru a v-card because I found all > the properties that I need to do the comparison, I can avoid parsing > 2.5Mb of data. > > What specifically is the down-side here that worries you? > > Thanks, > Alec. > > >---------- > >From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] > >Sent: Monday, August 26, 1996 2:11 PM > >To: Alec Dun (Exchange) > >Cc: 'ietf-asid'; 'ietf-calendar'; 'Frank Dawson' > >Subject: RE: Examples Are Somewhat Confusing > > > >Alec: > > > >I appreciate your answering my questions. Thanks. > > > >The required sequencing of the content information beyond boundary sentinels > >seem somewhat harsh. You have made a point that a search engine can be > >optimized if it predictable that the vCard or other application/directory > >content has such a sequencing order. > > > >It just seems an unnecessarily restrictive a request. Saying the header must > >appear before the body, and in the body, the body header must appear before > >the > >body content is an appropriate level of required ordering. But beyond that, > >it > >might be a bit restrictive. > > > >The size of these things are not really very large. For a vCard, we see less > >than 500 bytes on average. That is really small. This ordering is not going > >to > >improve efficiency to the point of paying for the restriction on generating > >these content portions. > > > >- - Frank Dawson From owner-ietf-calendar Tue Aug 27 16:13:10 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id QAA00603 for ietf-calendar-bks; Tue, 27 Aug 1996 16:13:10 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id QAA00598 for ; Tue, 27 Aug 1996 16:13:08 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9433.74D28FE0@yuri.microsoft.com>; Tue, 27 Aug 1996 16:19:00 -0700 Message-ID: From: Alec Dun To: "'poleary@clearblue.com'" Cc: "'Frank Dawson'" , "'ietf-asid'" , "'ietf-calendar'" Subject: RE: Cool Features - Was: (Re: Examples Are Somewhat Confusing) Date: Tue, 27 Aug 1996 16:18:56 -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 Peter, This is just one of the issues I originally raised. Concensus involves getting all involved parties to air their issues and then work thru them (which is what we are doing). Also, different issues are important to different people. Thanks, Alec. >---------- >From: Peter O'Leary[SMTP:poleary@clearblue.com] >Sent: Tuesday, August 27, 1996 12:29 PM >To: Alec Dun >Cc: 'Frank Dawson'; 'ietf-asid'; 'ietf-calendar' >Subject: Cool Features - Was: (Re: Examples Are Somewhat Confusing) > >> If the objects were contacts, and I was writing a piece of contact >> management software, I'd provide my users with a way to sort the >> contacts by last name or first name or switch between them. I'd also >> want them to be able to search based on the company I worked at. For >> example, I want to see everyone where "CN" = "Frank" and "Company" = >> "IBM". > >Frank, Alec, et. al. > >I understand the utility of applying type parameters to properties in >general. But, are we talking about doing this soley for the purpose of >being able to do the sorting and searching that Alec is referring to? If >so, I would like to point out that this is just one feature (granted, a >very cool one) among *many* that might be useful for Calendaring and >Scheduling. However, IMNSHO, it is not in the top 10 important features >that we *need* to have. > >If I remember correctly, you were charged by the group with resolving >your differences so that we might arrive at a useful format for sharing >Calendaring and Scheduling information. If this is the only, or perhaps >the largest, issue that needs to be resolved between you, then my vote >would be to drop this *feature* altogether. We need consensus on this >important piece of work *way* more than just about anything else. There >will be time enough in the future to add features. > >Pete. > > > From owner-ietf-calendar Tue Aug 27 17:46:11 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id RAA02119 for ietf-calendar-bks; Tue, 27 Aug 1996 17:46:11 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id RAA02114 for ; Tue, 27 Aug 1996 17:46:08 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9440.71859BE0@yuri.microsoft.com>; Tue, 27 Aug 1996 17:51:58 -0700 Message-ID: From: Alec Dun To: "'Mike Weston'" Cc: "'Frank Dawson'" , "'ietf-asid'" , "'ietf-calendar'" Subject: RE: Examples Are Somewhat Confusing Date: Tue, 27 Aug 1996 17:51:54 -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 Mike, You're right on the "read-from-disk case", most disks have at least 512 byte sectors. There are a couple of other scenarios that are significant though: 1. If the data is in-memory on a server, then my performance is directly related to the amount of parsing I'm doing, so I cut my parse time in 1/2. 2. Some networks (particularly slow ones) have small packets, so if I am reading from a stream and I stop reading the stream and the packet size is 100 bytes, then I may only use 3 packets. My overall network traffic will be smaller in this case. I guess one of the things I'm trying to understand is why folks are opposed to a fixed order which should not hurt anything, and has the potential to improve performance. I mean nobody is going to hand-code an application/directory body parts, right? ...or do people do that? I'm trying to figure out the downside, help me out here... Give me an example of where I'd want to have a random order and it makes life easier for me. Thanks, Alec. >---------- >From: Mike Weston[SMTP:mweston@netscape.com] >Sent: Tuesday, August 27, 1996 3:40 PM >To: Alec Dun >Cc: 'Frank Dawson'; 'ietf-asid'; 'ietf-calendar' >Subject: Re: Examples Are Somewhat Confusing > >If the 2.5MB you are parsing is coming from a disk, and is alternately >interspersed between the 2.5MB that you are potentially skipping, the >reduced parsing time will be dwarfed by the time to read the data from >the disk. If the data is coming over a network, the situation is >probably similar. It seems like we're talking about single digit >percentage performance issues, at a non-trivial cost in terms of code >for some simple applications. > >-- Mike Weston > >Alec Dun (Exchange) wrote: >> >> Hi Frank, >> >> The vCard may be 500 bytes, but I may have 10,000 of them. That's 5Mb >> of data I have to look thru (if I'm doing a linear search), and if, on >> average, I can stop searching 1/2 way thru a v-card because I found all >> the properties that I need to do the comparison, I can avoid parsing >> 2.5Mb of data. >> >> What specifically is the down-side here that worries you? >> >> Thanks, >> Alec. >> >> >---------- >> >From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] >> >Sent: Monday, August 26, 1996 2:11 PM >> >To: Alec Dun (Exchange) >> >Cc: 'ietf-asid'; 'ietf-calendar'; 'Frank Dawson' >> >Subject: RE: Examples Are Somewhat Confusing >> > >> >Alec: >> > >> >I appreciate your answering my questions. Thanks. >> > >> >The required sequencing of the content information beyond boundary >>sentinels >> >seem somewhat harsh. You have made a point that a search engine can be >> >optimized if it predictable that the vCard or other application/directory >> >content has such a sequencing order. >> > >> >It just seems an unnecessarily restrictive a request. Saying the header >>must >> >appear before the body, and in the body, the body header must appear >>before >> >the >> >body content is an appropriate level of required ordering. But beyond >>that, >> >it >> >might be a bit restrictive. >> > >> >The size of these things are not really very large. For a vCard, we see >>less >> >than 500 bytes on average. That is really small. This ordering is not >>going >> >to >> >improve efficiency to the point of paying for the restriction on >>generating >> >these content portions. >> > >> >- - Frank Dawson > From owner-ietf-calendar Tue Aug 27 19:23:22 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id TAA02509 for ietf-calendar-bks; Tue, 27 Aug 1996 19:23:22 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from yuri.microsoft.com (exchange.microsoft.com [131.107.243.48]) by imc.org (8.7.4/8.7.3) with SMTP id TAA02503 for ; Tue, 27 Aug 1996 19:23:20 -0700 (PDT) Received: by yuri.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB944E.0620E680@yuri.microsoft.com>; Tue, 27 Aug 1996 19:29:11 -0700 Message-ID: From: Alec Dun To: "'Harald.T.Alvestrand@uninett.no'" Cc: "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Date: Tue, 27 Aug 1996 19:29:07 -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 Your point is good. It's more powerful if we make the datatype parameter mandatory. The pushback against doing this is v-card, which doesn't type its data. Perhaps it should be mandatory/optional on a per/profile basis. That would close some of the gaps on other profiles, and keep the v-card profile reasonably similar to v-card. If the type is missing we would do a (profile, property) -> type lookup. If the type is present we don't do the lookup. The lookup tables may be out-of-date in which case if the entry is missing, it would be treated as text. Even when datatype is optional, we save in two ways: (i) if the table is out-of-date but the type is present we can still figure things out, (ii) if the type is present, we don't need do the lookup. Thanks, - Alec. >---------- >From: Harald.T.Alvestrand@uninett.no[SMTP:Harald.T.Alvestrand@uninett.no] >Sent: Tuesday, August 27, 1996 12:12 AM >To: Alec Dun (Exchange) >Cc: 'Frank Dawson'; 'Tim Howes'; 'ietf-asid@umich.edu'; >'ietf-calendar@imc.org' >Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt > >Making the datatype parameter optional makes it useless. >If it's optional, your "generic tool" must be able to handle >data both with and without it, meaning that you have to handle >the special case of no datatype, so why would you bother to do >anything with the type except to check it? > >I must have misunderstood..... > > Harald A > From owner-ietf-calendar Tue Aug 27 19:53:06 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id TAA02731 for ietf-calendar-bks; Tue, 27 Aug 1996 19:53:06 -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 TAA02725 for ; Tue, 27 Aug 1996 19:52: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 TAA12371 for ; Tue, 27 Aug 1996 19:59:06 -0700 Message-ID: <3223B4D4.D2@clearblue.com> Date: Tue, 27 Aug 1996 19:54:12 -0700 From: "Peter O'Leary" Reply-To: poleary@clearblue.com Organization: Clear Blue Network Systems, Inc. X-Mailer: Mozilla 3.0b6 (Win95; I) MIME-Version: 1.0 To: IETF-Calendar Subject: C&S Overview Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Folks, I have written an overview of C&S functionality as a kind of "road map" for the work that I think (IMNSHO) needs to be done in order to define C&S standards. Basically I just dumped as much as I could think of on paper and drew a few pictures to help illustrate. Some areas of the document are more informed than others; please give me your feedback about additional requirements, clarifications, etc. Also, please let me know if you find this useful and would like for me to continue working on it. http://www.clearblue.com/CSOverview.htm Cheers, Pete. From owner-ietf-calendar Wed Aug 28 04:35:25 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id EAA06319 for ietf-calendar-bks; Wed, 28 Aug 1996 04:35:25 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from pilot.firewall.is.chrysler.com (firewall-user@pilot.is.chrysler.com [204.189.94.35]) by imc.org (8.7.4/8.7.3) with SMTP id EAA06314 for ; Wed, 28 Aug 1996 04:35:19 -0700 (PDT) Received: by pilot.firewall.is.chrysler.com; id HAA07428; Wed, 28 Aug 1996 07:41:18 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma007422; Wed, 28 Aug 96 07:41:13 -0400 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA13496; Wed, 28 Aug 1996 07:33:20 -0400 (EDT) Message-Id: <3.0b11.32.19960828072742.00c12688@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b11 (32) Date: Wed, 28 Aug 1996 07:40:01 -0400 To: Frank Dawson , "Alec Dun (Exchange)" From: Robert Moskowitz Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Cc: "'Harald.T.Alvestrand@uninett.no'" , "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@imc.org Precedence: bulk At 01:05 PM 8/26/96, Frank Dawson wrote: > >The other concern is that MIME content types are now being used outside of a >MIME email transport environment. This is great! However, it also places >additional design considerations on our work. All problems are not just solved >by a "hammer" or in this case an email solution domain. Excuse me for only joining this list now. I have seen content types in HTTP as well, particularly if you use the file-upload feature. So what's the deal? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ietf-calendar Wed Aug 28 08:47:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA07128 for ietf-calendar-bks; Wed, 28 Aug 1996 08:47:09 -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 IAA07123 for ; Wed, 28 Aug 1996 08:47:06 -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 IAA22466; Wed, 28 Aug 1996 08:53:02 -0700 Message-ID: <32246A78.2A84@clearblue.com> Date: Wed, 28 Aug 1996 08:49:12 -0700 From: "Peter O'Leary" Reply-To: poleary@clearblue.com Organization: Clear Blue Network Systems, Inc. X-Mailer: Mozilla 3.0b6 (Win95; I) MIME-Version: 1.0 To: Alec Dun CC: "'Frank Dawson'" , "'ietf-calendar'" Subject: Re: Cool Features - Was: (Re: Examples Are Somewhat Confusing) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Alec Dun wrote: > > Peter, > > This is just one of the issues I originally raised. Concensus involves > getting all involved parties to air their issues and then work thru them > (which is what we are doing). Also, different issues are important to > different people. > > Thanks, > Alec. > Folks, I'm all for raising the issues and reaching consenus by working through them. My point is simply that if the issue being discussed is outside of the scope of Calendaring and Scheduling, in the opinion of the group, then it is appropriate to table it until other more pressing issues are resolved. I personally believe that the issue of whether or not properties should be typed, while it may be an important question, does not need to be resolved for the purpose of Calendaring and Scheduling operations. An example of an issue that I believe *does* need to be resolved, The Application/Properties Appointment profile defines "Start" and "End" using RFC822's date format, vCalendar defines "DTSTART" and "DTEND" using ISO8601. How close are we to resolving that issue? Pete. From owner-ietf-calendar Wed Aug 28 10:23:37 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA07531 for ietf-calendar-bks; Wed, 28 Aug 1996 10:23:37 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from hedgehog.mcom.com (h-207-1-136-17.netscape.com [207.1.136.17]) by imc.org (8.7.4/8.7.3) with ESMTP id KAA07526 for ; Wed, 28 Aug 1996 10:23:32 -0700 (PDT) Received: from vertigo ([207.1.136.91]) by hedgehog.mcom.com (Netscape Mail Server v1.1) with SMTP id AAA28853 for ; Wed, 28 Aug 1996 10:29:07 -0700 Message-ID: <32248128.59E2@netscape.com> Date: Wed, 28 Aug 1996 10:26:00 -0700 From: Tim Howes Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.0b7Gold (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Cool Features - Was: (Re: Examples Are Somewhat Confusing) References: <32246A78.2A84@clearblue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Peter O'Leary wrote: > > I'm all for raising the issues and reaching consenus by working through > them. My point is simply that if the issue being discussed is outside of > the scope of Calendaring and Scheduling, in the opinion of the group, > then it is appropriate to table it until other more pressing issues are > resolved. > > I personally believe that the issue of whether or not properties should > be typed, while it may be an important question, does not need to be > resolved for the purpose of Calendaring and Scheduling operations. We've been discussing several issues. Here's the first one: 1) Ordering of attributes within a body part (i.e., should we require all the CNs come together). Here's what application/directory says on this topic (from Section 5, "The application/directory Content-Type", under "Published specification". Note sentence number two: Note that the meanings of the various type names and the format of the corresponding values must be defined as specified in Section 9. Specifications may impose ordering on the type constructs within a body part, though none is required by default. The various x-name constructs are used for bilaterally-agreed upon type names, parameter names and parameter values. So, whether ordering is imposed or not is indeed an issue for C&S to decide. If you need it, impose it in your profile definition. If you don't then don't. The app/dir spec was designed this way on purpose, to be flexible enough to support a wide variety of applications. Issue number two: 2) The datatype parameter (should it exist at all, be optional or required, etc.). Two options here. One, we could add datatype to the base app/dir spec as an optional parameter. If the C&S profile thought it was necessary to require it, you could do that in your profile definition. I'd be happy to do this, not happy to require it all the time in the base app/dir spec, since I think not every application needs it. Second option is to leave the base app/dir spec alone, and just define the datatype parameter in the C&S profile document (procedures for doing this are given in app/dir). Since it seems like a potentially generally useful thing to me, I'd like to see us take the first route. If we do that, then the only C&S issue is whether to require use of this parameter. Issue number three: 3) Saving space for repeated values of the same type. Two options here, too. One, change it in the base spec as Alec suggested (missing type before the ':' defaults to the previous type). Two, define a new type (e.g., names instead of name) that has in its syntax the ability to specify multiple values (e.g., names: (name1, name2, ...) or something - you get the idea). On this one, the debate seems to be whether the space savings are really worth the extra parsing complexity or not. The issue for C&S is whether you need to save the space. If so, let's figure out the best way of doing this. If not, let's stop talking about it, at least until we find a real application that needs this. Issue number four: 4) Grouping of disjoint profiles within the same body part. I believe you can do this in your C&S profile definition, and that the base app/dir spec allows it already. If that's not the case, and somebody can suggest the wording change to app/dir to explicitly allow it, I'm happy to add it. So, this was all just a long way around to summarize the issues and to say that some of them definitely do apply to C&S. If C&S come up with some requirement you don't think the current app/dir draft can handle (e.g., you need the space saving, you don't think app/dir allows grouping of profiles, etc.), then let ASID know and we'll work to change app/dir. -- Tim From owner-ietf-calendar Wed Aug 28 12:09:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA07987 for ietf-calendar-bks; Wed, 28 Aug 1996 12:09:09 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from dolphin.automatrix.com ([198.69.29.254]) by imc.org (8.7.4/8.7.3) with SMTP id MAA07982 for ; Wed, 28 Aug 1996 12:08:42 -0700 (PDT) Received: (from skip@localhost) by dolphin.automatrix.com (8.6.12/8.6.12) id PAA25622; Wed, 28 Aug 1996 15:14:37 -0400 Date: Wed, 28 Aug 1996 15:14:37 -0400 From: Skip Montanaro Message-Id: <199608281914.PAA25622@dolphin.automatrix.com> To: Tim Howes Cc: ietf-calendar@imc.org Subject: Re: Cool Features - Was: (Re: Examples Are Somewhat Confusing) In-Reply-To: <32248128.59E2@netscape.com> References: <32246A78.2A84@clearblue.com> <32248128.59E2@netscape.com> Reply-To: skip@calendar.com (Skip Montanaro) Sender: owner-ietf-calendar@imc.org Precedence: bulk Okey dokey. I'm feeling especially opinionated today. (Perhaps it's lack of sleep and too much Pepsi...) Tim stated the issues so eloquently. How can I not cast a vote? :-) (Actually, I will avoid voting on item #4...) Tim Howes writes: 1) Ordering of attributes within a body part (i.e., should we require all the CNs come together). Are there any situations where the adjacency of two attributes would imply something? If so, then I believe there's an overall design problem with the spec (the two adjacent attributes would be one logical attribute and should be specified as such). If not, then I favor not having any ordering constraints on the attributes for one simple reason. Applications that parse these beasts should be tolerant of incorrectly ordered attribute lists. There will be some that don't conform to the spec, no matter how tightly you specify it. If parsers should be lenient, then they will have no choice but to assume nothing about the ordering of the attributes, so why require it? 2) The datatype parameter (should it exist at all, be optional or required, etc.). If we're talking vCard-like things, I can understand where having explicit data types is useful (WAV, vs AU sound bites, GIF vs PNG or JPEG logos, etc). I find it hard to imagine where the type of a vCalendar-ish sort of attribute wouldn't be obvious from the name of the attribute itself. I implemented vCalendar generation in our event calendars quite easily. There was no wailing and gnashing of teeth. ("Oh no! They required the GEO attribute to use decimal numbers! Don't those bozos know degrees/minutes/ seconds is the best way to do lat/long coordinates?" :-) If you allow multiple data types for various attributes you'll have to specify what every possible data type is, all parsers will have to handle each and every data type, and (in the words of a famous unnamed columnist, "I kid you not"), for each attribute one particular data type will be adopted by almost everyone, so you'll wind up with a bloated parser containing a bunch of dead code. Ergo, I say decide what the "best" data type is for each attribute, go with implicit typing and avoid all the hoo haw about optional vs required data types altogether. 3) Saving space for repeated values of the same type. Hogwash. #3 implies #1. I can't for the life of me understand how saving a couple bytes for repeated attributes is going to benefit anyone. Returning to vCard as an example, I occasionally get email from someone who shall remain unnamed. His messages are always a few hundred lines long, so I think, "Hmm, this must be pretty important. I'd better read it." Lo and behold, his messages are in reality only a couple lines long, but he always states, "Here's my vCard information in case you need to contact me." Naturally, he's taken full advantage of the capabilities available. There's a corporate logo and an introductory sound bite. His vCard is tens of thousands of bytes long. How is omitting an occasionally repeated attribute going to save anything? Now return to a hypothetical C&S example. Your boss calls a meeting and zips off the "invitee" list. His C&S tool being so easy to use, and bosses being who they are, he invites everyone under him, and the entire management chain above him all the way to the CEO. (Sorry about the gender reference ladies. I'm picturing a certain "pointy-haired" boss from the comic strips...) Okay, so you've got 80 gazillion people invited to the meeting. You could avoid the repeated attribute name for the invitees, but why bother? Most of the invitees' names will be substantially longer than the attribute name anyway. So where's the savings in repeating attribute names? What attributes besides attendees/invitees are likely to be repeated? Skip Montanaro | Musi-Cal: http://concerts.calendar.com/ skip@calendar.com | Conference Calendar: http://conferences.calendar.com/ (518)372-5583 | Python: http://www.python.org/ From owner-ietf-calendar Wed Aug 28 13:25:14 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA08235 for ietf-calendar-bks; Wed, 28 Aug 1996 13:25:14 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from europe.std.com ([199.172.62.20]) by imc.org (8.7.4/8.7.3) with ESMTP id NAA08230 for ; Wed, 28 Aug 1996 13:25:07 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id QAA13188; Wed, 28 Aug 1996 16:30:59 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA18174; Wed, 28 Aug 1996 16:30:58 -0400 Date: Wed, 28 Aug 1996 16:30:58 -0400 From: hanna@world.std.com (Stephen R Hanna) Message-Id: <199608282030.AA18174@world.std.com> To: izzy@nugget.scr.atm.com Cc: ietf-calendar@imc.org In-Reply-To: Dr. Mark K. Joseph's message of Tue, 27 Aug 1996 09:03:06 -0700 <19960827160306.izzy@scr.atm.com> Subject: Architectural issues Sender: owner-ietf-calendar@imc.org Precedence: bulk Dr. Mark K. Joseph wrote: >I would like to add in addition to client-server the additional >usage scenario of: >Client-Client: via Email or other standard protocol one client >can query and send information to another client to set up appointments. >For example, my client could send out a verb asking several people >for all their free time next week so my scheduling program on >my client can set up a common appointment time. >A special scheduling server should not be required. This scenario is a special case of the interoperability scenario, I believe. The agents in that scenario could be clients, servers, or whatever. From owner-ietf-calendar Wed Aug 28 13:27:40 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA08260 for ietf-calendar-bks; Wed, 28 Aug 1996 13:27:40 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from europe.std.com ([199.172.62.20]) by imc.org (8.7.4/8.7.3) with ESMTP id NAA08255 for ; Wed, 28 Aug 1996 13:27:33 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id QAA13683; Wed, 28 Aug 1996 16:33:39 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA19760; Wed, 28 Aug 1996 16:33:38 -0400 Date: Wed, 28 Aug 1996 16:33:38 -0400 From: hanna@world.std.com (Stephen R Hanna) Message-Id: <199608282033.AA19760@world.std.com> To: izzy@nugget.scr.atm.com Cc: ietf-calendar@imc.org In-Reply-To: Dr. Mark K. Joseph's message of Tue, 27 Aug 1996 09:09:37 -0700 <19960827160937.izzy@scr.atm.com> Subject: Architectural issues Sender: owner-ietf-calendar@imc.org Precedence: bulk Dr. Mark K. Joseph wrote: >>*Verbs* >> >For client-client cases how about adding: >appt-query-freetime: one client requests the other client to provide >chunks of free time in a specific time interval, say one week, one >month, etc. I can't believe I left out busy time queries! I guess I was rushing. Busy time queries can be useful in all three scenarios. Several other types of queries are also useful: appt-query-calendar to see what appointments are on a user's calendar and appt-query-off-calendar to see which ones have been received but not yet accepted. >And in general: >appt-update: provides the attendee with additional or revised information >that does not affect the time and location of the meeting but >the content of the meeting like an updated agenda. I would expect appt-announce to be used to communicate any changes to a meeting, not just time and location. Why do we need a new verb? From owner-ietf-calendar Wed Aug 28 13:59:29 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA08364 for ietf-calendar-bks; Wed, 28 Aug 1996 13:59:29 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from europe.std.com ([199.172.62.20]) by imc.org (8.7.4/8.7.3) with ESMTP id NAA08359 for ; Wed, 28 Aug 1996 13:59:25 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id RAA18937; Wed, 28 Aug 1996 17:05:23 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA09559; Wed, 28 Aug 1996 17:05:23 -0400 Date: Wed, 28 Aug 1996 17:05:23 -0400 From: hanna@world.std.com (Stephen R Hanna) Message-Id: <199608282105.AA09559@world.std.com> To: ietf-calendar@imc.org Subject: Object Format issues Sender: owner-ietf-calendar@imc.org Precedence: bulk A few comments on the object format: Let's not lose the BEGIN: type, END: type pair present in vCard and vCalendar. It allows you to embed one object inside another. This could be very useful for including vCard info in a vCalendar object. Also, when we get farther into the verbs, we may want to place vCalendar objects in verb objects or query results objects. While I'm here, I'll weigh in on the weighty issues of the day: Ordering requirements make the spec more complicated and make writing properties more complicated and difficult. I don't see much value to imposing such requirements (except for begin/end). Omitting property names and types doesn't save much space. It just complicates the process of reading them. Let's keep things simple and focus on the essential problems. There are plenty of them. Steve Hanna ON Technology Corporation hanna@world.std.com (617) 692-3153 From owner-ietf-calendar Wed Aug 28 14:00:04 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id OAA08388 for ietf-calendar-bks; Wed, 28 Aug 1996 14:00:04 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from starfish.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 OAA08383 for ; Wed, 28 Aug 1996 14:00:02 -0700 (PDT) Received: from eng.mcom.com (h-207-1-142-199.mcom.com [207.1.142.199]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id OAA20673; Wed, 28 Aug 1996 14:05:38 -0700 (PDT) Message-ID: <3224B4A2.4DD5@netscape.com> Date: Wed, 28 Aug 1996 14:05:38 -0700 From: Mike Weston Organization: Netscape Communications Corp. X-Mailer: Mozilla 3.0b8Gold (Win95; I) MIME-Version: 1.0 To: Alec Dun CC: "'Frank Dawson'" , "'ietf-asid'" , "'ietf-calendar'" Subject: Re: Examples Are Somewhat Confusing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk In your scenario #1, if the data is in non-paged-out memory on the server *and* the parsing is being done on the server, then you are right. Of course if the server owns this data, it could choose to re-order the data as it reads it into memory to make future searches faster. For scenario #2, how common are networks with small packets? Will this become more or less common as we move forward? The reason I see to keep the ordering more open is that doing otherwise pretty much forces the writing code to buffer everything before writing it out. This seems restrictive with minor or at least hard to quantify benefits to justify it. It also hampers hand-coded data, which a text-based format otherwise allows (e.g., hand-coded HTML is quite common). -- Mike Weston Alec Dun wrote: > > Mike, > > You're right on the "read-from-disk case", most disks have at least 512 > byte sectors. There are a couple of other scenarios that are > significant though: > > 1. If the data is in-memory on a server, then my performance is > directly related to the amount of parsing I'm doing, so I cut my parse > time in 1/2. > > 2. Some networks (particularly slow ones) have small packets, so if I > am reading from a stream and I stop reading the stream and the packet > size is 100 bytes, then I may only use 3 packets. My overall network > traffic will be smaller in this case. > > I guess one of the things I'm trying to understand is why folks are > opposed to a fixed order which should not hurt anything, and has the > potential to improve performance. I mean nobody is going to hand-code > an application/directory body parts, right? ...or do people do that? > > I'm trying to figure out the downside, help me out here... Give me an > example of where I'd want to have a random order and it makes life > easier for me. > > Thanks, > Alec. > > >---------- > >From: Mike Weston[SMTP:mweston@netscape.com] > >Sent: Tuesday, August 27, 1996 3:40 PM > >To: Alec Dun > >Cc: 'Frank Dawson'; 'ietf-asid'; 'ietf-calendar' > >Subject: Re: Examples Are Somewhat Confusing > > > >If the 2.5MB you are parsing is coming from a disk, and is alternately > >interspersed between the 2.5MB that you are potentially skipping, the > >reduced parsing time will be dwarfed by the time to read the data from > >the disk. If the data is coming over a network, the situation is > >probably similar. It seems like we're talking about single digit > >percentage performance issues, at a non-trivial cost in terms of code > >for some simple applications. > > > >-- Mike Weston > > > >Alec Dun (Exchange) wrote: > >> > >> Hi Frank, > >> > >> The vCard may be 500 bytes, but I may have 10,000 of them. That's 5Mb > >> of data I have to look thru (if I'm doing a linear search), and if, on > >> average, I can stop searching 1/2 way thru a v-card because I found all > >> the properties that I need to do the comparison, I can avoid parsing > >> 2.5Mb of data. > >> > >> What specifically is the down-side here that worries you? > >> > >> Thanks, > >> Alec. > >> > >> >---------- > >> >From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] > >> >Sent: Monday, August 26, 1996 2:11 PM > >> >To: Alec Dun (Exchange) > >> >Cc: 'ietf-asid'; 'ietf-calendar'; 'Frank Dawson' > >> >Subject: RE: Examples Are Somewhat Confusing > >> > > >> >Alec: > >> > > >> >I appreciate your answering my questions. Thanks. > >> > > >> >The required sequencing of the content information beyond boundary > >>sentinels > >> >seem somewhat harsh. You have made a point that a search engine can be > >> >optimized if it predictable that the vCard or other application/directory > >> >content has such a sequencing order. > >> > > >> >It just seems an unnecessarily restrictive a request. Saying the header > >>must > >> >appear before the body, and in the body, the body header must appear > >>before > >> >the > >> >body content is an appropriate level of required ordering. But beyond > >>that, > >> >it > >> >might be a bit restrictive. > >> > > >> >The size of these things are not really very large. For a vCard, we see > >>less > >> >than 500 bytes on average. That is really small. This ordering is not > >>going > >> >to > >> >improve efficiency to the point of paying for the restriction on > >>generating > >> >these content portions. > >> > > >> >- - Frank Dawson From owner-ietf-calendar Thu Aug 29 08:29:19 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA14512 for ietf-calendar-bks; Thu, 29 Aug 1996 08:29:19 -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 IAA14507 for ; Thu, 29 Aug 1996 08:29:02 -0700 (PDT) Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA31094; Thu, 29 Aug 1996 11:33:06 -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 LAA116580 for ; Thu, 29 Aug 1996 11:33:05 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA0903; Thu, 29 Aug 96 11:32:35 -0400 Message-Id: <9608291532.AA0903@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id 465EE87AE5E82DC585256395005167BB; Thu, 29 Aug 96 11:32:24 To: "Alec Dun (Exchange)" Cc: "'Harald.T.Alvestrand@uninett.no'" , "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" From: Frank Dawson Date: 29 Aug 96 10:51:28 Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Folks: I think we should be separating our discussions between the ASID and CALENDAR mailing lists. This is all interesting but gets schizo and redundant if we are copying the world on our CCs. - - Frank Dawson From owner-ietf-calendar Thu Aug 29 08:31:45 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA14522 for ietf-calendar-bks; Thu, 29 Aug 1996 08:31: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 IAA14517 for ; Thu, 29 Aug 1996 08:31:40 -0700 (PDT) Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA59926; Thu, 29 Aug 1996 11:34:19 -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 LAA21588 for ; Thu, 29 Aug 1996 11:34:20 -0400 Received: by rtpnsi01.raleigh.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/4.03) id AA0923; Thu, 29 Aug 96 11:33:48 -0400 Message-Id: <9608291533.AA0923@rtpnsi01.raleigh.ibm.com> Received: from RTPNOTES with "Lotus Notes Mail Gateway for SMTP" id BEE1500E5A3187D38525639500510B48; Thu, 29 Aug 96 11:33:36 To: "Alec Dun (Exchange)" Cc: "'Harald.T.Alvestrand@uninett.no'" , "'Tim Howes'" , "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org'" From: Frank Dawson Date: 29 Aug 96 10:48:55 Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-calendar@imc.org Precedence: bulk Alec: You wrote: >>>I would define "Location" (in the appointment profile) to always be of type text. If the application on the other end understands the appointment profile it can assume "Location" is of type text without even looking at the datatype parameter. Actually, the LOCATION property in vCalendar ought to be polymorphic. It ought to have a default of the string type you give, but ought also to be able to have a value that is an URL that points to the vCard definition for the location. This is a clear requirement that we are hearing from 360 degrees...okay, maybe 350 degrees. This polymorphism is one of the killer requirements making the DATATYPE argument of yours very difficult to accept. - - Frank From owner-ietf-calendar Thu Aug 29 12:00:23 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA17304 for ietf-calendar-bks; Thu, 29 Aug 1996 12:00:23 -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 ESMTP id MAA17299 for ; Thu, 29 Aug 1996 12:00:19 -0700 (PDT) Message-Id: <199608291900.MAA17299@imc.org> Received: by FEYURI with IMAIL 2.0 id <01BB95A2.5FE58AE0@FEYURI>; Thu, 29 Aug 1996 12:05:30 -0700 From: Alec Dun To: "'Frank Dawson'" , "'Harald.T.Alvestrand@uninett.no'" Cc: "'Tim Howes'" , "'ietf-calendar@imc.org'" Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Date: Thu, 29 Aug 1996 10:46:56 -0700 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-calendar@imc.org Precedence: bulk I agree, and I think this is also what I think Pete was trying to say. In CALENDAR, we should be discussing the higher level issues before we get into the details. We should drop ietf-calendar from this discussion. Anyone that has further interest in the ASID working group's mime-dir draft, please subscribe to the ASID working group. Thanks, Alec. ---------- From: Frank Dawson[SMTP:fdawson@raleigh.ibm.com] Sent: Thursday, August 29, 1996 3:51 AM To: Alec Dun Cc: 'Harald.T.Alvestrand@uninett.no'; 'Tim Howes'; 'ietf-asid@umich.edu'; 'ietf-calendar@imc.org' Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Folks: I think we should be separating our discussions between the ASID and CALENDAR=20 mailing lists. This is all interesting but gets schizo and redundant if we are=20 copying the world on our CCs. - - Frank Dawson From owner-ietf-calendar Thu Aug 29 12:26:57 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id MAA17458 for ietf-calendar-bks; Thu, 29 Aug 1996 12:26:57 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from novell.com (orm-mail20.orem.novell.com [151.155.174.10]) by imc.org (8.7.4/8.7.3) with SMTP id MAA17453 for ; Thu, 29 Aug 1996 12:26:54 -0700 (PDT) Received: from INET-ORM-Message_Server by novell.com with Novell_GroupWise; Thu, 29 Aug 1996 13:33:55 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 29 Aug 1996 13:32:49 -0600 From: Steve Carter To: ietf-calendar@imc.org Subject: C&S Overview -Reply Sender: owner-ietf-calendar@imc.org Precedence: bulk Thanks for the effort Peter. Your document will give us all a launching point for discussion as we move down the path to make Global C&S a reality. The following are my comments: 1. I see three models of C&S connectivity, those that will have server processes that will work against their calendar store directly (although the calendar store will in all probability be synchronized with other copies of the store), those that have a server process that has access to free time only (again, synchronized with other stores), and those that will insist on client-only connectivity. While I understand that some will insist on the client-only model, they will be the least connected as far a C&S is concerned. At Novell, our GroupWise product supports the first model in conjunction with synchronization of multiple calendar stores. I live daily in this world and have done so for many years. E-mail calendaring is a natural part of my life. 2. You hit it right on, resources do indeed need to have an e-mail address. Each resource, be it a conference room, overhead projector, etc., must be individually addressable. While an automated agent can automatically accept and/or reject scheduling requests that conflict with other, already accepted, requests, the additional attribute of "owner" must be included. There are times when a resource becomes a critical resource and some kind of arbitration is necessary. In this case a person (the owner) must step in and resolve the issue. An example, someone has already scheduled the conference room with the large presentation monitors, however, the VP has an important meeting that has just popped up and needs to preempt the original schedule. The owner works everything out, makes the changes to the schedule and life goes on. 3. Your "free time bitmap" is not really a bitmap but rather a datagram. Even though the datagram can be processed I would push for a free time list so that more processing options could be available to the chairperson. GroupWise currently supports free time processing (we call it busy check). I commonly request free times for all participants and resources for 21 days (my default) so that I have the data needed to schedule the meeting sometime within the next three weeks. Because I have a free time list I can change granularity, days, and time zones without posting another query. It is also important to allow the chairperson (your term) to work with partial responses to the free time query. If 9 of the 10 invitees have responded I can start planning the meeting rather than wait for the last response (which may or may not come in a timely manner). 4. Your "direct connect" model is probably more of an issue for a specific implementation that will support both the C&S standard we are all working on and some LAN based access mechanism. I doubt that many calendar stores will be directly accessible on the Internet. 5. Delegation and Inviting are two functions that will need to be carefully integrated into the information sent back to the person scheduling the meeting. If 10 people were invited and the room will hold 12 and 5 additional were "invited", the chairperson needs to know that the resources scheduled are not sufficient to host the meeting. GroupWise allows for both "delegation" and "inviting" and makes provision for notifying the chairperson of the changes. It is also well to note that those "delegated" or "invited" are not really a part of the original scheduled event. So, if the event is rescheduled based upon the original schedule, they must be re-delegated or -invited. I don't know if the work we are doing to define C&S as a specification can do anything to address this but we might want to keep it in mind as it reflects one of the several contexts that meeting schedules are viewed in. 6. Time zones are a very nasty problem when it comes to scheduling a meeting. Some of the participants may be attending at one of several scheduled rooms (resources) that may be connected via teleconference, others may be bridged in from their desk. This may involve some people traveling and thus "changing" their time zone context. When accepting a meeting it would be well to allow the person to define the time zone context. This context may change over time so everything should be relative to the latest declared context. 7. Proxy access to remote calendar stores via the Internet would be a very nice touch. Without positive identity authentication it will never happen. C&S really needs the pkix and other security initiatives to move forward and provide a security infrastructure. Without it we will continue to see proxy access relegated to LAN mechanisms. GroupWise provides for both local and remote proxy access to the message and calendar store, however, it is based on a proprietary security infrastructure. For C&S we need to watch the pkix WG and give them input (as well as the W3C Digital Signature Initiative). 8. I agree with the need to have multiple calendar stores. To make it practical, however, we need to specify the ability to OR several stores together so that an overall schedule can be viewed. This also impacts busy search because we will need to get free time from several stores based on one user id (e.g., srcarter@novell.com). 9. The preceding issue brings up the directory. I see this as one of the biggest problems we will face. The ability to easily register multiple calendar stores for a given user id is critical. Effortless look-up is even more important. Again, thanks for the paper. It provided a place for me to hang the several ideas, thoughts, and concerns I have been having as I've worked through the various C&S proposals. I look forward to participating as we move forward. -src Steve Carter srcarter@novell.com GroupWare Division >>> "Peter O'Leary" 08/27/96 08:54pm >>> Folks, I have written an overview of C&S functionality as a kind of "road map" for the work that I think (IMNSHO) needs to be done in order to define C&S standards. Basically I just dumped as much as I could think of on paper and drew a few pictures to help illustrate. Some areas of the document are more informed than others; please give me your feedback about additional requirements, clarifications, etc. Also, please let me know if you find this useful and would like for me to continue working on it. http://www.clearblue.com/CSOverview.htm Cheers, Pete. From owner-ietf-calendar Thu Aug 29 16:22:11 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id QAA18359 for ietf-calendar-bks; Thu, 29 Aug 1996 16:22:11 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by imc.org (8.7.4/8.7.3) with SMTP id QAA18354 for ; Thu, 29 Aug 1996 16:22:09 -0700 (PDT) Received: by mail2.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB95C6.F0BA8740@mail2.microsoft.com>; Thu, 29 Aug 1996 16:27:15 -0700 Message-ID: From: Lewis Geer To: "'ietf-calendar@imc.org'" Subject: RE: C&S Overview -Reply Date: Thu, 29 Aug 1996 16:27:22 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 48 TEXT Sender: owner-ietf-calendar@imc.org Precedence: bulk The expertise in this group is top notch and I think we are well prepared to come up with good solutions. I was wondering, however, if the chairs could update us on the progress of the charter with the IESG, since this is one of the necessary preconditions for us to move forward. Lewis >-----Original Message----- From: Steve Carter [SMTP:srcarter@novell.com] Sent: Thursday, August 29, 1996 12:33 PM To: ietf-calendar@imc.org Subject: C&S Overview -Reply Thanks for the effort Peter. Your document will give us all a launching point for discussion as we move down the path to make Global C&S a reality. The following are my comments: >[...snip...] > >Again, thanks for the paper. It provided a place for me to hang the several >ideas, thoughts, and concerns I have been having as I've worked through >the various C&S proposals. I look forward to participating as we move >forward. > >-src >Steve Carter >srcarter@novell.com >GroupWare Division > >>>> "Peter O'Leary" 08/27/96 08:54pm >>> >Folks, > >I have written an overview of C&S functionality as a kind of "road map" >for the work that I think (IMNSHO) needs to be done in order to define >C&S standards. Basically I just dumped as much as I could think of on >paper and drew a few pictures to help illustrate. Some areas of the >document are more informed than others; please give me your feedback >about additional requirements, clarifications, etc. Also, please let me >know if you find this useful and would like for me to continue working >on it. > >http://www.clearblue.com/CSOverview.htm > >Cheers, > >Pete. > > From owner-ietf-calendar Fri Aug 30 07:00:19 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id HAA22964 for ietf-calendar-bks; Fri, 30 Aug 1996 07:00:19 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from xr3.atlas.fr (xr3.atlas.fr [194.51.9.5]) by imc.org (8.7.4/8.7.3) with ESMTP id HAA22959 for ; Fri, 30 Aug 1996 07:00:11 -0700 (PDT) X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 30 Aug 1996 16:06:04 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 30 Aug 1996 16:06:04 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 30 Aug 1996 16:05:59 +0200 X400-Received: by /PRMD=sept/ADMD=atlas/C=FR/; Relayed; Fri, 30 Aug 1996 19:06:24 +0200 Date: Fri, 30 Aug 1996 19:06:24 +0200 X400-Originator: Denis.Bigorgne@sept.fr X400-Recipients: ietf-calendar@imc.org X400-MTS-Identifier: [/PRMD=sept/ADMD=atlas/C=FR/;84141758428870001BIGORGNE] X400-Content-Type: P2-1984 (2) Content-Identifier: UCOMX Alternate-Recipient: Allowed From: Denis BIGORGNE Message-ID: <84141758428870001BIGORGNE*/G=Denis/S=Bigorgne/PRMD=sept/ADMD=atlas/C=FR/@MHS> To: ietf C&S WG mailing list (Non Receipt Notification Requested) Subject: Freetime Lookup Sender: owner-ietf-calendar@imc.org Precedence: bulk In the C&S Overview document, the Freetime Lookup function seems adapted to corporate environments, where calendar sharing is a fair rule. Im not sure that extensive request of 21 days freetime map could be accepted for automated appointment scheduling made outside the enterprise ; there could be too many indiscretions opportunities, like trying to know who is busy at the same time... Instead of a one-shot ORing of freetime maps, the appointment scheduling could use a multi-round negotiation algorithm controlling the exchange of a list of time-slots (or ranges) arranged by preference order. At each step, the list should be narrowed, discarding the impossibilities ; if the list is reduced to null, an extension should be proposed... For two-parts meeting, a simple round may be sufficient ; for numerous invitee, many rounds could be required, with a succession of narrowing and extension phases. At SEPT, we developed a PC conference appointment scheduling demo using list of ten time- slots ; I have been told that in some corporation, the directive for non-automated scheduling requires an initial list of only three time-slots. Another item seems problematic to me : the ressource caracterisation. In Petes document, a ressource is simply another agenda which must be inquired. This is certainly true for common ones, like network reservation. But : - some ressources are private : if you are trying to schedule a videoconference, the networks ressources are (more or less) common, but the terminal equipments are private and external requesters are probably not allowed to make reservations - it is a task to be done by each invitee calendar agent (or user himself). - the disponibilities of the ressources are dependant of the time. By instance, an user may be present at some location at some time, and can only be call by phone at another time. A solution could be that the items of the negotiation list (or of the freetime map) should not be simple time-slots but consist in a time-slot plus acceptable media (physical location, phone, videoconferencing protocol,...). Note that the videoconferencing descrition is not trivial - see IETF mmusic WG. I understand my comments goes beyond the capabilities of the majority of the current calendar products ; this is explainable - I dont speak from a technology provider point of view, but from an user one, and more, an user interested in teleconferencing in a general environment (not corporate). If we are to establish an interoperability standard on the Internet, these aspects should not be forgotten. Regards, Denis Denis Bigorgne France Telecom / CNET / SEPT bigorgne@sept.fr phone : +33 31 75 92 29 fax : +33 31 75 06 31 From owner-ietf-calendar Fri Aug 30 08:23:30 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA23415 for ietf-calendar-bks; Fri, 30 Aug 1996 08:23:30 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mail.pilot.net (ns.pilot.net [198.232.147.10]) by imc.org (8.7.4/8.7.3) with ESMTP id IAA23409 for ; Fri, 30 Aug 1996 08:23:23 -0700 (PDT) Received: from relay1.clorox.com (relay.clorox.com [168.189.64.36]) by mail.pilot.net with ESMTP id IAA16897; Fri, 30 Aug 1996 08:29:38 -0700 (PDT) Received: from maverick.clorox.com (BOOTP-60-117.clorox.com) by relay1.clorox.com with SMTP (CEMS 5.01/1.37.109.14) id AA299129230; Fri, 30 Aug 1996 08:33:51 -0700 From: Paul Rarey Message-Id: <960830082845.ZM8630@maverick.clorox.com> Date: Wed, 28 Aug 1996 17:40:47 -0700 In-Reply-To: Robert Moskowitz "RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt" (Aug 28, 7:40) References: <3.0b11.32.19960828072742.00c12688@pop3hub.is.chrysler.com> Reply-To: Paul Rarey X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996) To: rgm3@chrysler.com Subject: Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt Cc: "'ietf-asid@umich.edu'" , "'ietf-calendar@imc.org" Sender: owner-ietf-calendar@imc.org Precedence: bulk '" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Robert..., On Aug 28, 7:40, Robert Moskowitz wrote: > Subject: RE: I-D ACTION:draft-ietf-asid-mime-direct-02.txt >At 01:05 PM 8/26/96, Frank Dawson wrote: >> >>The other concern is that MIME content types are now being used outside of a >>MIME email transport environment. This is great! However, it also places >>additional design considerations on our work. All problems are not just solved >>by a "hammer" or in this case an email solution domain. Nathaniel B... has often remarked that casting MIME with "Mail" in its title (the second "M") would, in many eyes & minds, limit the possibilities of its use. Seems we see one such minds eye.... >Excuse me for only joining this list now. > >I have seen content types in HTTP as well, particularly if you use the >file-upload feature. So what's the deal? The file upload facility is where Content-Type:'s are exposed to the human eye. HTTP uses MIME to describe data types for all transfers. We've all heard of text/html & image/gif Content-Type:'s before...:-) Cheers! [ psr ] From owner-ietf-calendar Tue Sep 3 08:40:17 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA06540 for ietf-calendar-bks; Tue, 3 Sep 1996 08:40:17 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from novell.com (orm-mail20.orem.novell.com [151.155.174.10]) by imc.org (8.7.4/8.7.3) with SMTP id IAA06529 for ; Tue, 3 Sep 1996 08:39:47 -0700 (PDT) Received: from INET-ORM-Message_Server by novell.com with Novell_GroupWise; Tue, 03 Sep 1996 09:46:26 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 03 Sep 1996 09:45:27 -0600 From: Steve Carter To: ietf-calendar@imc.org, Denis.Bigorgne@sept.fr Subject: Freetime Lookup -Reply Sender: owner-ietf-calendar@imc.org Precedence: bulk Thank you for your thoughts on this matter. My comments are below: -src Steve Carter Novell srcarter@novell.com >>> Denis BIGORGNE 08/30/96 11:06am >>> >In the C&S Overview document, the Freetime Lookup function >seems adapted to corporate environments, where calendar >sharing is a fair rule. Im not sure that extensive request of 21 >days freetime map could be accepted for automated >appointment scheduling made outside the enterprise ; there >could be too many indiscretions opportunities, like trying to >know who is busy at the same time... Point well taken, but I think we will find ourselves needed to organize groups of disperse individuals for meetings (phone, teleconference, face-to-face, chat, collaborative document, etc., etc.) much more in the future and the need to schedule time from a free time list is very important. Each of us has time that is private, time that is scheduled, and time that is available. I suggest that we have this kind of designation for our calendars. If several people have time marked "private" at the same time and others can see it, that may or may not be bad. Thus to my next point. We need to have a globally deployed PKI that will allow us to use certificates at various levels to authenticate requests for calendar (read personal and/or professional here) information. Even at this point you still have a valid point about the "private" time or "scheduled" times that you don't want others to interrogate. <> Perhaps we need another calendar distinction called "black out" that returns a random mixture of non-response, scheduled time, and/or private time? <> >Instead of a one-shot ORing of freetime maps, the appointment >scheduling could use a multi-round negotiation algorithm >controlling the exchange of a list of time-slots (or ranges) >arranged by preference order. At each step, the list should be >narrowed, discarding the impossibilities ; if the list is reduced >to null, an extension should be proposed... For two-parts >meeting, a simple round may be sufficient ; for numerous >invitee, many rounds could be required, with a succession of >narrowing and extension phases. At SEPT, we developed a PC >conference appointment scheduling demo using list of ten time- >slots ; I have been told that in some corporation, the directive >for non-automated scheduling requires an initial list of only >three time-slots. In my response to Peter's paper I specified that ORing takes place as each response is received and that work to schedule a meeting can be taking place during the receipt of the free time lists. On the client each free list is processed as it is received. Perhaps you are talking about having a server process do the progressive ORing? I'm not clear what your point is here -- please clarify. >Another item seems problematic to me : the resource >caracterisation. In Petes document, a resource is simply >another agenda which must be inquired. This is certainly true >for common ones, like network reservation. But : >- some resources are private : if you are trying to schedule a >videoconference, the networks resources are (more or less) >common, but the terminal equipments are private and >external requesters are probably not allowed to make >reservations - it is a task to be done by each invitee calendar >agent (or user himself). Thus, again we see the need for certificate processing. We need to be able to authenticate a scheduler. Private resources must authenticate the scheduling person (or agent) before allowing any access to the free list and before accepting any schedule. This is even more important to prevent "denial of service" attacks. I can imagine some unsavory characters shutting down a set of resources by scheduling bogus meetings and consuming the time slots. >- the disponibilities of the resources are dependant of the >time. By instance, an user may be present at some location >at some time, and can only be call by phone at another time. >A solution could be that the items of the negotiation list (or of >the freetime map) should not be simple time-slots but consist in >a time-slot plus acceptable media (physical location, phone, >videoconferencing protocol,...). Note that the >videoconferencing descrition is not trivial - see IETF mmusic >WG. I agree here as well. Time zone handling must be done in the context of the location of the person (resource) at the time of the scheduled event. The fact that the event is accepted in one time zone does not preclude the fact that movement will occur and the event will be participated in from another time zone. I have suggested that the person scheduling be advised of the time zone context that the accepting party has designated for their attendance at the event. I will look into the minutes and other information from the ietf mmusic WG. >I understand my comments goes beyond the capabilities of the >majority of the current calendar products ; this is explainable - I >dont speak from a technology provider point of view, but from >an user one, and more, an user interested in teleconferencing in >a general environment (not corporate). If we are to establish an >interoperability standard on the Internet, these aspects should >not be forgotten. If we design to technology we'll get a technology solution. Design from user work practice will yield a user solution. The latter will be used over the former. We should constantly be putting on our "user" hat and/or talking to users (doing a lot more listening than talking I might add). Thank you for your response. The issues you have raised should be considered as we move forward. -src Steve Carter Novell srcarter@novell.com >Regards, > Denis >Denis Bigorgne >France Telecom / CNET / SEPT >bigorgne@sept.fr >phone : +33 31 75 92 29 fax : +33 31 75 06 31 From owner-ietf-calendar Tue Sep 3 15:06:42 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id PAA08124 for ietf-calendar-bks; Tue, 3 Sep 1996 15:06:42 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from europe.std.com ([199.172.62.20]) by imc.org (8.7.4/8.7.3) with ESMTP id PAA08119 for ; Tue, 3 Sep 1996 15:06:39 -0700 (PDT) Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id SAA21253; Tue, 3 Sep 1996 18:13:06 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA11697; Tue, 3 Sep 1996 18:13:05 -0400 Date: Tue, 3 Sep 1996 18:13:05 -0400 Message-Id: <199609032213.AA11697@world.std.com> From: Stephen R Hanna To: poleary@clearblue.com Cc: ietf-calendar@imc.org Subject: Re: C&S Overview Sender: owner-ietf-calendar@imc.org Precedence: bulk Pete, I like your new document. Very thorough. Here are a few comments: Meeting Maker XP uses meeting invitations instead of direct book, but we use a direct connection, not S&F comm. I would like to see this architectural choice reflected in section 2.2. I don't think we're the only ones using it. In section 2.2.2, I'd like to see you address the question of how email is delivered to the C&S system. I believe that some systems require the user to transfer the email manually from their inbox, whereas others are integrated with the email system and pick up the mail automatically. Is that right? What about outgoing mail? Same idea? In section 2.3, you describe the functionality provided by a Calendar store briefly. You don't get into many details. Does the Calendar store keep a record of each user's entire calendar for all users served by that store? I assume it must in order to support Calendar Browsing and Proxy Access. That makes it rather different in function from an ICAP server, I believe. In section 2.4, you provide a list of features that must be provided by a Directory for a C&S system. First, I would suggest that any C&S standard should not include a full Directory Service, but be designed to take advantage of an external one. Second, I would suggest that many of the items you say "must be available to a C&S system" are not in fact required, but optional for many scenarios. For instance, user profile information should not be required in order to send an appointment to a user. An email address or user id and location of their Calendar server or Calendar store should be sufficient. In section 2.4.1, you say that Freetime Lookup and Calendar Browsing require the network address of the server. Can't those be performed via email? I believe that in many systems they are. In section 3, you provide a list of specifications required to define a standard for C&S on the Internet. I would like to see this fleshed out with a list of scenarios describing how these pieces would fit together. Defining two protocols, S&F and direct connect, will be complicated. I want to see a compelling requirement to do so. If we do so, I would hate to be required to use S&F for some things and direct connect for others. Lets make direct connect able to perform all operations (maybe S&F, too). I don't think that a single directory service for accessing user profile information is necessary, just a standard for how that data should be stored in whatever directory service is in use. Finally, the requirement for mapping an SMTP mail address to a server host name assumes that the mail address will be a C&S user's unique identifier. I like this idea, but it should probably be stated more clearly. It also assumes that direct connect will be used to communicate to the server. Typos: In section 2.1.5, you write "Lotus Notes employs one cache on each server where users Calendar stores...". That should be "users'". In section 2.2.2, you write "Some C&S systems, Lotus Organizer for example, will route Meeting Invitations to a agent...". That should be "an agent". In section 2.3.1, you write "Some C&S allow a user to browse other user's Calendars." That should be "users'". You also write "...in some cultures this is not seen in the that light." The word "the" is unnecessary. In section 2.4.3, you write "Many systems handle resource differently..." That should be "resources". Thanks, Steve Hanna ON Technology Corporation hanna@world.std.com (617) 692-3153 From owner-ietf-calendar Tue Sep 3 22:28:16 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id WAA01462 for ietf-calendar-bks; Tue, 3 Sep 1996 22:28:16 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from earth.ontime.com (earth.ontime.com [206.66.56.2]) by imc.org (8.7.4/8.7.3) with ESMTP id WAA01451 for ; Tue, 3 Sep 1996 22:28:13 -0700 (PDT) Received: from anik (ANIK.ontime.com [206.66.56.55]) by earth.ontime.com (post.office MTA v2.0 0813 ID# 0-13987) with SMTP id AAA215 for ; Wed, 4 Sep 1996 01:37:43 -0400 Message-Id: <2.2.32.19960904053333.007027cc@earth.ontime.com> X-Sender: anik@earth.ontime.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Sep 1996 01:33:33 -0400 To: ietf-calendar@imc.org From: anik@ontime.com (Anik Ganguly) Subject: Proposed charter Sender: owner-ietf-calendar@imc.org Precedence: bulk Folks, the IETF Applications Directorate has reviewed the charter of the Proposed Calendaring and Scheduling working group and asked to see some public discussion on the mailing list to see if any issues need to be addressed before they forward this to the IESG/IAB for approval. The attached version of the charter represents the results of the discussion at the July 24, 1996 meeting in Mountain View as well as some feedback that I have recieved from the applications directorate recently. Once the WG (represented by this charter) is approved, the real work will begin so I hope that we can come to "rough concensus" on this charter quickly and get the WG established. Calendaring and Scheduling (calsch) ----------------------------------- Charter Current Status: Proposed Working Group Chair(s): Anik Ganguly Robert Moskowitz Application Area Director(s): Harald Alvestrand Keith Moore Area Advisor: Harald Alvestrand Mailing List(s): Submissions: ietf-calendar@imc.org Requests: ietf-calendar-request@imc.org (SUBSCRIBE/UNSUBSCRIBE in Message body) Archive: Description of Working Group: Calendaring and group scheduling products are well established for organizational use, but they usually are limited to exchange of information among users of the same system, usually within the boundaries of a single organization. This working group will pursue development of standards to enable different products to interoperate and to work across organizational boundaries. This work will include the development of MIME content types to represent common objects needed for calendaring and group scheduling transactions and access methods between systems and between clients and servers. The working group will also consider and recommend solutions to the security issues concerning the exchange of calendar information between network entities. The group will exist to create standards that make calendaring and scheduling software significantly more useful and to enable a new class of solutions to be built that are only viable if open standards exist. To this end, the Calendaring and Scheduling Working Group will consider all ideas relating calendaring and meeting scheduling but is chartered to initially focus on Internet standards for three basic problems facing group scheduling and calendaring users today. These include the following: 1. A standard content type for capturing calendar event and to-do information. The content type should be suitable as a MIME message entity that can be transferred over MIME based email systems or HTTP World Wide Web, as well as, useful as an object for interacting between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. The basic objects along with their representation using MIME will be specified in the document entitled "Core Object Specification". 2. A standard interoperability method for common calendaring and group scheduling transactions. For example, these may include exchanging over the Internet, event-requests, reply to event-requests, cancellation notices for event-requests, requesting free/busy time and replying to free/busy time requests between different calendaring products. To the extent that the interoperability method have requirements related to security, the working group will attempt to apply existing Internet standards for authentication, and to assure privacy and integrity of sensitive calendaring information. The method for the interoperable transactions will be specified in a document entitled "Object Interaction Specification". 3. A standard access method to allow for the management of calendars, events and to-dos over the Internet. These methods will also be specified in the document entitled "Object Interaction Specification". This working group effort should be developed and stabilized with a 6-9 months since there has been considerable prior work done in this area. This prior body of work includes: * Distributed Scheduling Protocol (CHRONOS) IETF Working Group * ISO/IEC SC18 Distributed Office Application for Calendaring, Scheduling and Appointments * MHS Alliance Calendaring and Scheduling Interoperability Protocol (CSIP) * X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA) and Calendaring and Scheduling Interoperabilty Specification (CSIS) * X/Open Consortium Calendaring and Scheduling (XCS) Implementor's Specification * Versit vCalendar format The working group will focus on harmonizing, evolving and developing protocols and algorithms based on this work. The process is subject to extension if many new features are added, or more revision is needed. Goals and Milestones: Develop Architecture and Terms 1-Oct-1996 Core object specification First draft 1-Oct-1996 Second draft 1-Dec-1996 (San Jose IETF Meeting) Draft suitable for proposed standard 15-Mar-1997 (Spring IETF Meeting) Resolve integration issues with Object interaction specification 1-Jun-1997 Object interaction specification First draft (covering interoperability) 1-Dec-1996 Second draft (covering access also) 15-Mar-1997 (This should be ready to be a proposed standard) Resolve integration issues with Core object specification 1-Jun-1997 Anik Ganguly OnTime/FTP Software Inc. From owner-ietf-calendar Tue Sep 3 22:28:17 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id WAA01463 for ietf-calendar-bks; Tue, 3 Sep 1996 22:28:17 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from earth.ontime.com (earth.ontime.com [206.66.56.2]) by imc.org (8.7.4/8.7.3) with ESMTP id WAA01453 for ; Tue, 3 Sep 1996 22:28:14 -0700 (PDT) Received: from anik (ANIK.ontime.com [206.66.56.55]) by earth.ontime.com (post.office MTA v2.0 0813 ID# 0-13987) with SMTP id AAB215 for ; Wed, 4 Sep 1996 01:37:46 -0400 Message-Id: <2.2.32.19960904053335.006fd360@earth.ontime.com> X-Sender: anik@earth.ontime.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Sep 1996 01:33:35 -0400 To: ietf-calendar@imc.org From: anik@ontime.com (Anik Ganguly) Subject: A minimal set of objects and transactions Sender: owner-ietf-calendar@imc.org Precedence: bulk I'm humbly submitting this to offer a framework for us to focus our discussion. One of the early results that we as a group want to achieve is a mechanism to allow calendaring and group scheduling software from different vendors to interoperate. Ideally, a user of C&S product A should be able to setup, cancel, modify and otherwise manage meetings with a user of C&S product B with the same fidelity and capability, that they would have, if the other user was a user of product A. This ideal is impossible to achieve with all the C&S products today because of two reasons. First, the representation of the meeting itself varies from product to product (e.g. One product may have a separate field for meeting location while other products do not). Second, the actions that users can take relative to a meeting vary from product to product (e.g. One product may allow a meeting participant to delegate the meeting while other products do not). Each of these differences cause a "loss of fidelity" when meetings are managed across products. If you go further and consider the actions that a user can take to manage their own calendar, as opposed to setting up meetings, you have a much richer set of capabilities and more marked differences between different products. In the interest of getting something useful done quickly, let me suggest that we need to agree on a small set of transactions and associated objects that will allow a user of product A to setup and manage meeting which include users of product B (of course, for any product A and B). Let me go further and suggest that we defer the discussion of certain other transactions until we have agreement on the most basic set. Basic transactions: 1. Propose a new meeting The purpose of this transaction is to invite a set of people (and/or resources) to a meeting. The core object that is transmitted in this transaction is the "event object". 2. Cancel an existing meeting The purpose of this transaction is to notify the set of people (and/or resources) who were invited to a meeting that the meeting has been canceled. The core object that is transmitted in this transaction is the "event object" and should probably include a unique identifier for the existing meeting. 3. Modify an existing meeting The purpose of this transaction is to notify the set of people (and/or resources) who were invited to a meeting that certain details of the meeting have changed. This transaction has two instances of the "event object" associated with it. The first instance represents the details of the meeting prior to the change and the second instance represents the modified details. 4. Response to an existing meeting The purpose of this transaction is to allow a person (and/or resource) to notify the person who is trying to setup the meeting whether they intend to attend the meeting or not. The core object associated with this transaction is the "response object". Basic objects: To support the basic transactions, we need the following basic objects: EVENT The event object will need to include at a minimum the following attributes - Identifier that will uniquely identify this meeting on the originating system Event sequence/version number (starts at 1 and incremented for each modification) Description of meeting Date and time meeting begins Date and time meeting ends Identifier of person who is setting up the meeting List of people invited to meeting List of resources associated with meeting Additional, optional attributes Location of meeting Recurrence specification for recurring meeting Security classification of meeting (e.g. private, public, etc.) Invitee modifiers (e.g. mandatory invitee, optional invitee, etc.) Identifier of the person who proposed the meeting, if different from the person setting it up RESPONSE The response object will need to include at a minimum the following attributes - Unique identifier for meeting Response - Yes, No, Maybe, ... Transactions (and associated objects) that we will defer (but not for long) discussion on: Free time request/response Transactions to support "Calendar browsing" My assumption is that the design team on core objects is busy defining the EVENT object. I will only ask that they verify that their proposal includes at least all attributes that are designated as minimum requirements based on the discussion on the mailing list that this message will hopefully prompt. Additionally, we will need the RESPONSE object to be defined and its representation specified by the core objects design team. In terms of the transactions themselves, maybe we can think of transactions containing "envelope attributes" in addition to the "core objects" that they transmit. "Envelope attributes" for the "Propose a new meeting" transaction may include - protocol version message identifier message sequence number message sent date/time stamp originating system identifier and version message_from address message_to address message type In the ensuing discussion I would suggest that we can make the best use of our time if we could agree to work towards consensus on the following issues in the order presented: 1. Agree/reaffirm that system to system interoperability is a worthwhile goal to pursue 2. Agree on the minimum set of (system interoperability) transaction that will provide users with significant benefit 3. Agree on the minimum set of objects and their attributes needed to support the minimum set of transactions. 4. Agree on the "envelope attributes" or whatever we end up calling them 5. Agree on the mapping of transactions to transport mechanisms (SMTP+MIME), TCP/IP with defined packets, HTTP+MIME etc. This will probably interact with #4. I hope that this will spark lively but focused discussion and enable us to gain momentum as a group. Respectfully, Anik Ganguly OnTime/FTP Software Inc. From owner-ietf-calendar Wed Sep 4 08:42:10 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA05778 for ietf-calendar-bks; Wed, 4 Sep 1996 08:42:10 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mh1.well.com (mh1.well.com [206.15.64.22]) by imc.org (8.7.4/8.7.3) with ESMTP id IAA05773 for ; Wed, 4 Sep 1996 08:42:09 -0700 (PDT) Received: from gwresearch (gwresearch.orem.novell.com [151.155.61.177]) by mh1.well.com (8.7.5/8.7.5) with ESMTP id IAA17350; Wed, 4 Sep 1996 08:39:10 -0700 (PDT) Message-Id: <199609041539.IAA17350@mh1.well.com> From: "Don LaVange" To: "Steve Carter" , , Subject: Re: Freetime Lookup -Reply Date: Wed, 4 Sep 1996 09:36:51 -0600 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BB9A44.9A268550" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01BB9A44.9A268550 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit My comments below: > From: Steve Carter >> Denis BIGORGNE 08/30/96 11:06am >>> > >In the C&S Overview document, the Freetime Lookup function > >seems adapted to corporate environments, where calendar > >sharing is a fair rule. Im not sure that extensive request of 21 > >days freetime map could be accepted for automated > >appointment scheduling made outside the enterprise ; there > >could be too many indiscretions opportunities, like trying to > >know who is busy at the same time... > > Point well taken, but I think we will find ourselves needed to organize > groups of disperse individuals for meetings (phone, teleconference, > face-to-face, chat, collaborative document, etc., etc.) much more in the > future and the need to schedule time from a free time list is very > important. Each of us has time that is private, time that is scheduled, and > time that is available. I suggest that we have this kind of designation for > our calendars. If several people have time marked "private" at the same > time and others can see it, that may or may not be bad. I see Denis' point here for "indescretious use". But client implentation of this data manipulation doesn't have to correspond to the actual object that one wishes marked private. I can envision painting sub-regions "private" and marking "all private" to users outside an identified group. In short, I think that allowing multiple day searches for a given time slot is benificial enough to provide protocol support for it, and that client implementation can give reasonable protection to the calendar owner concerned about any kind of data spying. > Thus to my next point. We need to have a globally deployed PKI that will > allow us to use certificates at various levels to authenticate requests for > calendar (read personal and/or professional here) information. Even at > this point you still have a valid point about the "private" time or > "scheduled" times that you don't want others to interrogate. < thought>> Perhaps we need another calendar distinction called "black > out" that returns a random mixture of non-response, scheduled time, > and/or private time? <> Although this is a client issue as well, it seems you would simply want to have blackout not show availability or scheduled time at all, or show selective data to differing levels of users (exception list gets all, named domain gets public, and externals get nothing) All of this presupposes the client has some sort of directory accessible. <> Perhaps a request for schedule times that gets blacked out automatically generates a "knock" request, where the requestee can manually respond with rejection, one time, timed limit, or permanent admission to the exception group as requests to the calendar owner being queried or the request for this particular item. I suppose this is all doeable in the client but that leaves lots of room for simple clients to not protect the calendar owner. <>. > >Instead of a one-shot ORing of freetime maps, the appointment > >scheduling could use a multi-round negotiation algorithm > >controlling the exchange of a list of time-slots (or ranges) > >arranged by preference order. At each step, the list should be > >narrowed, discarding the impossibilities ; if the list is reduced > >to null, an extension should be proposed... For two-parts > >meeting, a simple round may be sufficient ; for numerous > >invitee, many rounds could be required, with a succession of > >narrowing and extension phases. At SEPT, we developed a PC > >conference appointment scheduling demo using list of ten time- > >slots ; I have been told that in some corporation, the directive > >for non-automated scheduling requires an initial list of only > >three time-slots. > > In my response to Peter's paper I specified that ORing takes place as > each response is received and that work to schedule a meeting can be > taking place during the receipt of the free time lists. On the client each > free list is processed as it is received. Perhaps you are talking about > having a server process do the progressive ORing? I'm not clear what > your point is here -- please clarify. Seems that the multiple round negotiation would provide a much longer hand holding period for the successful schedule of a meeting. Perhaps, there are certain attendees that must accept or the meeting is cancelled, or a certain percentage of attendees must respond favorably. Only when the criterion are met after several passes would the meeting actually be scheduled. However, this seems way beyond the scope of a protocol this group might see implemented as a standard. > >I understand my comments goes beyond the capabilities of the > >majority of the current calendar products ; this is explainable - I > >dont speak from a technology provider point of view, but from > >an user one, and more, an user interested in teleconferencing in > >a general environment (not corporate). If we are to establish an > >interoperability standard on the Internet, these aspects should > >not be forgotten. > > If we design to technology we'll get a technology solution. Design from > user work practice will yield a user solution. The latter will be used over > the former. We should constantly be putting on our "user" hat and/or > talking to users (doing a lot more listening than talking I might add). Thank > you for your response. The issues you have raised should be considered > as we move forward. I agree with both of you, but the charter of this (if it becomes such) group must be to get a working protocol as a standard soon, and that means getting agreement. Attempting to create solutions for problems that commercial products aren't negotiating yet, or attempting to make it all elegant from the outset will leave large commercial vendors left to implementing what they need and have standards being created de facto by one or two players. We need a solution that creates reasonable consensus in the working group in a timely fashion. I think that means a limited set of requirements. Don LaVange dlavange@novell.com (replying from private account) ------=_NextPart_000_01BB9A44.9A268550 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

My comments below:

> From: = Steve Carter <srcarter@novell.com>
>> Denis BIGORGNE <Denis.Bigorgne@sept.fr> 08/30/96 11:06am >>>
> >In the = C&S Overview document, the Freetime Lookup function  
> = >seems adapted to corporate environments, where calendar
> = >sharing is a fair rule. I=12m not sure that extensive request of 21 =
> >days freetime map could be accepted for automated
> = >appointment scheduling made outside the enterprise ; there
> = >could be too many indiscretions opportunities, like trying to =
> >know who is busy at the same time...
>
> Point = well taken, but I think we will find ourselves needed to = organize
> groups of disperse individuals for meetings (phone, = teleconference,
> face-to-face, chat, collaborative document, = etc., etc.) much more in the
> future and the need to schedule = time from a free time list is very
> important. Each of us has = time that is private, time that is scheduled, and
> time that is = available. I suggest that we have this kind of designation for
> = our calendars. If several people have time marked "private" at = the same
> time and others can see it, that may or may not be = bad.

I see Denis' point here for "indescretious use". =  But client implentation of this data manipulation doesn't have to = correspond to the actual object that one wishes marked private.  I = can envision painting sub-regions "private" and marking = "all private" to users outside an identified group.  In = short, I think that allowing multiple day searches for a given time slot = is benificial enough to provide protocol support for it, and that client = implementation can give reasonable protection to the calendar owner = concerned about any kind of data spying.

> Thus to my next = point. We need to have a globally deployed PKI that will
> allow = us to use certificates at various levels to authenticate requests = for
> calendar (read personal and/or professional here) = information. Even at
> this point you still have a valid point = about the "private" time or
> "scheduled" = times that you don't want others to interrogate. <<on-line
> = thought>> Perhaps we need another calendar distinction called = "black
> out" that returns a random mixture of = non-response, scheduled time,
> and/or private time? <<end = of on-line thought>>

Although this is a client issue as = well, it seems you would simply want to have blackout not show = availability or scheduled time at all, or show selective data to = differing levels of users (exception list gets all, named domain gets = public, and externals get nothing)  All of this presupposes the = client has some sort of directory accessible.  <<on line = thought>> Perhaps a request for schedule times  that gets = blacked out automatically generates a "knock" request, where = the requestee can manually respond with rejection, one time, timed = limit, or permanent admission to the exception group as requests to the = calendar owner being queried or the request for this particular item. =  I suppose this is all doeable in the client but that leaves lots = of room for simple clients to not protect the calendar owner. = <<end of OLT>>.

> >Instead of a one-shot ORing = of freetime maps, the appointment
> >scheduling could use a = multi-round negotiation algorithm
> >controlling the exchange = of a list of time-slots (or ranges)
> >arranged by preference = order. At each step, the list should be
> >narrowed, = discarding the impossibilities ; if the list is reduced
> >to = null, an extension should be proposed... For two-parts
> = >meeting, a simple round may be sufficient ; for numerous
> = >invitee, many rounds could be required, with a succession of =
> >narrowing and extension phases. At SEPT, we developed a PC =
> >conference appointment scheduling demo using list of ten = time-
> >slots ; I have been told that in some corporation, the = directive
> >for non-automated scheduling requires an initial = list of  only
> >three time-slots.
>
> In my = response to Peter's paper I specified that ORing takes place as
> = each response is received and that work to schedule a meeting can = be
> taking place during the receipt of the free time lists. On = the client each
> free list is processed as it is received. = Perhaps you are talking about
> having a server process do the = progressive ORing? I'm not clear what
> your point is here -- = please clarify.

Seems that the multiple round negotiation would = provide a much longer hand holding period for the successful schedule of = a meeting.  Perhaps, there are certain attendees that must accept = or the meeting is cancelled, or a certain percentage of attendees must = respond favorably.  Only when the criterion are met after several = passes would the meeting actually be scheduled.  However, this = seems way beyond the scope of a protocol this group might see = implemented as a standard.

> >I understand my comments goes = beyond the capabilities of the
> >majority of the current = calendar products ; this is explainable - I
> >don=12t speak = from a technology provider point of view, but from
> >an user = one, and more, an user interested in teleconferencing in
> >a = general environment (not corporate). If we are to establish an
> = >interoperability standard on the Internet, these aspects should =
> >not be forgotten.
>
> If we design to = technology we'll get a technology solution. Design from
> user = work practice will yield a user solution. The latter will be used = over
> the former. We should constantly be putting on our = "user" hat and/or
> talking to users (doing a lot more = listening than talking I might add). Thank
> you for your = response. The issues you have raised should be considered
> as we = move forward.

I agree with both of you, but the charter of this = (if it becomes such) group must be to get a working protocol as a = standard soon, and that means getting agreement.  Attempting to = create solutions for problems that commercial products aren't = negotiating yet, or attempting to make it all elegant from the outset = will leave large commercial vendors left to implementing what they need = and have standards being created de facto by one or two players. =  We need a solution that creates reasonable consensus in the = working group in a timely fashion.  I think that means a limited = set of requirements.

Don = LaVange
dlavange@novell.com

(replying from private = account)

------=_NextPart_000_01BB9A44.9A268550-- From owner-ietf-calendar Wed Sep 4 08:49:45 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id IAA05845 for ietf-calendar-bks; Wed, 4 Sep 1996 08:49:45 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mh1.well.com (mh1.well.com [206.15.64.22]) by imc.org (8.7.4/8.7.3) with ESMTP id IAA05840 for ; Wed, 4 Sep 1996 08:49:44 -0700 (PDT) Received: from gwresearch (gwresearch.orem.novell.com [151.155.61.177]) by mh1.well.com (8.7.5/8.7.5) with ESMTP id IAA20081; Wed, 4 Sep 1996 08:56:12 -0700 (PDT) Message-Id: <199609041556.IAA20081@mh1.well.com> From: "Don LaVange" To: , "Anik Ganguly" Subject: Re: Proposed charter Date: Wed, 4 Sep 1996 09:54:26 -0600 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BB9A47.0EEF7430" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01BB9A47.0EEF7430 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Anik for posting this. I am a little concerned with vagueness in the two quoted paragraphs below. If we are initally chartered to focus on internet standards and this is a 6-9 month task does it make sense to attack non-internet issues like the desktop interaction between calendar scheduler entities? It seems it might be prudent to focus on the standards for internet requirments and create a separate group to deal with the desktop. Are we assuming here that if we use something like vcal as the format perhaps this just falls out as a standard for the desktop? Seems like this might be taking on to much weight for the task. Other than that the charter seems reasonable to me. > The group will exist to create standards that make calendaring and > scheduling software significantly more useful and to enable a new class of > solutions to be built that are only viable if open standards exist. To this > end, the Calendaring and Scheduling Working Group will consider all ideas > relating calendaring and meeting scheduling but is chartered to initially > focus on Internet standards for three basic problems facing group scheduling > and calendaring users today. These include the following: > > 1. A standard content type for capturing calendar event and to-do > information. The content type should be suitable as a MIME message entity > that can be transferred over MIME based email systems or HTTP World Wide > Web, as well as, useful as an object for interacting between desktop > applications using the operating system clipboard, drag/drop or file systems > capabilities. The basic objects along with their representation using MIME > will be specified in the document entitled "Core Object Specification". Don ------------- Don LaVange dlavange@novell.com (replying from private account) ------=_NextPart_000_01BB9A47.0EEF7430 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks Anik for posting this.

I = am a little concerned with vagueness in the two quoted paragraphs below. =  If we are initally chartered to focus on internet standards and = this is a 6-9 month task does it make sense to attack non-internet = issues like the desktop interaction between calendar scheduler entities? =  It seems it might be prudent to focus on the standards for = internet requirments and create a separate group to deal with the = desktop.  Are we assuming here that if we use something like vcal = as the format perhaps this just falls out as a standard for the desktop? =  Seems like this might be taking on to much weight for the = task.

Other than that the charter seems reasonable to = me.

> The group will exist to create standards that make = calendaring and
> scheduling software significantly more useful = and to enable a new class of
> solutions to be built that are only = viable if open standards exist.  To this
> end, the = Calendaring and Scheduling Working Group will consider all ideas
> = relating calendaring and meeting scheduling but is chartered to = initially
> focus on Internet standards for three basic problems = facing group scheduling
> and calendaring users today. These = include the following:
>
> 1. A standard content type for = capturing calendar event and to-do
> information. The content type = should be suitable as a MIME message entity
> that can be = transferred over MIME based email systems or HTTP World Wide
> = Web, as well as, useful as an object for interacting between = desktop
> applications using the operating system clipboard, = drag/drop or file systems
> capabilities.  The basic objects = along with their representation using MIME
> will be specified in = the document entitled "Core Object = Specification".


Don
-------------
Don = LaVange
dlavange@novell.com

(replying from private = account)

------=_NextPart_000_01BB9A47.0EEF7430-- From owner-ietf-calendar Wed Sep 4 09:26:46 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA06124 for ietf-calendar-bks; Wed, 4 Sep 1996 09:26:46 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mh1.well.com (mh1.well.com [206.15.64.22]) by imc.org (8.7.4/8.7.3) with ESMTP id JAA06119 for ; Wed, 4 Sep 1996 09:26:45 -0700 (PDT) Received: from gwresearch (gwresearch.orem.novell.com [151.155.61.177]) by mh1.well.com (8.7.5/8.7.5) with ESMTP id JAA25660; Wed, 4 Sep 1996 09:33:14 -0700 (PDT) Message-Id: <199609041633.JAA25660@mh1.well.com> From: "Don LaVange" To: , "Anik Ganguly" Subject: Re: A minimal set of objects and transactions Date: Wed, 4 Sep 1996 10:30:24 -0600 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BB9A4C.14DD9AC0" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01BB9A4C.14DD9AC0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My comments below: > 2. Cancel an existing meeting > The purpose of this transaction is to notify the set of people (and/or > resources) who were invited to a meeting that the meeting has been canceled. > The core object that is transmitted in this transaction is the "event > object" and should probably include a unique identifier for the existing > meeting. It seems that the request here should be to both send such a notification to the user as well as remove the actual event from the calendar. I have seen where mail messages "cancelling" a meeting that were not linked to the data itself generated attendance at the scheduled meeting because the calendar dictated the attendance and the email notification was forgotten. This is true for items 3 and 4 as well. I do concede that this is doeable in the client given the notification described but thought it should be specified. > Additional, optional attributes > Location of meeting > Recurrence specification for recurring meeting > Security classification of meeting (e.g. private, public, etc.) > Invitee modifiers (e.g. mandatory invitee, optional invitee, etc.) > Identifier of the person who proposed the meeting, if different from > the person setting it up I would also like to see a list of attached documents that might be required as reading material for the meeting as a part of the event object. > In the ensuing discussion I would suggest that we can make the best use of > our time if we could agree to work towards consensus on the following issues > in the order presented: > > 1. Agree/reaffirm that system to system interoperability is a worthwhile > goal to pursue > 2. Agree on the minimum set of (system interoperability) transaction that > will provide users with significant benefit > 3. Agree on the minimum set of objects and their attributes needed to > support the minimum set of transactions. > 4. Agree on the "envelope attributes" or whatever we end up calling them > 5. Agree on the mapping of transactions to transport mechanisms (SMTP+MIME), > TCP/IP with defined packets, HTTP+MIME etc. This will probably interact > with #4. I would agree with those goals. ------=_NextPart_000_01BB9A4C.14DD9AC0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

My comments below:

> 2. = Cancel an existing meeting
> The purpose of this transaction is to = notify the set of people (and/or
> resources) who were invited to = a meeting that the meeting has been canceled.
> The core object = that is transmitted in this transaction is the "event
> = object" and should probably include a unique identifier for the = existing
> meeting.

It seems that the request here should = be to both send such a notification to the user as well as remove the = actual event from the calendar.  I have seen where mail messages = "cancelling" a meeting that were not linked to the data itself = generated attendance at the scheduled meeting because the calendar = dictated the attendance and the email notification was forgotten. =  This is true for items 3 and 4 as well.  I do concede that = this is doeable in the client given the notification described but = thought it should be specified.

> =         Additional, optional = attributes
> =         Location of = meeting
> =         Recurrence specification = for recurring meeting
> =         Security classification = of meeting (e.g. private, public, etc.)
> =         Invitee modifiers (e.g. = mandatory invitee, optional invitee, etc.)
> =         Identifier of the person = who proposed the meeting, if different from
> the person setting = it up

I would also like to see a list of attached documents that = might be required as reading material for the meeting as a part of the = event object.

> In the ensuing discussion I would suggest = that we can make the best use of
> our time if we could agree to = work towards consensus on the following issues
> in the order = presented:
>
> 1. Agree/reaffirm that system to system = interoperability is a worthwhile
> goal to pursue
> 2. Agree = on the minimum set of (system interoperability) transaction that
> = will provide users with significant benefit
> 3. Agree on the = minimum set of objects and their attributes needed to
> support = the minimum set of transactions.
> 4. Agree on the "envelope = attributes" or whatever we end up calling them
> 5. Agree on = the mapping of transactions to transport mechanisms (SMTP+MIME),
> = TCP/IP with defined packets, HTTP+MIME etc.  This will probably = interact
> with #4.

I would agree with those goals.

------=_NextPart_000_01BB9A4C.14DD9AC0-- From owner-ietf-calendar Wed Sep 4 09:29:31 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id JAA06145 for ietf-calendar-bks; Wed, 4 Sep 1996 09:29:31 -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 JAA06140 for ; Wed, 4 Sep 1996 09:29:29 -0700 (PDT) Received: from sarrus.com (sarrus [205.219.53.65]) by imakron.sarrus.com (8.7.1/8.7.1) with SMTP id JAA15020; Wed, 4 Sep 1996 09:34:09 -0700 (PDT) Received: from dogbert by sarrus.com (NX5.67d/NeXT-2.0) id AA12968; Wed, 4 Sep 96 09:35:19 -0700 Message-Id: <9609041635.AA12968@sarrus.com> Received: by dogbert.sarrus.com (NX5.67e/NX3.0X) id AA05503; Wed, 4 Sep 96 09:41:28 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: <2.2.32.19960904053333.007027cc@earth.ontime.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) Received: by NeXT.Mailer (1.118.2) From: Liz Statmore Date: Wed, 4 Sep 96 09:41:27 -0700 To: anik@ontime.com (Anik Ganguly) Subject: Re: Proposed charter Cc: ietf-calendar@imc.org Reply-To: liz@sarrus.com References: <2.2.32.19960904053333.007027cc@earth.ontime.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk Anik, This draft looks great -- exactly what we discussed in July down at Netscape. Thanks for doing the legwork to put this together. Regards, Liz Statmore Sarrus Software, Inc. From owner-ietf-calendar Wed Sep 4 10:10:44 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA06388 for ietf-calendar-bks; Wed, 4 Sep 1996 10:10:44 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by imc.org (8.7.4/8.7.3) with ESMTP id KAA06383 for ; Wed, 4 Sep 1996 10:10:41 -0700 (PDT) Received: from iocaine.orem.novell.com (srcarter_pc.orem.novell.com [151.155.60.234]) by xmission.xmission.com (8.7.5/8.7.5) with SMTP id LAA01463; Wed, 4 Sep 1996 11:16:30 -0600 (MDT) Message-ID: <322DB974.47C@xmission.com> Date: Wed, 04 Sep 1996 11:16:36 -0700 From: Steve Carter Reply-To: srcarter@xmission.com X-Mailer: Mozilla 3.0b6Gold (Win95; I) MIME-Version: 1.0 To: Anik Ganguly CC: ietf-calendar@imc.org Subject: Re: Proposed charter References: <2.2.32.19960904053333.007027cc@earth.ontime.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Anik Ganguly wrote: > > Folks, the IETF Applications Directorate has reviewed the charter of the > Proposed Calendaring and Scheduling working group and asked to see some > public discussion on the mailing list to see if any issues need to be > addressed before they forward this to the IESG/IAB for approval. > > The attached version of the charter represents the results of the discussion > at the July 24, 1996 meeting in Mountain View as well as some feedback that > I have recieved from the applications directorate recently. > > Once the WG (represented by this charter) is approved, the real work will > begin so I hope that we can come to "rough concensus" on this charter > quickly and get the WG established. > > > Calendaring and Scheduling (calsch) > ----------------------------------- > > Charter > > Current Status: Proposed Working Group > > Chair(s): > Anik Ganguly > Robert Moskowitz > > Application Area Director(s): > Harald Alvestrand > Keith Moore > > Area Advisor: > Harald Alvestrand > > Mailing List(s): > Submissions: ietf-calendar@imc.org > Requests: ietf-calendar-request@imc.org (SUBSCRIBE/UNSUBSCRIBE > in Message body) > > Archive: > > Description of Working Group: > > Calendaring and group scheduling products are well established for > organizational use, but they usually are limited to exchange of information > among users of the same system, usually within the boundaries of a single > organization. This working group will pursue development of standards to > enable different products to interoperate and to work across organizational > boundaries. This work will include the development of MIME content types to > represent common objects needed for calendaring and group scheduling > transactions and access methods between systems and between clients and > servers. The working group will also consider and recommend solutions to > the security issues concerning the exchange of calendar information between > network entities. What I hear in this paragraph is that we are working to provide "interoperability" with current calendar/schedular "products" that are on the market "e.g., Novell GroupWise, Lotus, Microsoft). We will do this by providing a MIME mechanism and encoding so that common client AND server processes will be interoperable. > > The group will exist to create standards that make calendaring and > scheduling software significantly more useful and to enable a new class of > solutions to be built that are only viable if open standards exist. To this > end, the Calendaring and Scheduling Working Group will consider all ideas > relating calendaring and meeting scheduling but is chartered to initially > focus on Internet standards for three basic problems facing group scheduling > and calendaring users today. These include the following: Further, the standard that we are working will make the existing products "significantly more useful" and provide a mechanism to enable a "new class of solutions." > > 1. A standard content type for capturing calendar event and to-do > information. The content type should be suitable as a MIME message entity > that can be transferred over MIME based email systems or HTTP World Wide > Web, as well as, useful as an object for interacting between desktop > applications using the operating system clipboard, drag/drop or file systems > capabilities. The basic objects along with their representation using MIME > will be specified in the document entitled "Core Object Specification". > > 2. A standard interoperability method for common calendaring and group > scheduling transactions. For example, these may include exchanging over the > Internet, event-requests, reply to event-requests, cancellation notices for > event-requests, requesting free/busy time and replying to free/busy time > requests between different calendaring products. To the extent that the > interoperability method have requirements related to security, the working > group will attempt to apply existing Internet standards for authentication, > and to assure privacy and integrity of sensitive calendaring information. > The method for the interoperable transactions will be specified in a > document entitled "Object Interaction Specification". What "existing" authentication Internet standards are you referring to? > > 3. A standard access method to allow for the management of calendars, events > and to-dos over the Internet. These methods will also be specified in the > document entitled "Object Interaction Specification". I assume that this "management" consists of the items above (e.g., event-requests, reply to event-requests, cancellation notices for event-requests, requesting free/busy time and replying to free/busy time requests). I see "Core Object Specification" and "Object Interaction Specification", but nothing on the protocol (e.g., ICAP). Do you intend that one of the above referenced documents has the protocol in it or will their be another document? > > This working group effort should be developed and stabilized with a > 6-9 months since there has been considerable prior work done in this > area. This prior body of work includes: > > * Distributed Scheduling Protocol (CHRONOS) IETF Working Group > * ISO/IEC SC18 Distributed Office Application for Calendaring, > Scheduling and Appointments > * MHS Alliance Calendaring and Scheduling Interoperability Protocol > (CSIP) > * X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA) > and Calendaring and Scheduling Interoperabilty Specification > (CSIS) > * X/Open Consortium Calendaring and Scheduling (XCS) Implementor's > Specification > * Versit vCalendar format > > The working group will focus on harmonizing, evolving and developing > protocols and algorithms based on this work. The process is subject > to extension if many new features are added, or more revision is > needed. > > Goals and Milestones: > > Develop Architecture and Terms 1-Oct-1996 > > Core object specification > First draft 1-Oct-1996 Since the charter calls out for interoperability, Oct 1, 1996 may be too aggressive a goal. I know that Novell has not worked with the BOF to submit functionality contained in GroupWise 4.1a and GroupWise 5. Let alone determine via the WG what the "core" set of functionality should be. There are also significant issues concerning privacy as well as the authentication mentioned above. > > Second draft 1-Dec-1996 > (San Jose IETF Meeting) > > Draft suitable for proposed standard 15-Mar-1997 > (Spring IETF Meeting) > > Resolve integration issues with Object interaction specification > 1-Jun-1997 > > Object interaction specification > First draft (covering interoperability) 1-Dec-1996 > > Second draft (covering access also) 15-Mar-1997 > (This should be ready to be a proposed standard) > > Resolve integration issues with Core object specification > 1-Jun-1997 > > Anik Ganguly > OnTime/FTP Software Inc. Let's move forward! -src Steve Carter Novell srcarter@novell.com From owner-ietf-calendar Wed Sep 4 10:28:14 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA06473 for ietf-calendar-bks; Wed, 4 Sep 1996 10:28:14 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by imc.org (8.7.4/8.7.3) with ESMTP id KAA06468 for ; Wed, 4 Sep 1996 10:28:12 -0700 (PDT) Received: from iocaine.orem.novell.com (srcarter_pc.orem.novell.com [151.155.60.234]) by xmission.xmission.com (8.7.5/8.7.5) with SMTP id LAA06379; Wed, 4 Sep 1996 11:34:19 -0600 (MDT) Message-ID: <322DBDA0.48EE@xmission.com> Date: Wed, 04 Sep 1996 11:34:24 -0700 From: Steve Carter Reply-To: srcarter@xmission.com X-Mailer: Mozilla 3.0b6Gold (Win95; I) MIME-Version: 1.0 To: Anik Ganguly CC: ietf-calendar@imc.org Subject: Re: A minimal set of objects and transactions References: <2.2.32.19960904053335.006fd360@earth.ontime.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Anik Ganguly wrote: > > I'm humbly submitting this to offer a framework for us to focus our discussion. > > One of the early results that we as a group want to achieve is a mechanism > to allow calendaring and group scheduling software from different vendors to > interoperate. Ideally, a user of C&S product A should be able to setup, > cancel, modify and otherwise manage meetings with a user of C&S product B > with the same fidelity and capability, that they would have, if the other > user was a user of product A. This ideal is impossible to achieve with all > the C&S products today because of two reasons. First, the representation of > the meeting itself varies from product to product (e.g. One product may have > a separate field for meeting location while other products do not). Second, > the actions that users can take relative to a meeting vary from product to > product (e.g. One product may allow a meeting participant to delegate the > meeting while other products do not). Each of these differences cause a > "loss of fidelity" when meetings are managed across products. If you go > further and consider the actions that a user can take to manage their own > calendar, as opposed to setting up meetings, you have a much richer set of > capabilities and more marked differences between different products. > > In the interest of getting something useful done quickly, let me suggest > that we need to agree on a small set of transactions and associated objects > that will allow a user of product A to setup and manage meeting which > include users of product B (of course, for any product A and B). Let me go > further and suggest that we defer the discussion of certain other > transactions until we have agreement on the most basic set. > > Basic transactions: > 1. Propose a new meeting > The purpose of this transaction is to invite a set of people (and/or > resources) to a meeting. The core object that is transmitted in this > transaction is the "event object". > > 2. Cancel an existing meeting > The purpose of this transaction is to notify the set of people (and/or > resources) who were invited to a meeting that the meeting has been canceled. > The core object that is transmitted in this transaction is the "event > object" and should probably include a unique identifier for the existing > meeting. I would suggest that we have an "event change" object that collects all of the changable attributes of an event into one object. This will tend to simplify the event object to definition only. > > 3. Modify an existing meeting > The purpose of this transaction is to notify the set of people (and/or > resources) who were invited to a meeting that certain details of the meeting > have changed. This transaction has two instances of the "event object" > associated with it. The first instance represents the details of the > meeting prior to the change and the second instance represents the modified > details. Perhaps this could be done via an "event change" which deletes the old event (after all it is no longer scheduled and any previous acceptance of the event is not valid) and then a new schedule. Indication that the meeting has been move could be a part of the event message (the part telling the person what is going on) since the event rescheduler will probably want to tell the invitees why the event is being moved. > > 4. Response to an existing meeting > The purpose of this transaction is to allow a person (and/or resource) to > notify the person who is trying to setup the meeting whether they intend to > attend the meeting or not. The core object associated with this transaction > is the "response object". > > Basic objects: > To support the basic transactions, we need the following basic objects: > EVENT > The event object will need to include at a minimum the following > attributes - > Identifier that will uniquely identify this meeting on the > originating system and must be maintained by receiving systems for reference integrity. > Event sequence/version number (starts at 1 and incremented for each > modification) by using the mechanism I propose above this attribute is not needed. > Description of meeting > Date and time meeting begins > Date and time meeting ends I assume this includes some indication of the time zone. > Identifier of person who is setting up the meeting > List of people invited to meeting > List of resources associated with meeting > > Additional, optional attributes > Location of meeting > Recurrence specification for recurring meeting > Security classification of meeting (e.g. private, public, etc.) as per previous messages on the listserver, we still don't know what these mean. > Invitee modifiers (e.g. mandatory invitee, optional invitee, etc.) > Identifier of the person who proposed the meeting, if different from > the person setting it up > > RESPONSE > The response object will need to include at a minimum the following > attributes - > Unique identifier for meeting > Response - Yes, No, Maybe, ... > > Transactions (and associated objects) that we will defer (but not for long) > discussion on: > Free time request/response > Transactions to support "Calendar browsing" This should probably be put of until *much* later. If free time query is a sensitive issue, this one is an order of magnitude more. > > My assumption is that the design team on core objects is busy defining the > EVENT object. I will only ask that they verify that their proposal includes > at least all attributes that are designated as minimum requirements based on > the discussion on the mailing list that this message will hopefully prompt. > > Additionally, we will need the RESPONSE object to be defined and its > representation specified by the core objects design team. > > In terms of the transactions themselves, maybe we can think of transactions > containing "envelope attributes" in addition to the "core objects" that they > transmit. "Envelope attributes" for the "Propose a new meeting" transaction > may include - > protocol version > message identifier > message sequence number > message sent date/time stamp > originating system identifier and version > message_from address > message_to address > message type > > In the ensuing discussion I would suggest that we can make the best use of > our time if we could agree to work towards consensus on the following issues > in the order presented: > > 1. Agree/reaffirm that system to system interoperability is a worthwhile > goal to pursue Agree > 2. Agree on the minimum set of (system interoperability) transaction that > will provide users with significant benefit Agree, we need to work on this > 3. Agree on the minimum set of objects and their attributes needed to > support the minimum set of transactions. Agree, we need to work on this > 4. Agree on the "envelope attributes" or whatever we end up calling them Agree, we need to work on this > 5. Agree on the mapping of transactions to transport mechanisms (SMTP+MIME), > TCP/IP with defined packets, HTTP+MIME etc. This will probably interact > with #4. Agree, we need to work on this > > I hope that this will spark lively but focused discussion and enable us to > gain momentum as a group. > > Respectfully, > Anik Ganguly > OnTime/FTP Software Inc. From owner-ietf-calendar Wed Sep 4 10:42:47 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA06532 for ietf-calendar-bks; Wed, 4 Sep 1996 10:42:47 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by imc.org (8.7.4/8.7.3) with ESMTP id KAA06526 for ; Wed, 4 Sep 1996 10:42:44 -0700 (PDT) Received: from iocaine.orem.novell.com (srcarter_pc.orem.novell.com [151.155.60.234]) by xmission.xmission.com (8.7.5/8.7.5) with SMTP id LAA08779; Wed, 4 Sep 1996 11:46:05 -0600 (MDT) Message-ID: <322DC061.7293@xmission.com> Date: Wed, 04 Sep 1996 11:46:09 -0700 From: Steve Carter Reply-To: srcarter@xmission.com X-Mailer: Mozilla 3.0b6Gold (Win95; I) MIME-Version: 1.0 To: Don LaVange CC: Steve Carter , ietf-calendar@imc.org, Denis.Bigorgne@sept.fr Subject: Re: Freetime Lookup -Reply References: <199609041539.IAA17350@mh1.well.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Don LaVange wrote: > > My comments below: > > > From: Steve Carter > >> Denis BIGORGNE 08/30/96 11:06am >>> > > >In the C&S Overview document, the Freetime Lookup function > > >seems adapted to corporate environments, where calendar > > >sharing is a fair rule. Im not sure that extensive request of 21 > > >days freetime map could be accepted for automated > > >appointment scheduling made outside the enterprise ; there > > >could be too many indiscretions opportunities, like trying to > > >know who is busy at the same time... > > > > Point well taken, but I think we will find ourselves needed to > organize > > groups of disperse individuals for meetings (phone, teleconference, > > face-to-face, chat, collaborative document, etc., etc.) much more in > the > > future and the need to schedule time from a free time list is very > > important. Each of us has time that is private, time that is > scheduled, and > > time that is available. I suggest that we have this kind of > designation for > > our calendars. If several people have time marked "private" at the > same > > time and others can see it, that may or may not be bad. > > I see Denis' point here for "indescretious use". But client > implentation of this data manipulation doesn't have to correspond to > the actual object that one wishes marked private. I can envision > painting sub-regions "private" and marking "all private" to users > outside an identified group. In short, I think that allowing multiple > day searches for a given time slot is benificial enough to provide > protocol support for it, and that client implementation can give > reasonable protection to the calendar owner concerned about any kind > of data spying. > > > Thus to my next point. We need to have a globally deployed PKI that > will > > allow us to use certificates at various levels to authenticate > requests for > > calendar (read personal and/or professional here) information. Even > at > > this point you still have a valid point about the "private" time or > > "scheduled" times that you don't want others to interrogate. > < > thought>> Perhaps we need another calendar distinction called "black > > out" that returns a random mixture of non-response, scheduled time, > > and/or private time? <> > > Although this is a client issue as well, it seems you would simply > want to have blackout not show availability or scheduled time at all, > or show selective data to differing levels of users (exception list > gets all, named domain gets public, and externals get nothing) All of > this presupposes the client has some sort of directory accessible. > <> Perhaps a request for schedule times that gets > blacked out automatically generates a "knock" request, where the > requestee can manually respond with rejection, one time, timed limit, > or permanent admission to the exception group as requests to the > calendar owner being queried or the request for this particular item. > I suppose this is all doeable in the client but that leaves lots of > room for simple clients to not protect the calendar owner. < OLT>>. If we agree that the "private" indication can be sensitive then perhaps "black out" can be as well. I can see the same argument for black out as for private (gee, look these two have the same time slot marked as black out). Thus my comment of "random mixture of non-response, scheduled time, and/or private time." However, I do not feel that that is the answer. Further, knock only helps if the recipient is on-line and at his/her workstation. > > > >Instead of a one-shot ORing of freetime maps, the appointment > > >scheduling could use a multi-round negotiation algorithm > > >controlling the exchange of a list of time-slots (or ranges) > > >arranged by preference order. At each step, the list should be > > >narrowed, discarding the impossibilities ; if the list is reduced > > >to null, an extension should be proposed... For two-parts > > >meeting, a simple round may be sufficient ; for numerous > > >invitee, many rounds could be required, with a succession of > > >narrowing and extension phases. At SEPT, we developed a PC > > >conference appointment scheduling demo using list of ten time- > > >slots ; I have been told that in some corporation, the directive > > >for non-automated scheduling requires an initial list of only > > >three time-slots. > > > > In my response to Peter's paper I specified that ORing takes place > as > > each response is received and that work to schedule a meeting can be > > taking place during the receipt of the free time lists. On the > client each > > free list is processed as it is received. Perhaps you are talking > about > > having a server process do the progressive ORing? I'm not clear what > > your point is here -- please clarify. > > Seems that the multiple round negotiation would provide a much longer > hand holding period for the successful schedule of a meeting. > Perhaps, there are certain attendees that must accept or the meeting > is cancelled, or a certain percentage of attendees must respond > favorably. Only when the criterion are met after several passes would > the meeting actually be scheduled. However, this seems way beyond the > scope of a protocol this group might see implemented as a standard. > > > >I understand my comments goes beyond the capabilities of the > > >majority of the current calendar products ; this is explainable - I > > > >dont speak from a technology provider point of view, but from > > >an user one, and more, an user interested in teleconferencing in > > >a general environment (not corporate). If we are to establish an > > >interoperability standard on the Internet, these aspects should > > >not be forgotten. > > > > If we design to technology we'll get a technology solution. Design > from > > user work practice will yield a user solution. The latter will be > used over > > the former. We should constantly be putting on our "user" hat and/or > > talking to users (doing a lot more listening than talking I might > add). Thank > > you for your response. The issues you have raised should be > considered > > as we move forward. > > I agree with both of you, but the charter of this (if it becomes such) > group must be to get a working protocol as a standard soon, and that > means getting agreement. Attempting to create solutions for problems > that commercial products aren't negotiating yet, or attempting to make > it all elegant from the outset will leave large commercial vendors > left to implementing what they need and have standards being created > de facto by one or two players. We need a solution that creates > reasonable consensus in the working group in a timely fashion. I > think that means a limited set of requirements. > Amen! (and not just because I'm from Novell ;-)) > Don LaVange > dlavange@novell.com > > (replying from private account) -- -src Steve Carter Novell srcarter@novell.com From owner-ietf-calendar Wed Sep 4 10:56:38 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id KAA06583 for ietf-calendar-bks; Wed, 4 Sep 1996 10:56:38 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from pilot.firewall.is.chrysler.com (firewall-user@pilot.is.chrysler.com [204.189.94.35]) by imc.org (8.7.4/8.7.3) with SMTP id KAA06578 for ; Wed, 4 Sep 1996 10:56:34 -0700 (PDT) Received: by pilot.firewall.is.chrysler.com; id OAA05686; Wed, 4 Sep 1996 14:02:35 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma005681; Wed, 4 Sep 96 14:02:16 -0400 Received: from rgm3 ([172.16.252.20]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id NAA00739; Wed, 4 Sep 1996 13:54:03 -0400 (EDT) Message-Id: <3.0b15.32.19960904135702.009ce4a0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b15 (32) Date: Wed, 04 Sep 1996 13:59:25 -0400 To: "Don LaVange" , , "Anik Ganguly" From: Robert Moskowitz Subject: Re: Proposed charter Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ietf-calendar@imc.org Precedence: bulk At 09:54 AM 9/4/96 -0600, Don LaVange wrote: >>>> ArialThanks Anik for posting this. I am a little concerned with vagueness in the two quoted paragraphs below. If we are initally chartered to focus on internet standards and this is a 6-9 month task does it make sense to attack non-internet issues like the desktop interaction between calendar scheduler entities? It seems it might be prudent to focus on the standards for internet requirments and create a <<<<<<<< In the tradition of the IETF, we like to see rewritten paragraphs to critiques of paragraphs ;) Can you really take a crack at it? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ietf-calendar Wed Sep 4 11:08:32 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA06678 for ietf-calendar-bks; Wed, 4 Sep 1996 11:08: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 LAA06673 for ; Wed, 4 Sep 1996 11:08: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 LAA22107; Wed, 4 Sep 1996 11:14:55 -0700 Message-ID: <322DC66D.1220@clearblue.com> Date: Wed, 04 Sep 1996 11:11:57 -0700 From: "Peter O'Leary" Reply-To: poleary@clearblue.com Organization: Clear Blue Network Systems, Inc. X-Mailer: Mozilla 3.0b6 (Win95; I) MIME-Version: 1.0 To: Stephen R Hanna CC: ietf-calendar@imc.org Subject: Re: C&S Overview References: <199609032213.AA11697@world.std.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Stephen R Hanna wrote: > > Pete, > > I like your new document. Very thorough. Here are a few comments: > > Meeting Maker XP uses meeting invitations instead of direct book, but > we use a direct connection, not S&F comm. I would like to see this > architectural choice reflected in section 2.2. I don't think we're > the only ones using it. Will do. I will contact you to get more details. > In section 2.2.2, I'd like to see you address the question of how > email is delivered to the C&S system. I believe that some systems > require the user to transfer the email manually from their inbox, > whereas others are integrated with the email system and pick up > the mail automatically. Is that right? What about outgoing mail? > Same idea? I will add some clarification. Both of the methods you describe are used in practice to get mail into the C&S system. I believe that outgoing mail messages are usually submitted directly either via SMTP, VIM or MAPI. > In section 2.3, you describe the functionality provided by a > Calendar store briefly. You don't get into many details. Does > the Calendar store keep a record of each user's entire calendar > for all users served by that store? I assume it must in order > to support Calendar Browsing and Proxy Access. That makes > it rather different in function from an ICAP server, I believe. ICAP doesn't mandate that everyone's calendar store reside on the same server: it is purposely a little mushy on this subject. > In section 2.4, you provide a list of features that must be provided > by a Directory for a C&S system. > > First, I would suggest that any C&S standard should not include a > full Directory Service, but be designed to take advantage of an > external one. I agree completely that we shouldn't create yet another Directory Service. I think we should be fairly rigorous in defining which DS is used and how it is used. > Second, I would suggest that many of the items you say "must be > available to a C&S system" are not in fact required, but optional > for many scenarios. For instance, user profile information should > not be required in order to send an appointment to a user. An > email address or user id and location of their Calendar server or > Calendar store should be sufficient. > > In section 2.4.1, you say that Freetime Lookup and Calendar Browsing > require the network address of the server. Can't those be performed > via email? I believe that in many systems they are. I previously described Freetime Lookup via e-mail, so 2.4.1 is indeed slightly wrong. I did not describe Calendar Browsing via e-mail however and am not aware of any implementation which supports this. > In section 3, you provide a list of specifications required to > define a standard for C&S on the Internet. I would like to see this > fleshed out with a list of scenarios describing how these pieces > would fit together. I would love to start on this list of scenarios as soon as we have some consensus about the scope of the work to be done. I don't want to do a bunch of detail work that nobody needs. > Defining two protocols, S&F and direct connect, will be > complicated. I want to see a compelling requirement to do so. > If we do so, I would hate to be required to use S&F for some > things and direct connect for others. Lets make direct connect > able to perform all operations (maybe S&F, too). Unfortunately, many existing systems are a blend of both direct connect and S&F. I hope we don't have to have S&F and DC perform ALL C&S actions, this would be alot of work. I'd like to see other members of the group weigh on the operations that I've already defined so we can get a sense of how many other types of operations need to be supported. > I don't think that a single directory service for accessing user > profile information is necessary, just a standard for how that > data should be stored in whatever directory service is in use. I agree. > Finally, the requirement for mapping an SMTP mail address to > a server host name assumes that the mail address will be a C&S > user's unique identifier. I like this idea, but it should > probably be stated more clearly. It also assumes that direct > connect will be used to communicate to the server. It does not *assume* that direct connect will be used, it merely points out that a host name will be needed for direct connect. I've tried to make no assumptions about how I think a C&S system should work: the exercise I'm trying to do is detail - to the best of my humble knowledge - how such systems *do* work so we can scope out all the requirements. I will incorporate your comments into the next draft of this document. Thanks, Pete. From owner-ietf-calendar Wed Sep 4 11:26:16 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA06763 for ietf-calendar-bks; Wed, 4 Sep 1996 11:26:16 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from pilot.firewall.is.chrysler.com (firewall-user@pilot.is.chrysler.com [204.189.94.35]) by imc.org (8.7.4/8.7.3) with SMTP id LAA06758 for ; Wed, 4 Sep 1996 11:26:14 -0700 (PDT) Received: by pilot.firewall.is.chrysler.com; id OAA06676; Wed, 4 Sep 1996 14:32:41 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma006666; Wed, 4 Sep 96 14:32:28 -0400 Received: from rgm3 ([172.16.252.20]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id OAA01656; Wed, 4 Sep 1996 14:24:16 -0400 (EDT) Message-Id: <3.0b15.32.19960904142756.00dde5f0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b15 (32) Date: Wed, 04 Sep 1996 14:29:38 -0400 To: srcarter@xmission.com, Anik Ganguly From: Robert Moskowitz Subject: Re: A minimal set of objects and transactions Cc: ietf-calendar@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@imc.org Precedence: bulk At 11:34 AM 9/4/96 -0700, Steve Carter wrote: > >> Description of meeting >> Date and time meeting begins >> Date and time meeting ends > >I assume this includes some indication of the time zone. I'm in a heavy RFP meeting and this message hit my funny bone just when I needed it. Here we are in the middle of the 'year 2000' data conversion and we are still earth centric for time... Sorry if funny bones are not your thing today. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ietf-calendar Wed Sep 4 11:47:10 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id LAA06841 for ietf-calendar-bks; Wed, 4 Sep 1996 11:47:10 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from oslo.Accordance.COM (oslo.Accordance.COM [204.57.50.1]) by imc.org (8.7.4/8.7.3) with ESMTP id LAA06836 for ; Wed, 4 Sep 1996 11:46:27 -0700 (PDT) Received: from oslo.accordance.com (jscottb.Accordance.COM [204.57.50.22]) by oslo.Accordance.COM (8.7.5/8.6.4) with SMTP id OAA13862; Wed, 4 Sep 1996 14:54:34 -0400 (EDT) Message-ID: <322DCF29.15FA@Software.com> Date: Wed, 04 Sep 1996 14:49:13 -0400 From: "J. Scott Benson" Reply-To: Scott@software.com Organization: Software.com X-Mailer: Mozilla 3.0b6 (Win95; I) MIME-Version: 1.0 To: Anik Ganguly CC: ietf-calendar@imc.org Subject: Re: Proposed charter References: <2.2.32.19960904053333.007027cc@earth.ontime.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk Anik, Your proposed charter looks great to me. -Scott ________________________ J. Scott Benson Vice President, Marketing Software.com, Inc. (617) 274.7000 ext. 234 Scott@Software.com http://www.Software.com From owner-ietf-calendar Wed Sep 4 13:18:11 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.3) id NAA07299 for ietf-calendar-bks; Wed, 4 Sep 1996 13:18:11 -0700 (PDT) X-Authentication-Warning: imc.org: majordomo set sender to owner-ietf-calendar using -f Received: from mh1.well.com (mh1.well.com [206.15.64.22]) by imc.org (8.7.4/8.7.3) with ESMTP id NAA07294 for ; Wed, 4 Sep 1996 13:18:10 -0700 (PDT) Received: from gwresearch (gwresearch.orem.novell.com [151.155.61.177]) by mh1.well.com (8.7.5/8.7.5) with ESMTP id NAA14051; Wed, 4 Sep 1996 13:17:47 -0700 (PDT) Message-Id: <199609042017.NAA14051@mh1.well.com> From: "Don LaVange" To: Cc: "Steve Carter" , , Subject: Re: Freetime Lookup -Reply Date: Wed, 4 Sep 1996 14:14:08 -0600 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BB9A6B.565E2810" Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01BB9A6B.565E2810 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I said: > > <> Perhaps a request for schedule times that gets > > blacked out automatically generates a "knock" request, where the > > requestee can manually respond with rejection, one time, timed limit, > > or permanent admission to the exception group as requests to the > >