From owner-ietf-calendar@mail.imc.org Thu Mar 1 05:41:25 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29229 for ; Thu, 1 Mar 2001 05:41:25 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id CAA29119 for ietf-calendar-bks; Thu, 1 Mar 2001 02:29:01 -0800 (PST) Received: from web12606.mail.yahoo.com (web12606.mail.yahoo.com [216.136.173.229]) by above.proper.com (8.9.3/8.9.3) with SMTP id CAA29110 for ; Thu, 1 Mar 2001 02:28:59 -0800 (PST) Message-ID: <20010301102859.66035.qmail@web12606.mail.yahoo.com> Received: from [195.92.67.72] by web12606.mail.yahoo.com; Thu, 01 Mar 2001 10:28:59 GMT Date: Thu, 1 Mar 2001 10:28:59 +0000 (GMT) From: =?iso-8859-1?q?Andrew=20Proud?= Subject: Re: Updates to appointments - clarification To: ietf-calendar@imc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit To clarify as requested. I was thinking of the situation where an ics file is received either by e-mail or openned directly from a web page. (or a combination) Example - User visits Company A's website to find dates/times of an event. - He downloads the details into his PIM directly from the site. - Company 'A' changes the date/time of the meeting. They now need some way of informing the user that the details have changed. (Perhaps they collected his e-mail address during the download process. ) The desired aproach from the company would be to e-mail the user a new ics file. Then simply by openeing the file the user would receive the new dates/times. It would be great if these new details could update the old event details, rather than just be treated as a new entry. If they do not, the user is forced to go into his PIM and manually delete the original entry. Andy --- Bruce_Kahn@iris.com wrote: > John replied: > >> If the event was created by importing an > Icalendar > >> file, there will be a unique ID. If a new event > was > >> sent with the same ID, could this not update the > >> original event ? > > > >Might. It'd be up to the implementation. > > Guess Id have to ask Andrew "What do you mean by new > event?" before I > could really answer. If its already in the store > then its not new now is > it? New as in the user created a new entry and > somehow the UID given it > matches? New as in the user imported another > iCalendar file and the same > UID was used? Assumptions tend to bite our > collective behinds in the long > run... > > Andrew, could you clarify what you meant by "new > event was sent"? > > Bruce > =========================================================================== > Bruce Kahn INet: > Bruce_Kahn@iris.com > Iris Associates Phone: > 978.392.5335 > Westford, MA, USA 01886 FAX: and > nothing but the FAX... > Standard disclaimers apply, even where prohibited by > law... > ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie From owner-ietf-calendar@mail.imc.org Thu Mar 1 10:18:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06788 for ; Thu, 1 Mar 2001 10:18:25 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA25525 for ietf-calendar-bks; Thu, 1 Mar 2001 07:03:03 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA25520 for ; Thu, 1 Mar 2001 07:03:02 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f21F9If08929 for ; Thu, 1 Mar 2001 10:09:19 -0500 Message-ID: <3A9E56B5.75B56CF9@ecal.com> Date: Thu, 01 Mar 2001 09:03:33 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Updates to appointments - clarification References: <20010301102859.66035.qmail@web12606.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrew Proud wrote: > I was thinking of the situation where an ics file is > received either by e-mail or openned directly from a > web page. (or a combination) Right. If the updated iCalendar has the same UID as the original, then the recipient's CUA can match them up and replace the old one with the new. The CUA probably should not do this if the new iCalendar's SEQUENCE number is less than the old one's. However, again, "import an iCalendar" is not a defined operation, so what the CUA does with the iCalendar is implementation-dependent. It could interpret it as the time at which to spam the world with pictures of the user cavorting with naked tractors...though it probably won't. ;-) Now, if the original iCalendar was an iTIP PUBLISH message, and the CUA implements iTIP and accepts the iCalendar as an iTIP message, then, yes, the updated message will cause the CUA to overwrite the old one (if the SEQUENCE number is greater). -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Some days, it just doesn't pay to gnaw through| |francis@ecal.com|the straps. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 1 10:19:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06823 for ; Thu, 1 Mar 2001 10:19:03 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA25512 for ietf-calendar-bks; Thu, 1 Mar 2001 07:02:54 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA25507 for ; Thu, 1 Mar 2001 07:02:52 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f21F96f08918 for ; Thu, 1 Mar 2001 10:09:08 -0500 Message-ID: <3A9E54D1.41A9B2F5@ecal.com> Date: Thu, 01 Mar 2001 08:55:29 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Guide to internet calendaring draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > Alex, as has been stated on the list a couple of times, and in > minutes, iRIP is being replaced by CRISP. I believe John was > going to submit another version of it to keep it active. Actually, I updated the CRISP draft with people's comments in December, so it won't expire until June. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Some days, it just doesn't pay to gnaw through| |francis@ecal.com|the straps. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 1 10:44:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07681 for ; Thu, 1 Mar 2001 10:44:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA27806 for ietf-calendar-bks; Thu, 1 Mar 2001 07:30:56 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA27790 for ; Thu, 1 Mar 2001 07:30:52 -0800 (PST) From: Bruce_Kahn@iris.com To: fortin@teamsoft.com (Gilles Fortin) Cc: ietf-calendar@imc.org Subject: RE: vTODO due/duration conflict MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02222001 February 22, 2001 Message-ID: Date: Thu, 1 Mar 2001 10:31:47 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/01/2001 10:39:21 AM, Serialize complete at 03/01/2001 10:39:21 AM Content-Type: multipart/alternative; boundary="=_alternative 00553F6B85256A02_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00553F6B85256A02_= Content-Type: text/plain; charset="us-ascii" Gilles replied: > You may want to define a VTODO "Write income tax statement" that you > estimate will take you 4 hours to do, and which you have to complete by a > legal dead line. If you calendaring application is able to sum up the > durations of your to dos, you will have idea of your future workload. Once > you has done the work, you can then record the actual time it took for a > better estimate next year... Ok, since you have a 'legal dead line' you have a hard DUE date/time. If you know it will take you 4 hours to do then you can set the DTSTART 4 hours prior to the DUE. I sense you want to use DUE and DURATION instead of DTSTART and DURATION. We did not take that approach as you can tell by the text in 4.8.2.5 Duration: In a "VTODO" calendar component the property may be used to specify a duration for the to-do, instead of an explicit due date/time. based on the definition of DURATION as "a positive duration of time." For the DUE/DURATION model the time is negative in duration or at least in direction and we have always taken the model that time 'flow' is always positive. > I simply do not understand the rationale behind the restriction in RFC 2445: > ;either 'due' or 'duration' may appear in > ; a 'todoprop', but 'due' and 'duration' > ; MUST NOT occur in the same 'todoprop' Perhaps Frank or Derik (if he is still lurking around) can give you their rationale for it but I think I explained it above. In order to KISS, the model of how VTODOs are pegged to a real time interval was basicially 3 scenarios: 1: They have a hard start date/time (DTSTART) and a hard due date/time (DUE). 2: They have a hard start date/time (DTSTART) and take a specific amount of time to complete (DURATION). 3: They have no hard start date/time (no DTSTART) but do have a hard due date/time (DUE). For your cited example, it can simply be done using case #1 by knowing your time to complete it and figuring the DTSTART from the DUE date/time. Since there is nothing that precludes you from starting the VTODO before the DTSTART (ie: Who cares if you finish your taxes early?) case #3 is also suitable for use, depending on your your CUA handles "open starting" entries. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00553F6B85256A02_= Content-Type: text/html; charset="us-ascii"
Gilles replied:
> You may want to define a VTODO "Write income tax statement" that you
> estimate will take you 4 hours to do, and which you have to complete by a
> legal dead line. If you calendaring application is able to sum up the
> durations of your to dos, you will have idea of your future workload. Once
> you has done the work, you can then record the actual time it took for a
> better estimate next year...
Ok, since you have a 'legal dead line' you have a hard DUE date/time.  If you know it will take you 4 hours to do then you can set the DTSTART 4 hours prior to the DUE.  I sense you want to use DUE and DURATION instead of DTSTART and DURATION. We did not take that approach as you can tell by the text in 4.8.2.5 Duration:

            In a "VTODO" calendar component the property may be used
  to specify a duration for the to-do, instead of an explicit due
  date/time.

based on the definition of DURATION as "a positive duration of time."  For the DUE/DURATION model the time is negative in duration or at least in direction and we have always taken the model that time 'flow' is always positive.

> I simply do not understand the rationale behind the restriction in RFC 2445:
>                 ;either 'due' or 'duration' may appear in
>                 ; a 'todoprop', but 'due' and 'duration'
>                 ; MUST NOT occur in the same 'todoprop'
Perhaps Frank or Derik (if he is still lurking around) can give you their rationale for it but I think I explained it above.  In order to KISS, the model of how VTODOs are pegged to a real time interval was basicially 3 scenarios:

1: They have a hard start date/time (DTSTART) and a hard due date/time (DUE).
2: They have a hard start date/time (DTSTART) and take a specific amount of time to complete (DURATION).
3: They have no hard start date/time (no DTSTART) but do have a hard due date/time (DUE).

For your cited example, it can simply be done using case #1 by knowing your time to complete it and figuring the DTSTART from the DUE date/time.  Since there is nothing that precludes you from starting the VTODO before the DTSTART (ie: Who cares if you finish your taxes early?) case #3 is also suitable for use, depending on your your CUA handles "open starting" entries.  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00553F6B85256A02_=-- From owner-ietf-calendar@mail.imc.org Sun Mar 4 03:24:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02652 for ; Sun, 4 Mar 2001 03:24:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA21190 for ietf-calendar-bks; Sun, 4 Mar 2001 00:00:20 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA21177 for ; Sun, 4 Mar 2001 00:00:15 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA17944 for ietf-calendar@imc.org; Sun, 4 Mar 2001 00:00:03 -0800 (PST) Date: Sun, 4 Mar 2001 00:00:03 -0800 (PST) From: Doug Royer Message-Id: <200103040800.AAA17944@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous Y user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and Y static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex Y text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug D C-4 VCAR examples Doug? Y C-5 PUBLISH text Y C-6 REQUEST text Y C-7 REPLY text Y C-8 ADD text Y C-9 CANCEL text Y C-10 REFRESH text Y C-11 COUNTER text Y C-12 DECLINECOUNTER Text Y C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS Y and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property Y C-16 (2.11) Query Schema Y C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Y Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS D Format? Text needs to be written. C-20 (13.) Security Considerations Y See editors note - more text. C-21 Resubmit REQUIREMENTS draft. Y C-22 Document MAXSIZE and MAXRESULT N C-23 Document METHOD is stored in CS database N Only one 'CREATE' per UID. Multple non-CREATE per UID. C-24 Fix the RESPONSE's to be consistant. N and multiple components, one for each TARGET. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: (iCal, iTIP, iMIP) Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 I-4 Add ALARMID to VALARM! I-5 iTIP error. VJOURNAL should be 0 (not 0+) for CANCEL ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com Tuesday discussion: DONE Section 2.4.3 - editor note: Change with new paragraph; Groups may be in a directory with its own ACL model and CAP should use the directory service to expand a UPN subject to the directory service access control model for the authenticated entity. DONE Section 2.4.4.1 - editor note: Your access is a union of all your grants minus a union of all your denies. (We still need to discuss ordering - allow or not. We may not want to fool with it). DONE Section 2.4.4.2 - editor note: We need an example (Steve/Doug) - Paul needs to read this note an example). Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve Section 2.9 Will be discussed earlier in draft - remove altogether. Section 7.1.3 Need to get IANA registration Section 7.1.3 Delete editors note about blank on examples. Need to add an unsuccessful login. Delete all lines except the line that starts with "The following...." - (* Who will do this example) DONE Section 7.2.1.1.1 Get rid of whole paragraph (pargraph above). If you want to generate unique relative CALids, use the GENERATE UID command and use the result as the relative CALid. (we need to make sure that the results are characters that are compatible with our definition of calids) Section 7.2.1.3. The result needs to be consistent with CALID character rules (i.e. no spaces). The example needs one more line with a dot. Steve will do this. DONE Section 7.2.1.5 This issue goes away because we are not doing heirarchial. Remove editors note Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. Section 7.2.2 Need restriction tables. Some are CAP - for the rest of them use iTIP tables (Steve/Doug) we all need to review the text DONE Section 7.2.3.2 Pull editors note - fix applied Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. Section 12.0 Leave as is until we get people to agree. On version shipped after last call, this is what we are going to enhance this section. It does not make sense to do this until working group last call. Updates to iCalendar need to be written and will not be submitted to IANA until last call to WG. Doug Section 13.0 This section is not ready for prime time. Need Paul Hill. Need an editors note. Section 14.0 Needs to be reformatted - Doug will make sure it is consistent. George will do 14 DONE Section 15.1.1. Steve - additions or changes to the CAP schema (replaces Define the Entity). Word entity needs to be removed and replaced throughout the document). Section 15.1.4 Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. DONE Section 16.0 Remove reference to vCard - - - - - - Assignment list: Section 2.4.4.2 - VCAR example (Steve/Doug) Sectoin 2.6 - Steve will research Section 7.1.3 - IANA registration (Pat) Section 7.1.3 - example of unsuccessful login (Who) Section 7.2.1.1. - look at Calid characters (Doug) Section 7.2.1.3 - example line (Steve) Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug) Section 7.2.2. - Restriction tables (Steve/Doug) Section 8.0 - look at consistency of Response code in all drafts (Pat) Section 12.0 - needs work. Check for consistency - Doug Section 13.0 - Paul Hill Section 14.0 - George Section 15.1.1 - replace text (Pat) Section 15.1.4 - add John's text to doc and put on list to look at proposal. - - - - - Work on Restriction table Editor note: Remove references to VDATA (mistake) Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 From owner-ietf-calendar@mail.imc.org Mon Mar 5 20:39:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13283 for ; Mon, 5 Mar 2001 20:39:35 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA06562 for ietf-calendar-bks; Mon, 5 Mar 2001 17:23:22 -0800 (PST) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA06558 for ; Mon, 5 Mar 2001 17:23:20 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f261NMu23631 for ; Mon, 5 Mar 2001 17:23:23 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 5 Mar 2001 17:23:22 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Re: #4 Typo In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 2 Mar 2001 Bruce_Kahn@iris.com wrote: > WRT: #4 Typo > [ABNF] does not expressly indicate any ordering of values since > "*( x / y / z)" > means you can have "X Y Z", "Y X Z", "Z X Y", etc. I do not recall any > ABNF that mandated any orders for component properties. Did I miss 'em? > Perhaps John was referring to something like: > > eventc = "BEGIN" ":" "VEVENT" CRLF > eventprop *alarmc > "END" ":" "VEVENT" CRLF > > which mandates that, say, DTSTART MUST occur before the embedded VALARM. > Was this what John was asking about?? I don't know much about ABNF. Any other comments? eric. From owner-ietf-calendar@mail.imc.org Mon Mar 5 20:39:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13284 for ; Mon, 5 Mar 2001 20:39:36 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA06594 for ietf-calendar-bks; Mon, 5 Mar 2001 17:24:44 -0800 (PST) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA06590 for ; Mon, 5 Mar 2001 17:24:42 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f261Ojo23636 for ; Mon, 5 Mar 2001 17:24:45 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 5 Mar 2001 17:24:45 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Re: #5 ERR Multiple ATTENDEE with Same Value In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 2 Mar 2001 Bruce_Kahn@iris.com wrote: > I reviewed this in my archives and it was unanimously accepted. Make it > so. Any other discussion before I mark it "CLOSED"? eric. From owner-ietf-calendar@mail.imc.org Mon Mar 5 20:43:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13447 for ; Mon, 5 Mar 2001 20:43:43 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA06856 for ietf-calendar-bks; Mon, 5 Mar 2001 17:31:08 -0800 (PST) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA06852 for ; Mon, 5 Mar 2001 17:31:06 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f261V3U23652 for ; Mon, 5 Mar 2001 17:31:09 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 5 Mar 2001 17:31:03 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Re: #6 ICR Mixed DATE and DATE-TIME In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 2 Mar 2001 Bruce_Kahn@iris.com wrote: > While the need for all values to match the DTSTART data type IFF it is > DATE only is important; there was a question rasied about how does one > specify that any occurance on a particular date is to be blocked (ie: > > DTSTART:20010401T140000Z > RRULE;FREQ=DAILY;UNTIL=20010901;BYHOUR=9,10,11 > EXDATE:20010410 > > (Not checked for validity but you get my idea). It would be more than > nice to allow DATE only values if DATE-TIME values are on the DTSTART. The > meaning is "Any instance on the given DATE". I think we covered this in > some thread already but I just wanted to make sure in fixing #3 we did not > preclude the "other way" which is not a problem now. So, as an addendum to my text for #3: However, when the prevailing type is DATE-TIME, EXRULE and EXDATE MAY specify DATE values. These dates MUST be interpreted to exclude all occurrences on the referenced dates." From owner-ietf-calendar@mail.imc.org Mon Mar 5 22:00:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15853 for ; Mon, 5 Mar 2001 22:00:27 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA08106 for ietf-calendar-bks; Mon, 5 Mar 2001 18:44:35 -0800 (PST) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA08102 for ; Mon, 5 Mar 2001 18:44:34 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f262iQY23778; Mon, 5 Mar 2001 18:44:27 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 5 Mar 2001 18:44:26 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Bruce_Kahn@iris.com cc: ietf-calendar@imc.org Subject: RE: vTODO due/duration conflict In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 28 Feb 2001 Bruce_Kahn@iris.com wrote: > So, now that we are on the same page (mostly), the next topic is to > codify this info in the RFC update to address JPs quandry. This is issue #49. eric. From owner-ietf-calendar@mail.imc.org Mon Mar 5 22:21:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16199 for ; Mon, 5 Mar 2001 22:21:57 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA08426 for ietf-calendar-bks; Mon, 5 Mar 2001 19:11:12 -0800 (PST) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA08422 for ; Mon, 5 Mar 2001 19:11:11 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f263B7H23820; Mon, 5 Mar 2001 19:11:08 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 5 Mar 2001 19:11:07 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Graham Gilmore cc: ietf-calendar@imc.org Subject: Re: Semantics of date vs. date/time EXDATEs In-Reply-To: <003301c0a1bc$9ddca2e0$89314dc1@cst.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 28 Feb 2001, Graham Gilmore wrote: > Both of these are marked as 'open'. Does that mean there hasn't > been a consensus on them, or just that they haven't been formally added > to the spec yet? See the text at the end of the issues list. "Open" means that the issue is on the issue list and has not been widely discussed on the list. Some of the "Open" issues should be "Discuss"; this will be changed in the next release of the list. eric. From owner-ietf-calendar@mail.imc.org Tue Mar 6 10:56:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15498 for ; Tue, 6 Mar 2001 10:56:59 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA12122 for ietf-calendar-bks; Tue, 6 Mar 2001 07:37:47 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA12107 for ; Tue, 6 Mar 2001 07:37:45 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f26FiBi08180 for ; Tue, 6 Mar 2001 10:44:12 -0500 Message-ID: <3AA505C9.7FDC4F4E@ecal.com> Date: Tue, 06 Mar 2001 10:44:10 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: #6 ICR Mixed DATE and DATE-TIME References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Eric Busboom wrote: > So, as an addendum to my text for #3: > > However, when the prevailing type is DATE-TIME, EXRULE and EXDATE MAY > specify DATE values. These dates MUST be interpreted to exclude all > occurrences on the referenced dates." Sounds good to me. Thanks! -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"All gateways lose information. Some do it more| |francis@ecal.com|efficiently than others." -- Einar Stefferud | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 6 12:08:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17502 for ; Tue, 6 Mar 2001 12:08:12 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA18958 for ietf-calendar-bks; Tue, 6 Mar 2001 08:48:37 -0800 (PST) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA18953 for ; Tue, 6 Mar 2001 08:48:37 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f26GmVp25465; Tue, 6 Mar 2001 08:48:32 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Tue, 6 Mar 2001 08:48:31 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Bruce_Kahn@iris.com cc: ietf-calendar@imc.org Subject: Re: Do we need GEO-BOUNDS? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 27 Feb 2001 Bruce_Kahn@iris.com wrote: > This addition had some interesting use but it was not fully flushed > is currently on haitus I would suggest we NOT put it into the update > since its not been fleshed out more and the potential crocs removed. > Perhaps when Doug surfaces later he can take up this effort again for > a future revision. I've been leaning this way too. Rejected. eric. From owner-ietf-calendar@mail.imc.org Tue Mar 6 12:11:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17645 for ; Tue, 6 Mar 2001 12:11:06 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA18866 for ietf-calendar-bks; Tue, 6 Mar 2001 08:45:34 -0800 (PST) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA18862 for ; Tue, 6 Mar 2001 08:45:33 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f26GjYS25457 for ; Tue, 6 Mar 2001 08:45:35 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Tue, 6 Mar 2001 08:45:34 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Re: #1 ICR FMTYPE can't hold MIME type; no "/" allowed (Was: Proposed RFC2445 Changes.) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ---------- Forwarded message ---------- Date: Mon, 5 Mar 2001 16:59:27 -0800 (PST) From: Eric Busboom To: Bruce_Kahn@iris.com Cc: ieft-calendar@imc.org, Bob Mahoney , George Babics , Paul Hill , Pat Egen , Steve Mansour Subject: Re: #1 ICR FMTYPE can't hold MIME type; no "/" allowed (Was: Proposed RFC2445 Changes.) On Fri, 2 Mar 2001 Bruce_Kahn@iris.com wrote: > Ill break msgs into singletons so that we can keep coherent toughts. > > WRT: > #1 ICR FMTYPE can't hold MIME type; no "/" allowed > > Its not clear why this was rejected at least from the pages at > msg02989 and msg04619. The text in the latter talks about a FILE-NAME > parameter, not about FMTYPE. Anyone recall the issue with no "/"?? > I cant find it in my full text indexed searchs. The title for this issue was incorrect, and I changed in it the issues list but not on the proposed changes. The issue is really about having a filename as a parameter to Attach, and that idea was rejected after discussion. eric. From owner-ietf-calendar@mail.imc.org Tue Mar 6 16:22:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28691 for ; Tue, 6 Mar 2001 16:22:31 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA03589 for ietf-calendar-bks; Tue, 6 Mar 2001 12:58:01 -0800 (PST) Received: from intermezzo.ximian.com (h00a0cc5351f4.ne.mediaone.net [66.31.95.92]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA03584 for ; Tue, 6 Mar 2001 12:57:59 -0800 (PST) Received: from localhost.localdomain (IDENT:jpr@localhost.localdomain [127.0.0.1]) by intermezzo.ximian.com (8.9.3/8.9.3) with ESMTP id PAA13042 for ; Tue, 6 Mar 2001 15:58:03 -0500 Subject: Re: vTODO due/duration conflict From: JP Rosevear To: ietf-calendar@imc.org Content-Type: text/plain X-Mailer: Evolution/0.8 (Preview Release) Date: 06 Mar 2001 15:58:02 -0500 Message-Id: <983912291.340.1.camel@intermezzo.ximian.com.unknown.domain> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 27 Feb 2001 16:55:33 -0500, Bruce_Kahn@iris.com wrote: > Gilles suggested: > >It seems to me very useful to have a duration for a to do component, for > >time estimates in the context of project management for instance. I do > not > >seen any reason why this would conflict with a due date? > > The duration concept you are referring to is not "How long _should_ it take for this ToDo" but "How long _did_ it take to complete this ToDo". The difference is subtle. If you or > someone wants to coin a new property to indicate this then propose away > but the WG made a conscious decision way back NOT to do "project > management" features in iCalendar. This statement would seem contradictory to having things like priority, percent complete and assigned to/assigned from properties. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Wed Mar 7 07:52:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01914 for ; Wed, 7 Mar 2001 07:52:46 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id EAA12101 for ietf-calendar-bks; Wed, 7 Mar 2001 04:37:18 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA12096 for ; Wed, 7 Mar 2001 04:37:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00751; Wed, 7 Mar 2001 07:37:14 -0500 (EST) Message-Id: <200103071237.HAA00751@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cap-04.txt Date: Wed, 07 Mar 2001 07:37:14 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Calendar Access Protocol (CAP) Author(s) : S. Mansour, D. Royer, G. Babics, P. Hill Filename : draft-ietf-calsch-cap-04.txt Pages : 113 Date : 06-Mar-01 The Calendar Access Protocol (CAP) is an Internet protocol that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). This memo defines the CAP specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-cap-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-cap-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125249.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Sat Mar 10 07:45:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12257 for ; Sat, 10 Mar 2001 07:45:11 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id EAA20307 for ietf-calendar-bks; Sat, 10 Mar 2001 04:15:55 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA20298 for ; Sat, 10 Mar 2001 04:15:53 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA08785; Sat, 10 Mar 2001 07:15:47 -0500 (EST) Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA00284; Sat, 10 Mar 2001 07:15:47 -0500 (EST) Received: from [18.162.0.242] ([18.162.0.242]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id HAA22424; Sat, 10 Mar 2001 07:15:45 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Sat, 10 Mar 2001 07:15:38 -0500 To: agenda@ietf.org From: Bob Mahoney Subject: CALSCH Agenda for IETF 50 Cc: ietf-calendar@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. Agenda Tweaks -Bob Mahoney The usual bashing 2. IPTEL/CALSCH issues -John Stracke Overview of major issues (Will also be covered in WG dinners and such) 3. CAP status -Steve Mansour/George Babics 4. CALSCH.ORG web site -Bob Mahoney 5. Have we bit off more than we can chew? -Steve Mansour Are the sheer size of the documents & scope of effort impeding adoption? 6. "Guide to Internet Calendaring" Last Call -Bob/George 7. RFC updates and status -TBA 7. Plans for further informal meetings during the week. 8. Adjourn. From owner-ietf-calendar@mail.imc.org Sun Mar 11 03:13:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01031 for ; Sun, 11 Mar 2001 03:13:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA17083 for ietf-calendar-bks; Sun, 11 Mar 2001 00:00:10 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA17065 for ; Sun, 11 Mar 2001 00:00:05 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA28257 for ietf-calendar@imc.org; Sun, 11 Mar 2001 00:00:03 -0800 (PST) Date: Sun, 11 Mar 2001 00:00:03 -0800 (PST) From: Doug Royer Message-Id: <200103110800.AAA28257@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous Y user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and Y static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex Y text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug D C-4 VCAR examples Doug? Y C-5 PUBLISH text Y C-6 REQUEST text Y C-7 REPLY text Y C-8 ADD text Y C-9 CANCEL text Y C-10 REFRESH text Y C-11 COUNTER text Y C-12 DECLINECOUNTER Text Y C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS Y and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property Y C-16 (2.11) Query Schema Y C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Y Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS D Format? Text needs to be written. C-20 (13.) Security Considerations Y See editors note - more text. C-21 Resubmit REQUIREMENTS draft. Y C-22 Document MAXSIZE and MAXRESULT N C-23 Document METHOD is stored in CS database N Only one 'CREATE' per UID. Multple non-CREATE per UID. C-24 Fix the RESPONSE's to be consistant. N and multiple components, one for each TARGET. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: (iCal, iTIP, iMIP) Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 I-4 Add ALARMID to VALARM! I-5 iTIP error. VJOURNAL should be 0 (not 0+) for CANCEL ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com Tuesday discussion: DONE Section 2.4.3 - editor note: Change with new paragraph; Groups may be in a directory with its own ACL model and CAP should use the directory service to expand a UPN subject to the directory service access control model for the authenticated entity. DONE Section 2.4.4.1 - editor note: Your access is a union of all your grants minus a union of all your denies. (We still need to discuss ordering - allow or not. We may not want to fool with it). DONE Section 2.4.4.2 - editor note: We need an example (Steve/Doug) - Paul needs to read this note an example). Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve Section 2.9 Will be discussed earlier in draft - remove altogether. Section 7.1.3 Need to get IANA registration Section 7.1.3 Delete editors note about blank on examples. Need to add an unsuccessful login. Delete all lines except the line that starts with "The following...." - (* Who will do this example) DONE Section 7.2.1.1.1 Get rid of whole paragraph (pargraph above). If you want to generate unique relative CALids, use the GENERATE UID command and use the result as the relative CALid. (we need to make sure that the results are characters that are compatible with our definition of calids) Section 7.2.1.3. The result needs to be consistent with CALID character rules (i.e. no spaces). The example needs one more line with a dot. Steve will do this. DONE Section 7.2.1.5 This issue goes away because we are not doing heirarchial. Remove editors note Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. Section 7.2.2 Need restriction tables. Some are CAP - for the rest of them use iTIP tables (Steve/Doug) we all need to review the text DONE Section 7.2.3.2 Pull editors note - fix applied Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. Section 12.0 Leave as is until we get people to agree. On version shipped after last call, this is what we are going to enhance this section. It does not make sense to do this until working group last call. Updates to iCalendar need to be written and will not be submitted to IANA until last call to WG. Doug Section 13.0 This section is not ready for prime time. Need Paul Hill. Need an editors note. Section 14.0 Needs to be reformatted - Doug will make sure it is consistent. George will do 14 DONE Section 15.1.1. Steve - additions or changes to the CAP schema (replaces Define the Entity). Word entity needs to be removed and replaced throughout the document). Section 15.1.4 Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. DONE Section 16.0 Remove reference to vCard - - - - - - Assignment list: Section 2.4.4.2 - VCAR example (Steve/Doug) Sectoin 2.6 - Steve will research Section 7.1.3 - IANA registration (Pat) Section 7.1.3 - example of unsuccessful login (Who) Section 7.2.1.1. - look at Calid characters (Doug) Section 7.2.1.3 - example line (Steve) Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug) Section 7.2.2. - Restriction tables (Steve/Doug) Section 8.0 - look at consistency of Response code in all drafts (Pat) Section 12.0 - needs work. Check for consistency - Doug Section 13.0 - Paul Hill Section 14.0 - George Section 15.1.1 - replace text (Pat) Section 15.1.4 - add John's text to doc and put on list to look at proposal. - - - - - Work on Restriction table Editor note: Remove references to VDATA (mistake) Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 From owner-ietf-calendar@mail.imc.org Mon Mar 12 01:35:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23899 for ; Mon, 12 Mar 2001 01:35:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id WAA29308 for ietf-calendar-bks; Sun, 11 Mar 2001 22:16:26 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id WAA29304 for ; Sun, 11 Mar 2001 22:16:24 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id AAA09442 for ; Mon, 12 Mar 2001 00:14:42 -0600 From: "Shannon J. Clark" To: Subject: RE: CALSCH Agenda for IETF 50 Date: Mon, 12 Mar 2001 00:15:44 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I probably won't be able to attend the meeting, but wanted to weigh in on agenda item 5. My company, JigZaw Inc, is in the process of writing applications that will make extensive use of the various calendaring standards that this group is responsible for, in the course of doing this we have had to spend a great deal of time with the various standards documents. Below are some of my general observations and conclusions, hopefully these will be useful for the general discussion in the meeting. One - the documents were already too long, and every new version of them has only gotten longer - see the CAP proposed standard for a great example of this. Two - while the documents as written serve a useful purpose of having both human readable and machine parseable sections (the ABNF stuff) - this also serves to greatly lengthen the documents, and has frequently been a source of errors cropping up the documentation - where the text and the ABNF examples differ. Three - the documents are very erratic about language usage which serves to confuse the reader - especially around deciding which sections represent components that are MANDATORY to implement and which are truly OPTIONAL. Four - the various interlocking documents and standards do not have a clear sense of the PURPOSE and PLAN behind the various standards and proposed standards - why do we have multiple proposed standards for realtime/live interactions with a calendar server (CAP and iRip etc) More fundamentally there is lacking a clear sense of HOW the various standards will in fact be deployed. Five - Most glaringly some of the MAJOR software products on the market seem to define the use of the iCalendar standard very differently than the standards documents imply - the case of MS Outlook is what I am citing here. Six - There is preponderance of sections to the various documents which address the problem set of Scheduling meetings between individuals - whether using the same basic calendaring service or whether using multiple vendor's systems. This is fine - but it is NOT the same problem set as the general question of the storage and communication of time-related information. My company's products have nearly nothing at all to do with scheduling of meetings - all of the sections of the various standards that involve FREE/BUSY time, attendees, delegates, invitations, organizers, etc are mostly meaningless in the context of what our applications do. We are interested in the standards for a standard means of storing and interchanging complex time-related information - our software harvests this information from a large variety of sources, stores it, sorts it, and otherwise manipulates it for our end users - in a fully standards compliant world I would like to be able to interchange information from my systems to the systems employed by the various firms for whom we provide services. So, for my purposes the large sections of the various standards that deal with scheduling are an impediment for my development purposes. Seven - there are some sections of various standards that might be best pulled OUT of the current standards and made into their own standards. This would simplify the documents considerably, and would also refine reusability of these elements. I propose the following - one, the reoccurrence sections - both the simple and the "full" be pulled OUT and turned into a generalized system for reoccurrence rules. This would greatly simplify the standards, and would allow the reoccurrence rules to be applied in a greater variety of means than currently considered. Two - The working group strongly consider whether CALENDARING - that is the STORAGE of time-related information (Events or ToDo's in particular) be separated in the standards from SCHEDULING - which is the subset of events that have the characteristics of a business meeting (Organizer, attendees, a need for Free/Busy checking, locations, delegates, etc.) Three - The group consider strongly HOW the various standards will in fact be employed in the "real world" - will they be used to exchange information about ONE event at a time (ala vCalendar), to exchange complex calendars (how I thought iCalendar was intended to be used), to allow for interoperability between scheduling systems?, or to provide a generalized framework for applications that have to deal with TIME RELATED issues to handle the storage, electronic definition, and communication of those issues to other applications? Will we ever in fact address such a server by way of a cal://URL or will these systems primarily be addressed in a secondary manner - i.e. hidden by a more common addressing scheme such as HTTP? Hope this was not too long for people to read through and pick our my questions, I will be very curious to hear what is decided at the meeting. thanks, Shannon Clark CEO and Founder, JigZaw Inc. shannon@jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Bob Mahoney Sent: Saturday, March 10, 2001 6:16 AM To: agenda@ietf.org Cc: ietf-calendar@imc.org Subject: CALSCH Agenda for IETF 50 1. Agenda Tweaks -Bob Mahoney The usual bashing 2. IPTEL/CALSCH issues -John Stracke Overview of major issues (Will also be covered in WG dinners and such) 3. CAP status -Steve Mansour/George Babics 4. CALSCH.ORG web site -Bob Mahoney 5. Have we bit off more than we can chew? -Steve Mansour Are the sheer size of the documents & scope of effort impeding adoption? 6. "Guide to Internet Calendaring" Last Call -Bob/George 7. RFC updates and status -TBA 7. Plans for further informal meetings during the week. 8. Adjourn. From owner-ietf-calendar@mail.imc.org Mon Mar 12 11:18:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13060 for ; Mon, 12 Mar 2001 11:18:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA22555 for ietf-calendar-bks; Mon, 12 Mar 2001 08:04:15 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA22548 for ; Mon, 12 Mar 2001 08:04:14 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2CGAoQ31301 for ; Mon, 12 Mar 2001 11:10:50 -0500 Message-ID: <3AACF509.F238C78C@ecal.com> Date: Mon, 12 Mar 2001 11:10:49 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CALSCH Agenda for IETF 50 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > Two - while the documents as written serve a useful purpose of having both > human readable and machine parseable sections (the ABNF stuff) - this also > serves to greatly lengthen the documents, and has frequently been a source > of errors cropping up the documentation - where the text and the ABNF > examples differ. I think part of the problem here is that the ABNF is incomplete; it can't specify things like "these appear in any order, but no more than one of each", so such statements get relegated to comments and the text. Short of definining a new formal grammar (), we don't really have a solution for this. > why do we have multiple proposed standards for realtime/live > interactions with a calendar server (CAP and iRip etc) Um...because we're not done yet? iRIP went by the wayside a couple of years ago, and then it was realized that CAP could serve the same purpose. This has been the case for some time (I remember Steve Mansour pointed it out to me in Oslo, so that's 20 months ago), and the iRIP drafts have long since expired. > Five - Most glaringly some of the MAJOR software products on the market seem > to define the use of the iCalendar standard very differently than the > standards documents imply - the case of MS Outlook is what I am citing here. Does this surprise you? Everybody has trouble implementing a standard correctly when it's new (that's why we have Proposed Standard, Draft Standard, and Standard); if any vendor is going to be an exception, it won't be MS (see the Halloween Memos for why not). > Six - There is preponderance of sections to the various documents which > address the problem set of Scheduling meetings between individuals That's because scheduling is where people have the deepest experience; it's the problem people set out to solve. If you want a data model that matches what you're doing, please write up a Draft describing your needs. > I propose the following - one, the reoccurrence sections - both the simple > and the "full" be pulled OUT and turned into a generalized system for > reoccurrence rules. Very bad idea. Recurrence rule syntaxes are nasty, twisted little beasties; the last thing we want to do is grant them more freedom to proliferate. It is my opinion that we need to rein in the RRULE syntax, and adopt a subset; but, even if we wind up supporting both the subset and the current full syntax, I would not want to use a generic mechanism that would let people add more in the future. > Hope this was not too long for people to read through and pick our my > questions, I will be very curious to hear what is decided at the meeting. Nothing is ever decided at IETF meetings. Decisions get made on the list, so as not to exclude anybody; meetings are just for talking things through faster, so that the people at the meeting can move closer to consensus (or, at least, a better understanding of their disagreements ;-) and then try to spread that consensus to the rest of the WG. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I'm on a Mission From God to Save The World from| |francis@ecal.com|megalomania! | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 12 12:17:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14564 for ; Mon, 12 Mar 2001 12:17:55 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA24226 for ietf-calendar-bks; Mon, 12 Mar 2001 08:53:25 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA24222 for ; Mon, 12 Mar 2001 08:53:18 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2CGt9w28027 for ; Mon, 12 Mar 2001 10:55:09 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 12 Mar 2001 10:53:19 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Mon, 12 Mar 2001 10:53:19 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB0361FC3D@daeis06nok> To: francis@ecal.com, ietf-calendar@imc.org Subject: RE: CALSCH Agenda for IETF 50 Date: Mon, 12 Mar 2001 10:53:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Six - There is preponderance of sections to the various > documents which > > address the problem set of Scheduling meetings between individuals > > That's because scheduling is where people have the deepest > experience; it's the > problem people set out to solve. If you want a data model > that matches what > you're doing, please write up a Draft describing your needs. > Yep, the original IETF CALSCH effort was chartered to focus on "interpersonal C&S". > > I propose the following - one, the reoccurrence sections - > both the simple > > and the "full" be pulled OUT and turned into a generalized > system for > > reoccurrence rules. > > Very bad idea. Recurrence rule syntaxes are nasty, twisted > little beasties; > the last thing we want to do is grant them more freedom to > proliferate. It is > my opinion that we need to rein in the RRULE syntax, and > adopt a subset; but, > even if we wind up supporting both the subset and the current > full syntax, I > would not want to use a generic mechanism that would let > people add more in the > future. > Agree with John about the need for some "interop subsets" of RRULE features. It is a powerful syntax, but as such is also difficult to find interop between implementations. From owner-ietf-calendar@mail.imc.org Mon Mar 12 13:18:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15927 for ; Mon, 12 Mar 2001 13:18:01 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA25702 for ietf-calendar-bks; Mon, 12 Mar 2001 09:58:11 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA25698 for ; Mon, 12 Mar 2001 09:58:10 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA10259 for ; Mon, 12 Mar 2001 11:56:19 -0600 From: "Shannon J. Clark" To: Subject: RE: CALSCH Agenda for IETF 50 Date: Mon, 12 Mar 2001 11:57:35 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <30F2DED23724D311902D0008C7EABAFB0361FC3D@daeis06nok> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit What I was trying to suggest is not to make reoccurrence rules proliferate more freely - but to suggest that it may in fact best be considered separately from the rest of the standards. We have already had some suggestions from various participants about additional uses/issues around reoccurrence rules, additionally they already make up a seemingly separate set from the rest of the standard - the "full" syntax is incredibly dense and complex. There are also many contexts where having a clear means of defining in a standardized way the reoccurrence of events would be useful - areas which may or may not incorporate the rest of the CALSCH standards. For example - websites displaying information about reoccurring events - may not be using an iCalendar based system to display it, but rather than developing a fully proprietary means of calculating reoccurrences reusing the standard would save significant development time and effort - and facilitate the eventual movement to an iCalendar based solution. I cite this from the EXACT case of a client of my company - presently they plan on using an extracted version of the reoccurrence rules and expect that this will save many weeks of development time resulting in a much lower cost of implementation for their web based applications. Also, just within the context of the standard, there have been proposals to extend WHERE reoccurrence rules can be employed - some of the suggestions from the SKiCal group have included this. Anyway - I guess my main point is that the reoccurrence rules, and the syntax for them, seem to me to be a separate potential standard from the base iCalendar standard - as such it seems useful to separate them from the main standard document and incorporate them by reference - not by embedding the definition of the one standard into the other. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Frank.Dawson@nokia.com Sent: Monday, March 12, 2001 10:53 AM To: francis@ecal.com; ietf-calendar@imc.org Subject: RE: CALSCH Agenda for IETF 50 > > I propose the following - one, the reoccurrence sections - > both the simple > > and the "full" be pulled OUT and turned into a generalized > system for > > reoccurrence rules. > > Very bad idea. Recurrence rule syntaxes are nasty, twisted > little beasties; > the last thing we want to do is grant them more freedom to > proliferate. It is > my opinion that we need to rein in the RRULE syntax, and > adopt a subset; but, > even if we wind up supporting both the subset and the current > full syntax, I > would not want to use a generic mechanism that would let > people add more in the > future. > Agree with John about the need for some "interop subsets" of RRULE features. It is a powerful syntax, but as such is also difficult to find interop between implementations. From owner-ietf-calendar@mail.imc.org Mon Mar 12 13:29:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16279 for ; Mon, 12 Mar 2001 13:29:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA25857 for ietf-calendar-bks; Mon, 12 Mar 2001 10:04:19 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA25853 for ; Mon, 12 Mar 2001 10:04:18 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2CI3m902357 for ; Mon, 12 Mar 2001 10:03:49 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GA3JI300.8DT; Mon, 12 Mar 2001 10:03:40 -0800 Message-ID: <3AAD0F66.2BCFF6C2@netscape.com> Date: Mon, 12 Mar 2001 10:03:18 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Shannon J. Clark" CC: ietf-calendar@imc.org Subject: Re: CALSCH Agenda for IETF 50 References: Content-Type: multipart/mixed; boundary="------------445FBC906C9845DEB605FD85" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------445FBC906C9845DEB605FD85 Content-Type: multipart/alternative; boundary="------------191A3ECC496880B34B680456" --------------191A3ECC496880B34B680456 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shannon, Thanks for the feedback. Comments below "Shannon J. Clark" wrote: > One - the documents were already too long, and every new version of them has > only gotten longer - see the CAP proposed standard for a great example of > this. I feel the same. The latest version of CAP (04) has actually gotten shorter than the previous version. It's still long. What would *really* be helpful is to suggest how we might further shorten the draft. > Two - while the documents as written serve a useful purpose of having both > human readable and machine parseable sections (the ABNF stuff) - this also > serves to greatly lengthen the documents, yep. > and has frequently been a source > of errors cropping up the documentation - where the text and the ABNF > examples differ. yes. Still, I think those examples are really important. However, the ABNF and the examples should always be consistent. Careful as the editors might be, errors show up. We can use help in making them consistent. > Three - the documents are very erratic about language usage which serves to > confuse the reader - especially around deciding which sections represent > components that are MANDATORY to implement and which are truly OPTIONAL. I agree that having too many "optional" or "should" features lengthens the document. More important, whether a feature is "must" or "should", if it appears in the RFC, then we have to spend as much as necessary to get it right. This takes a lot of time --especially on the should features because there is usually a long debate about whether it is "should" or "must". If nobody is going to implement a "should" feature, or if only one or two vendors *might* implement it, then I would push for removing it altogether from first version of CAP. We can address the "should" issues in a seperate or follow-on draft. Let me be clear on this point. I'm not trying to say that many of the "should" features are not worth pursuing. But we don't need to get to *everything* in the first version of CAP. The "crawl, walk run" approach is probably a good one for CAP. The "must" features alone add up to a pretty complicated draft. I'd rather see us focus on those, and maybe even lose some of the "must" features, in order to make it easier for vendors to do an implementation. Then follow-up with the should features in future drafts. > Four - the various interlocking documents and standards do not have a clear > sense of the PURPOSE and PLAN behind the various standards and proposed > standards - why do we have multiple proposed standards for realtime/live > interactions with a calendar server (CAP and iRip etc) More fundamentally > there is lacking a clear sense of HOW the various standards will in fact be > deployed. I think we've done a reasonable job. Here's the way I see it: * iCalendar - data and schema definition * iTIP / iMIP - interoperability protocol * CAP - calendar client-server protocol There is no IRIP. We use iTIP to interact with disjoint systems. Use CAP to connect clients to a server within an organization. Could you articulate where your concern or confusion lies? > Five - Most glaringly some of the MAJOR software products on the market seem > to define the use of the iCalendar standard very differently than the > standards documents imply - the case of MS Outlook is what I am citing here. iPlanet's calendar server does interoperate with Microsoft's Exchange server through iMIP and to some extent with Lotus. I know that Lotus' calendar product can interoperate with iPlanet's and Microsoft's products. It's not perfect, yet. Will JigZaw be at the CalConnect? That's another place to really drive the point home. The product developers will be there. Test your interactions with other companies. Point out the problems. > Six - There is preponderance of sections to the various documents which > address the problem set of Scheduling meetings between individuals - whether > using the same basic calendaring service or whether using multiple vendor's > systems. This is fine - but it is NOT the same problem set as the general > question of the storage and communication of time-related information. My > company's products have nearly nothing at all to do with scheduling of > meetings - all of the sections of the various standards that involve > FREE/BUSY time, attendees, delegates, invitations, organizers, etc are > mostly meaningless in the context of what our applications do. We are > interested in the standards for a standard means of storing and > interchanging complex time-related information - our software harvests this > information from a large variety of sources, stores it, sorts it, and > otherwise manipulates it for our end users - in a fully standards compliant > world I would like to be able to interchange information from my systems to > the systems employed by the various firms for whom we provide services. > > So, for my purposes the large sections of the various standards that deal > with scheduling are an impediment for my development purposes. We just have to be careful here. Of course we want the standards to cover everything. But this is part of the reason we have the bloat in the documents that you're concerned with. It's also part of the reason we've been on CAP for a couple of years, and why it took a few years to get iCalendar to RFC status. If there's a whole new area we need to cover, CAP and potentially iCalendar will become bigger. If we come out with the perfect specification, that addresses every calendaring need, but people don't implement it because it's too much or too complicated, then we've all lost. It would be great if you could make it to the Minneapolis meeting to discuss where the shortcomings are and what it would take to make the standards more relevant for your product. Perhaps there's another way to go about getting what you need (something other than tying it to CAP). But I do believe we are addressing the needs of many vendors. > Seven - there are some sections of various standards that might be best > pulled OUT of the current standards and made into their own standards. This > would simplify the documents considerably, and would also refine reusability > of these elements. > > I propose the following - one, the reoccurrence sections - both the simple > and the "full" be pulled OUT and turned into a generalized system for > reoccurrence rules. This would greatly simplify the standards, and would > allow the reoccurrence rules to be applied in a greater variety of means > than currently considered. > > Two - The working group strongly consider whether CALENDARING - that is the > STORAGE of time-related information (Events or ToDo's in particular) be > separated in the standards from SCHEDULING - which is the subset of events > that have the characteristics of a business meeting (Organizer, attendees, a > need for Free/Busy checking, locations, delegates, etc.) much of the CAP document that may have led people to believe that we were proposing how data should be stored has been pulled from the doc. The intent was not to tell people how to store the data, it was to provide schema information for the new components so that we could develop a query capability for the protocol. The schema definitions will be moved into iCalendar, which is more appropriate. But CAP will not specify how implementors store their data. > Three - The group consider strongly HOW the various standards will in fact > be employed in the "real world" - will they be used to exchange information > about ONE event at a time (ala vCalendar), to exchange complex calendars > (how I thought iCalendar was intended to be used), to allow for > interoperability between scheduling systems?, or to provide a generalized > framework for applications that have to deal with TIME RELATED issues to > handle the storage, electronic definition, and communication of those issues > to other applications? this last framework question is a slippery slope. We have our hands full with just the calendaring and scheduling we're dealing with today. If, as you say, what we're producing is not relevant to your needs, wouldn't a standard that addressed them become even bigger and more complicated? I don't know, I'm just asking. I do have some ideas on what we might do to simplify CAP. But even if those are accepted by the group, we will still have a pretty complex draft. > Will we ever in fact address such a server by way of > a cal://URL or will these systems primarily be addressed in a secondary > manner - i.e. hidden by a more common addressing scheme such as HTTP? It is certainly my goal to see that cap://bla becomes a common way to access calendar information. I think everyone in this working group would want this. > Hope this was not too long for people to read through and pick our my > questions, I will be very curious to hear what is decided at the meeting. > Great feedback! Please don't let everyone else decide. You obviously have some energy on this. We need more energy in this working group. Help us. -Steve --------------191A3ECC496880B34B680456 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Shannon,

Thanks for the feedback.  Comments below

"Shannon J. Clark" wrote:

One - the documents were already too long, and every new version of them has
only gotten longer - see the CAP proposed standard for a great example of
this.
I feel the same. The latest version of CAP (04) has actually gotten shorter than the previous version. It's still long. What would *really* be helpful is to suggest how we might further shorten the draft.
Two - while the documents as written serve a useful purpose of having both
human readable and machine parseable sections (the ABNF stuff) - this also
serves to greatly lengthen the documents,
yep.
and has frequently been a source
of errors cropping up the documentation - where the text and the ABNF
examples differ.
yes. Still, I think those examples are really important. However, the ABNF and the examples should always be consistent. Careful as the editors might be, errors show up. We can use help in making them consistent.
Three - the documents are very erratic about language usage which serves to
confuse the reader - especially around deciding which sections represent
components that are MANDATORY to implement and which are truly OPTIONAL.
I agree that having too many "optional" or "should" features lengthens the document. More important, whether a feature is "must" or "should", if it appears in the RFC, then we have to spend as much as necessary to get it right. This takes a lot of time --especially on the should features because there is usually a long debate about whether it is "should" or "must". If nobody is going to implement a "should" feature, or if only one or two vendors *might* implement it, then I would push for removing it altogether from first version of CAP. We can address the "should" issues in a seperate or follow-on draft.

Let me be clear on this point. I'm not trying to say that many of the "should" features are not worth pursuing. But we don't need to get to *everything* in the first version of CAP. The "crawl, walk run" approach is probably a good one for CAP. The "must" features alone add up to a pretty complicated draft. I'd rather see us focus on those, and maybe even lose some of the "must" features, in order to make it easier for vendors to do an implementation. Then follow-up with the should features in future drafts.

Four - the various interlocking documents and standards do not have a clear
sense of the PURPOSE and PLAN behind the various standards and proposed
standards - why do we have multiple proposed standards for realtime/live
interactions with a calendar server (CAP and iRip etc) More fundamentally
there is lacking a clear sense of HOW the various standards will in fact be
deployed.
I think we've done a reasonable job.  Here's the way I see it:
  • iCalendar - data and schema definition
  • iTIP / iMIP - interoperability protocol
  • CAP - calendar client-server protocol
There is no IRIP.   We use iTIP to interact with disjoint systems.  Use CAP to connect clients to a server within an organization.

Could you articulate where your concern or confusion lies?

Five - Most glaringly some of the MAJOR software products on the market seem
to define the use of the iCalendar standard very differently than the
standards documents imply - the case of MS Outlook is what I am citing here.
iPlanet's calendar server does interoperate with Microsoft's Exchange server through iMIP and to some extent with Lotus. I know that Lotus' calendar product can interoperate with iPlanet's and Microsoft's products.  It's not perfect, yet.

Will JigZaw be at the CalConnect?  That's another place to really drive the point home. The product developers will be there. Test your interactions with other companies. Point out the problems.

Six - There is preponderance of sections to the various documents which
address the problem set of Scheduling meetings between individuals - whether
using the same basic calendaring service or whether using multiple vendor's
systems. This is fine - but it is NOT the same problem set as the general
question of the storage and communication of time-related information. My
company's products have nearly nothing at all to do with scheduling of
meetings - all of the sections of the various standards that involve
FREE/BUSY time, attendees, delegates, invitations, organizers, etc are
mostly meaningless in the context of what our applications do. We are
interested in the standards for a standard means of storing and
interchanging complex time-related information - our software harvests this
information from a large variety of sources, stores it, sorts it, and
otherwise manipulates it for our end users - in a fully standards compliant
world I would like to be able to interchange information from my systems to
the systems employed by the various firms for whom we provide services.

So, for my purposes the large sections of the various standards that deal
with scheduling are an impediment for my development purposes.

We just have to be careful here. Of course we want the standards to cover everything. But this is part of the reason we have the bloat in the documents that you're concerned with. It's also part of the reason we've been on CAP for a couple of years, and why it took a few years to get iCalendar to RFC status. If there's a whole new area we need to cover, CAP and potentially iCalendar will become bigger. If we come out with the perfect specification, that addresses every calendaring need, but people don't implement it because it's too much or too complicated, then we've all lost. It would be great if you could make it to the Minneapolis meeting to discuss where the shortcomings are and what it would take to make the standards more relevant for your product. Perhaps there's another way to go about getting what you need (something other than tying it to CAP).

 But I do believe we are addressing the needs of many vendors.

Seven - there are some sections of various standards that might be best
pulled OUT of the current standards and made into their own standards. This
would simplify the documents considerably, and would also refine reusability
of these elements.

I propose the following - one, the reoccurrence sections - both the simple
and the "full" be pulled OUT and turned into a generalized system for
reoccurrence rules. This would greatly simplify the standards, and would
allow the reoccurrence rules to be applied in a greater variety of means
than currently considered.

Two - The working group strongly consider whether CALENDARING - that is the
STORAGE of time-related information (Events or ToDo's in particular) be
separated in the standards from SCHEDULING - which is the subset of events
that have the characteristics of a business meeting (Organizer, attendees, a
need for Free/Busy checking, locations, delegates, etc.)

much of the CAP document that may have led people to believe that we were proposing how data should be stored has been pulled from the doc. The intent was not to tell people how to store the data, it was to provide schema information for the new components so that we could develop a query capability for the protocol.  The schema definitions will be moved into iCalendar, which is more appropriate. But CAP will not specify how implementors store their data.
Three - The group consider strongly HOW the various standards will in fact
be employed in the "real world" - will they be used to exchange information
about ONE event at a time (ala vCalendar), to exchange complex calendars
(how I thought iCalendar was intended to be used), to allow for
interoperability between scheduling systems?, or to provide a generalized
framework for applications that have to deal with TIME RELATED issues to
handle the storage, electronic definition, and communication of those issues
to other applications?
this last framework question is a slippery slope. We have our hands full with just the calendaring and scheduling we're dealing with today. If, as you say, what we're producing is not relevant to your needs, wouldn't a standard that addressed them become even bigger and more complicated?  I don't know, I'm just asking.  I do have some ideas on what we might do to simplify CAP. But even if those are accepted by the group, we will still have a pretty complex draft.
Will we ever in fact address such a server by way of
a cal://URL or will these systems primarily be addressed in a secondary
manner - i.e. hidden by a more common addressing scheme such as HTTP?
It is certainly my goal to see that cap://bla becomes a common way to access calendar information. I think everyone in this working group would want this.
Hope this was not too long for people to read through and pick our my
questions, I will be very curious to hear what is decided at the meeting.
 
Great feedback!   Please don't let everyone else decide. You obviously have some energy on this. We need more energy in this working group.  Help us.

-Steve --------------191A3ECC496880B34B680456-- --------------445FBC906C9845DEB605FD85 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------445FBC906C9845DEB605FD85-- From owner-ietf-calendar@mail.imc.org Mon Mar 12 13:51:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16706 for ; Mon, 12 Mar 2001 13:51:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA26426 for ietf-calendar-bks; Mon, 12 Mar 2001 10:32:27 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA26422 for ; Mon, 12 Mar 2001 10:32:25 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2CIcrQ31887 for ; Mon, 12 Mar 2001 13:38:53 -0500 Message-ID: <3AAD17BD.EB49B2F0@ecal.com> Date: Mon, 12 Mar 2001 13:38:53 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CALSCH Agenda for IETF 50 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > We have already had some suggestions from various participants about > additional uses/issues around reoccurrence rules, additionally they already > make up a seemingly separate set from the rest of the standard - the "full" > syntax is incredibly dense and complex. This is a separate issue; I'm working on a Draft to suggest a subset, based on the work done in CPL. But it is not useful to have iCalendar with its recurrence rules; nor is it useful (as far as interop is concerned) to have iCalendar's recurrence rules without the rest of iCalendar. > I cite this > from the EXACT case of a client of my company - presently they plan on using > an extracted version of the reoccurrence rules and expect that this will > save many weeks of development time resulting in a much lower cost of > implementation for their web based applications. Well, but this working group is not here to lower your client's cost of implementation; we are here to promote interop, so that users can exchange data regardless of vendor. From what you say, your client is not doing that; they're taking the rrule syntax and using it in a proprietary data format, which maintains vendor lock-in. Some may consider it gratifying that the rrule syntax turned out to be useful outside its original domain; but that's not an argument for spending the working group's time on making it easier to extract. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |If you choke a Smurf, what color does it turn?| |francis@ecal.com| | \===============================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 12 14:05:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17083 for ; Mon, 12 Mar 2001 14:05:06 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA26662 for ietf-calendar-bks; Mon, 12 Mar 2001 10:43:07 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA26658 for ; Mon, 12 Mar 2001 10:43:06 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2CIngQ31930 for ; Mon, 12 Mar 2001 13:49:42 -0500 Message-ID: <3AAD1A46.67873949@ecal.com> Date: Mon, 12 Mar 2001 13:49:42 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CALSCH Agenda for IETF 50 References: <3AAD0F66.2BCFF6C2@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Mansour wrote: >> One - the documents were already too long, and every new >> version of them has >> only gotten longer - see the CAP proposed standard for a >> great example of >> this. > > I feel the same. The latest version of CAP (04) has actually > gotten shorter than the previous version. It's still long. What > would *really* be helpful is to suggest how we might further > shorten the draft. One approach that might help would be to split it up into transport and messages: define, say, tiCAP (transport-independent CAP) as the set of iCalendar messages exchanged and CATP (Calendar Access Transport Protocol) as the transport protocol they run over. Then both documents would be shorter and easier to read; and we could run tiCAP over other transports. (For example, tiCAP over SMS could be useful for CUAs running on cellphones.) It'd be a nice bit of orthogonality. tiCAP would not explicitly contain any iTIP functionality. Instead, iTIP running over CATP would be CRISP; (iTIP+tiCAP) over CATP would be CAP; (iTIP+tiCAP) over email would be a superset of iMIP; tiCAP over CATP would be SOGGY. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |This space intentionally not left blank. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 12 15:55:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19938 for ; Mon, 12 Mar 2001 15:55:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA28954 for ietf-calendar-bks; Mon, 12 Mar 2001 12:35:12 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA28950 for ; Mon, 12 Mar 2001 12:35:10 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA10512 for ; Mon, 12 Mar 2001 14:33:17 -0600 From: "Shannon J. Clark" To: Subject: Interoperability and reoccurrence rules (was Re: CALSCH Agenda for IETF 50) Date: Mon, 12 Mar 2001 14:34:36 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3AAD17BD.EB49B2F0@ecal.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Guess this raises a question as far as interop goes. I am strongly recommending to my client that they use the rrule syntax to PROMOTE eventual interoperability of the solutions they are having created for them so that as they move forward they are not locked into a proprietary solution - rather they can become an ideal client for standards compliant calendaring software, albeit not calendaring software that is concerned with the scheduling of people, but calendaring software that is concerned with conveying timed information to a user population (in this case it is not public information ala SKiCal but personalized for an individual but not scheduled with other people). By employing the rrules directly within their underlying databases and custom written applications they will greatly facilitate the use of their information within standards compliant applications. Thus, I would consider that this use of the rrules to be very much promoting interoperability, in this case not between different vendors of calendaring applications, but in terms of helping encourage end user behaviors that help show the value of interoperability. My client is not interested in writing software, rather they have information that they are in the business of sharing with their customers - they want to do this for the widest possible audience, in a manner that will work going forward, and in a way that reduces their costs and helps them avoid being locked into a proprietary solution. By employing the rrules syntax they greatly facilitate converting their information into native iCalendar information, and from there in theory they can achieve interop with a wide array of other systems. I would be curious to hear from others who are working with customers to see if my conversation with this client was unique or something encountered by many people - when we are defining interoperability it will only be adopted by vendors if it provides value to clients and helps drive adoption and usage of our products - from a vendor's perspective there is a great deal of value to proprietary processes - they can ensure reoccurring revenues and client lockin - to push for interoperability there has to be compelling client driven demands for the value of it. In my client's case it is to be able to serve the widest possible universe of end users - they do not want to force technical decisions on their end users, if in the process they also save themselves time and money so much the better. Also, I assume you meant to say "If is not useful to have iCalendar withOUT its recurrence rules" (your original had "with"). I'm not convinced that this is so - looking both at the majority of the examples in the documentation, and in many of the areas that calendars are used for, reoccurring events are by no means the majority of the events handled by calendaring systems - thus it is quite possible for real usage of a calendaring system to rarely if ever use reoccurrence rules. That said, reoccurrence is a very important feature in many situations, it serves to define a very common situation, and may have some technical advantages over storing multiple entries. It also has some technical limitations (such as the issue of how computationally difficult it is to resolve the rrules in a quick manner). Reoccurrence is also an area prone to lots of issues surrounding interoperability - how each system handles exceptions, whether or not the systems allow for a single instance of a reoccurring event to be modified (for example a regularly reoccurring meeting - for each specific instance attaching the current agenda might be a highly desirable action) or the case of deleting one instance of the series. We are also looking at the various types of reoccurrences that might be desirable to allow users to use - the current standards have many more possibilities that it has been said is feasible to display in a user interface. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Monday, March 12, 2001 12:39 PM To: ietf-calendar@imc.org Subject: Re: CALSCH Agenda for IETF 50 "Shannon J. Clark" wrote: > We have already had some suggestions from various participants about > additional uses/issues around reoccurrence rules, additionally they already > make up a seemingly separate set from the rest of the standard - the "full" > syntax is incredibly dense and complex. This is a separate issue; I'm working on a Draft to suggest a subset, based on the work done in CPL. But it is not useful to have iCalendar with its recurrence rules; nor is it useful (as far as interop is concerned) to have iCalendar's recurrence rules without the rest of iCalendar. > I cite this > from the EXACT case of a client of my company - presently they plan on using > an extracted version of the reoccurrence rules and expect that this will > save many weeks of development time resulting in a much lower cost of > implementation for their web based applications. Well, but this working group is not here to lower your client's cost of implementation; we are here to promote interop, so that users can exchange data regardless of vendor. From what you say, your client is not doing that; they're taking the rrule syntax and using it in a proprietary data format, which maintains vendor lock-in. Some may consider it gratifying that the rrule syntax turned out to be useful outside its original domain; but that's not an argument for spending the working group's time on making it easier to extract. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |If you choke a Smurf, what color does it turn?| |francis@ecal.com| | \===============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 13 10:28:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21888 for ; Tue, 13 Mar 2001 10:28:58 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA09803 for ietf-calendar-bks; Tue, 13 Mar 2001 07:09:07 -0800 (PST) Received: from relay.wineasy.se (smtp.wineasy.se [195.42.198.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA09798 for ; Tue, 13 Mar 2001 07:09:04 -0800 (PST) Received: from metamatrix.se (IDENT:pbb@dublin.metamatrix.se [213.88.195.121]) by relay.wineasy.se with ESMTP id f2DF94P06063 for ; Tue, 13 Mar 2001 16:09:04 +0100 Message-ID: <3AAE3814.19C56EA9@metamatrix.se> Date: Tue, 13 Mar 2001 16:09:08 +0100 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: SKICal CONTROL Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA09803 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA21888 The ORGANIZER of a VEVENT is not always the organizer of the corresponding real life event. If I publish an event (or more generally, a "SKiSource") and want to indicate what organization/person is legally responsible for the event, or what organizations are sponsors of the event, or other such roles which are important in event directories, I cannot use ORGANIZER. Yet there is a need for this information to be included in a controlled manner (that is, not as easy-to-forget free text notes in DESCRIPTION) for many SKICal user groups. The following property ("CONTROL") is intended to meet this need. I believe it is a good idea if this property replaces RESPONSIBLE, ASSOCIATION and OTHERAGENTS in earlier SKICal specifications. It greatly reduces the complexity of the specification. Comments welcome! -From the current SKICal draft---------------------------------------- Property Name: CONTROL Purpose: This property indicates responsibilities, jurisdictions, ownership, and other formal or informal relationships for parties involved in the SKiSource. Value Type: TEXT. (MAILTO) Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: To declare relationships, responsibilities and liabilities of formal, informal, or contractual nature amongst parties involved in a SKiSource or particular aspects of a SKiSource. The CONTROL property is used to define these responsibilities and jurisdictions. Format Definition: The property is defined by the following notation: control = "CONTROL" controlparam ":" uri CRLF ; the value MAY be a MAILTO URI, as defined ; by RFC-1738[4]. controlparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparam ) / (";" cnparam ) / (";" skiroleparam) ; It is highly RECOMMENDED that SKICal objects actually ; use the cnparam since some applications will not ; bother to read the altrep'ed vCard. ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: CONTROL;SKiROLE=producer;CN=Nobelkommitten:MAILTO:info@nobel.se CONTROL;SKiROLE=producer;CN=Opera house:MAILTO:info@opera.de CONTROL;SKiROLE=responsible;MAILTO:jean-marie@petiteville.fr CONTROL;SKiROLE=contracting agency:MAILTO:info@ematelstar.se CONTROL;SKiROLE=sponsor;CN=Stockholms stad:MAILTO:kultur@stadshuset. a.se CONTROL;SKiROLE=in association with;CN=Svenska Turistforbundet:MAILT O:info@stf.se CONTROL;SKiROLE=responsible-is-member-of;CN=Rotary international:MAI LTO:rotary@rotary.org -------------------------------------------------------------------------- /Pär From owner-ietf-calendar@mail.imc.org Tue Mar 13 11:03:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22468 for ; Tue, 13 Mar 2001 11:03:23 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA15248 for ietf-calendar-bks; Tue, 13 Mar 2001 07:47:10 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA15243 for ; Tue, 13 Mar 2001 07:47:08 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2DFri302220 for ; Tue, 13 Mar 2001 10:53:44 -0500 Message-ID: <3AAE4287.9A0310EE@ecal.com> Date: Tue, 13 Mar 2001 10:53:44 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKICal CONTROL References: <3AAE3814.19C56EA9@metamatrix.se> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA15248 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA22468 Pär Lannerö wrote: > The following property ("CONTROL") is intended to meet this need. > I believe it is a good idea if this property replaces RESPONSIBLE, > ASSOCIATION and OTHERAGENTS in earlier SKICal specifications. It greatly > reduces the complexity of the specification. > > Comments welcome! Looks good to me. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |I used to belong to a solipsism club, but I got| |francis@ecal.com|bored & voted everybody else out. | \================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 13 11:06:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22504 for ; Tue, 13 Mar 2001 11:06:10 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA15638 for ietf-calendar-bks; Tue, 13 Mar 2001 07:53:27 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA15634 for ; Tue, 13 Mar 2001 07:53:25 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2DG03302265 for ; Tue, 13 Mar 2001 11:00:03 -0500 Message-ID: <3AAE4403.519B44C2@ecal.com> Date: Tue, 13 Mar 2001 11:00:03 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Interoperability and reoccurrence rules (was Re: CALSCH Agenda for IETF 50) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > By employing the rrules syntax they greatly facilitate converting > their information into native iCalendar information, So why don't they just use native iCalendar? Why are they taking on the trouble of implementing iCalendar rrules (the most complicated part) and not going the rest of the way? > Also, I assume you meant to say "If is not useful to have iCalendar withOUT > its recurrence rules" (your original had "with"). Yes, sorry. > I'm not convinced that > this is so - looking both at the majority of the examples in the > documentation, and in many of the areas that calendars are used for, > reoccurring events are by no means the majority of the events handled by No, but the recurrence rules are iCalendar's largest value-add; the rest of it is pretty standard stuff that would be easy to work out on your own. > calendaring systems - thus it is quite possible for real usage of a > calendaring system to rarely if ever use reoccurrence rules. This does not follow. For example, recurring events make up only a small fraction of the distinct events on my calendar; but that doesn't mean I rarely use recurrence rules. In fact, *instances* of recurring events make up the majority of the instances of events on my calendar. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |If God had meant us to be in the Army, we | |francis@ecal.com|would've been born with green, baggy skin. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 13 12:00:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23657 for ; Tue, 13 Mar 2001 12:00:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA19338 for ietf-calendar-bks; Tue, 13 Mar 2001 08:48:41 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA19334 for ; Tue, 13 Mar 2001 08:48:40 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2DGmgg10890 for ; Tue, 13 Mar 2001 10:48:42 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 13 Mar 2001 10:48:36 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Tue, 13 Mar 2001 10:48:36 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB03F3468F@daeis06nok> To: par.lannero@metamatrix.se, ietf-calendar@imc.org Subject: RE: SKICal CONTROL Date: Tue, 13 Mar 2001 10:48:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Subject: SKICal CONTROL > > > The ORGANIZER of a VEVENT is not always the organizer of the > corresponding real life event. > > If I publish an event (or more generally, a "SKiSource") and want to > indicate what organization/person is legally responsible for > the event, > or what organizations are sponsors of the event, or other such roles > which are important in event directories, I cannot use ORGANIZER. Is this just informational or is there some scheduling workflow requirement for this "CONTROL" information? Is there some requirement/description beyond specifying the individual that is "legally responsible" for the event? I am also not certain what "legally responsible" actually means compared with the semantics for ORGANIZER, which is the person responsible for scheduling the event. This semantic interaction needs some clarification. Maybe scenarios would help? > The following property ("CONTROL") is intended to meet this need. > I believe it is a good idea if this property replaces RESPONSIBLE, > ASSOCIATION and OTHERAGENTS in earlier SKICal specifications. Simple sounds good! > Purpose: This property indicates responsibilities, jurisdictions, > ownership, and other formal or informal relationships for parties > involved in the SKiSource. > > Value Type: TEXT. (MAILTO) > > Property Parameters: Non-standard property parameters can be > specified on this property. > > Conformance: This property CAN be specified within a "VEVENT" > calendar component. > > Description: To declare relationships, responsibilities and > liabilities of formal, informal, or contractual nature amongst > parties involved in a SKiSource or particular aspects of a > SKiSource. The CONTROL property is used to define these > responsibilities and jurisdictions. > > Format Definition: The property is defined by the > following notation: > > control = "CONTROL" controlparam ":" uri CRLF > > ; the value MAY be a MAILTO URI, as defined > ; by RFC-1738[4]. > Can the value be anything other than a MAILTO URI? If not, then shouldn't this be a MUST rather than a MAY? How many times can this property appear in a VEVENT? If more than once, what does this mean? > controlparam = *( > ; the following is optional, > ; but MUST NOT occur more than once > (";" languageparam ) / (";" cnparam ) / (";" skiroleparam) > > ; It is highly RECOMMENDED that SKICal objects actually > ; use the cnparam since some applications will not > ; bother to read the altrep'ed vCard. > > ; the following is optional, > ; and MAY occur more than once > > (";" xparam) > ) > > Example: The following are examples of this property: > > CONTROL;SKiROLE=producer;CN=Nobelkommitten:MAILTO:info@nobel.se > CONTROL;SKiROLE=producer;CN=Opera house:MAILTO:info@opera.de > CONTROL;SKiROLE=responsible;MAILTO:jean-marie@petiteville.fr > CONTROL;SKiROLE=contracting agency:MAILTO:info@ematelstar.se > CONTROL;SKiROLE=sponsor;CN=Stockholms > stad:MAILTO:kultur@stadshuset. > a.se > CONTROL;SKiROLE=in association with;CN=Svenska > Turistforbundet:MAILT > O:info@stf.se > CONTROL;SKiROLE=responsible-is-member-of;CN=Rotary > international:MAI > LTO:rotary@rotary.org > There are some errors in the examples. SEMICOLON appears where a COLON ought to be. -- Frank From owner-ietf-calendar@mail.imc.org Tue Mar 13 12:00:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23684 for ; Tue, 13 Mar 2001 12:00:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA19254 for ietf-calendar-bks; Tue, 13 Mar 2001 08:45:40 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA19248 for ; Tue, 13 Mar 2001 08:45:38 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id KAA12017 for ; Tue, 13 Mar 2001 10:43:22 -0600 From: "Shannon J. Clark" To: Subject: RE: SKICal CONTROL Date: Tue, 13 Mar 2001 10:44:43 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <3AAE3814.19C56EA9@metamatrix.se> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id IAA19254 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA23684 This raises a question that has been bothering me for a while. How should "ORGANIZER" be handled for the possibly large number of events for which it hold no meaning? Examples: Holidays; public events; tax-filing deadlines; etc. In the context of events, such as holidays, shared by all the users of a given calendar system (probably by way of user groups and a group calendar) - the concept of ORGANIZER and for that matter ATTENDEE are counterproductive and likely confusing if displayed or revealed to an end user. CONTROL seems like a possible step in the right direction. A few specific questions about CONTROL. Where are the possible set for the SKiROLE parameter's set? Is it possible to use anything here? Or is there a limited set being proposed? If the SKiROLE's are intended to be mapped to a programmed response (perhaps a way of being displayed etc) then a limited set is desirable. A second point - are CONTROL's intended to be mapped to a USER (however loosely defined) within the calendar store, or are they intended to be referencing an external agency with no other connection to the calendar store (and therefore no requirement of any validation/security on the USER id etc.) A third point - from the examples it is implied - but never clearly stated - that there may be multiple CONTROL properties for a given vEvent. A fourth point - is control only intended for vEvents? Or is it suggested for other vObjects such as vTodo's? (so a vToDO for "File your US Taxes" might have a CONTROL of the IRS? Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Pär Lannerö Sent: Tuesday, March 13, 2001 9:09 AM To: ietf-calendar@imc.org Subject: SKICal CONTROL The ORGANIZER of a VEVENT is not always the organizer of the corresponding real life event. If I publish an event (or more generally, a "SKiSource") and want to indicate what organization/person is legally responsible for the event, or what organizations are sponsors of the event, or other such roles which are important in event directories, I cannot use ORGANIZER. Yet there is a need for this information to be included in a controlled manner (that is, not as easy-to-forget free text notes in DESCRIPTION) for many SKICal user groups. The following property ("CONTROL") is intended to meet this need. I believe it is a good idea if this property replaces RESPONSIBLE, ASSOCIATION and OTHERAGENTS in earlier SKICal specifications. It greatly reduces the complexity of the specification. Comments welcome! -From the current SKICal draft---------------------------------------- Property Name: CONTROL Purpose: This property indicates responsibilities, jurisdictions, ownership, and other formal or informal relationships for parties involved in the SKiSource. Value Type: TEXT. (MAILTO) Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: To declare relationships, responsibilities and liabilities of formal, informal, or contractual nature amongst parties involved in a SKiSource or particular aspects of a SKiSource. The CONTROL property is used to define these responsibilities and jurisdictions. Format Definition: The property is defined by the following notation: control = "CONTROL" controlparam ":" uri CRLF ; the value MAY be a MAILTO URI, as defined ; by RFC-1738[4]. controlparam = ; the following is optional, ; but MUST NOT occur more than once (";" languageparam ) / (";" cnparam ) / (";" skiroleparam) ; It is highly RECOMMENDED that SKICal objects actually ; use the cnparam since some applications will not ; bother to read the altrep'ed vCard. ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: CONTROL;SKiROLE=producer;CN=Nobelkommitten:MAILTO:info@nobel.se CONTROL;SKiROLE=producer;CN=Opera house:MAILTO:info@opera.de CONTROL;SKiROLE=responsible;MAILTO:jean-marie@petiteville.fr CONTROL;SKiROLE=contracting agency:MAILTO:info@ematelstar.se CONTROL;SKiROLE=sponsor;CN=Stockholms stad:MAILTO:kultur@stadshuset. a.se CONTROL;SKiROLE=in association with;CN=Svenska Turistforbundet:MAILT O:info@stf.se CONTROL;SKiROLE=responsible-is-member-of;CN=Rotary international:MAI LTO:rotary@rotary.org -------------------------------------------------------------------------- /Pär From owner-ietf-calendar@mail.imc.org Tue Mar 13 12:34:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24590 for ; Tue, 13 Mar 2001 12:34:12 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA20271 for ietf-calendar-bks; Tue, 13 Mar 2001 09:20:08 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA20267 for ; Tue, 13 Mar 2001 09:20:03 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2DHK7g16805 for ; Tue, 13 Mar 2001 11:20:07 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 13 Mar 2001 11:20:04 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 13 Mar 2001 11:20:04 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB03F34690@daeis06nok> To: shannon@jigzaw.com, ietf-calendar@imc.org Subject: RE: SKICal CONTROL Date: Tue, 13 Mar 2001 11:19:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > How should "ORGANIZER" be handled for the possibly large > number of events > for which it hold no meaning? Examples: Holidays; public > events; tax-filing > deadlines; etc. The ORGANIZER is the entity that scheduled the event, not necessarily the entity that is responsible for or controls the event. In an enterprise or web calendar environment, some entity is responsible for defining the holiday VEVENT definitions that a subscriber can add to their calendar. This would be the logical entity to addressed by the ORGANIZER property. I think for most of your examples, logical entities can be identified. From owner-ietf-calendar@mail.imc.org Tue Mar 13 15:03:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27406 for ; Tue, 13 Mar 2001 15:03:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA28618 for ietf-calendar-bks; Tue, 13 Mar 2001 11:45:50 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA28608 for ; Tue, 13 Mar 2001 11:45:46 -0800 (PST) Received: from earth.in.steltor.com (earth.int.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA29837; Tue, 13 Mar 2001 14:45:15 -0500 Received: from steltor.com ([101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2DJjFT15734; Tue, 13 Mar 2001 14:45:15 -0500 (EST) Message-ID: <3AAE78BE.84CAD563@steltor.com> Date: Tue, 13 Mar 2001 14:45:02 -0500 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKICal CONTROL References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id LAA28618 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA27406 "Shannon J. Clark" wrote: > > This raises a question that has been bothering me for a while. > > How should "ORGANIZER" be handled for the possibly large number of events > for which it hold no meaning? Examples: Holidays; public events; tax-filing > deadlines; etc. An organizer can still have a meaning. It is the person who created or published the meeting. One may ask questions about a public event to the organizer. Or if there was a mistake in the holiday event, who does one contact? One can use the CONTACT property, but then would one specify CONTACT for a holiday? Thus, who does one contact, the ORGANIZER, the CONTACT, or the CONTROL? Furthermore, who should be contacted depending on which situation? Should ORGANIZER be the default contact if CONTACT or CONTROL are not specified? In context of iTIP, one needs to organizer to be able to know who to send REFRESH and possibly other requests to. > > In the context of events, such as holidays, shared by all the users of a > given calendar system (probably by way of user groups and a group > calendar) - the concept of ORGANIZER and for that matter ATTENDEE are > counterproductive and likely confusing if displayed or revealed to an end > user. The organizer may be useful as I described above. Furthermore, one need not add attendees to an event. If one looks at the publish method in iTIP (one would normally publish a public event or holiday rather than invite people to it), the attendee attribute is not permitted. George > > CONTROL seems like a possible step in the right direction. > > A few specific questions about CONTROL. > > Where are the possible set for the SKiROLE parameter's set? Is it possible > to use anything here? Or is there a limited set being proposed? If the > SKiROLE's are intended to be mapped to a programmed response (perhaps a way > of being displayed etc) then a limited set is desirable. > > A second point - are CONTROL's intended to be mapped to a USER (however > loosely defined) within the calendar store, or are they intended to be > referencing an external agency with no other connection to the calendar > store (and therefore no requirement of any validation/security on the USER > id etc.) > > A third point - from the examples it is implied - but never clearly stated - > that there may be multiple CONTROL properties for a given vEvent. > > A fourth point - is control only intended for vEvents? Or is it suggested > for other vObjects such as vTodo's? (so a vToDO for "File your US Taxes" > might have a CONTROL of the IRS? > > Shannon > > Shannon J. Clark > CEO - JigZaw, Inc > 1.800.4.JIGZAW (454.4929) > shannon@jigzaw.com > www.jigzaw.com > > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Pär Lannerö > Sent: Tuesday, March 13, 2001 9:09 AM > To: ietf-calendar@imc.org > Subject: SKICal CONTROL > > The ORGANIZER of a VEVENT is not always the organizer of the > corresponding real life event. > > If I publish an event (or more generally, a "SKiSource") and want to > indicate what organization/person is legally responsible for the event, > or what organizations are sponsors of the event, or other such roles > which are important in event directories, I cannot use ORGANIZER. > > Yet there is a need for this information to be included in a controlled > manner (that is, not as easy-to-forget free text notes in DESCRIPTION) > for many SKICal user groups. > > The following property ("CONTROL") is intended to meet this need. > I believe it is a good idea if this property replaces RESPONSIBLE, > ASSOCIATION and OTHERAGENTS in earlier SKICal specifications. It greatly > reduces the complexity of the specification. > > Comments welcome! > > -From the current SKICal draft---------------------------------------- > > Property Name: CONTROL > > Purpose: This property indicates responsibilities, jurisdictions, > ownership, and other formal or informal relationships for parties > involved in the SKiSource. > > Value Type: TEXT. (MAILTO) > > Property Parameters: Non-standard property parameters can be > specified on this property. > > Conformance: This property CAN be specified within a "VEVENT" > calendar component. > > Description: To declare relationships, responsibilities and > liabilities of formal, informal, or contractual nature amongst > parties involved in a SKiSource or particular aspects of a > SKiSource. The CONTROL property is used to define these > responsibilities and jurisdictions. > > Format Definition: The property is defined by the following notation: > > control = "CONTROL" controlparam ":" uri CRLF > > ; the value MAY be a MAILTO URI, as defined > ; by RFC-1738[4]. > > controlparam = > > ; the following is optional, > ; but MUST NOT occur more than once > (";" languageparam ) / (";" cnparam ) / (";" skiroleparam) > > ; It is highly RECOMMENDED that SKICal objects actually > ; use the cnparam since some applications will not > ; bother to read the altrep'ed vCard. > > ; the following is optional, > ; and MAY occur more than once > > (";" xparam) > ) > > Example: The following are examples of this property: > > CONTROL;SKiROLE=producer;CN=Nobelkommitten:MAILTO:info@nobel.se > CONTROL;SKiROLE=producer;CN=Opera house:MAILTO:info@opera.de > CONTROL;SKiROLE=responsible;MAILTO:jean-marie@petiteville.fr > CONTROL;SKiROLE=contracting agency:MAILTO:info@ematelstar.se > CONTROL;SKiROLE=sponsor;CN=Stockholms stad:MAILTO:kultur@stadshuset. > a.se > CONTROL;SKiROLE=in association with;CN=Svenska Turistforbundet:MAILT > O:info@stf.se > CONTROL;SKiROLE=responsible-is-member-of;CN=Rotary international:MAI > LTO:rotary@rotary.org > > -------------------------------------------------------------------------- > > /Pär From owner-ietf-calendar@mail.imc.org Tue Mar 13 17:21:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29398 for ; Tue, 13 Mar 2001 17:21:37 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA07450 for ietf-calendar-bks; Tue, 13 Mar 2001 14:03:48 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA07442 for ; Tue, 13 Mar 2001 14:03:46 -0800 (PST) From: Bruce_Kahn@iris.com To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: RE: SKICal CONTROL MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03082001 March 08, 2001 Message-ID: Date: Tue, 13 Mar 2001 17:12:22 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/13/2001 05:08:43 PM, Serialize complete at 03/13/2001 05:08:43 PM Content-Type: multipart/alternative; boundary="=_alternative 00790C1B85256A0E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00790C1B85256A0E_= Content-Type: text/plain; charset="us-ascii" Shannon wrote: > A third point - from the examples it is implied - but never clearly stated - > that there may be multiple CONTROL properties for a given vEvent. Nothing wrong w/that scenario. Ever notice that a real even has > 1 Sponsor? Look as NASCAR, F1 Racing, Sporting Events, etc. Check out the IETF Sponsors list next time you sign up... Your point about clearly stating it though is a very good one. Implicit assumptions are not nice in an interop. spec. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00790C1B85256A0E_= Content-Type: text/html; charset="us-ascii"
Shannon wrote:
> A third point - from the examples it is implied - but never clearly stated -
> that there may be multiple CONTROL properties for a given vEvent.

Nothing wrong w/that scenario.  Ever notice that a real even has > 1 Sponsor?  Look as NASCAR, F1 Racing, Sporting Events, etc.  Check out the IETF Sponsors list next time you sign up...  Your point about clearly stating it though is a very good one.  Implicit assumptions are not nice in an interop. spec.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 00790C1B85256A0E_=-- From owner-ietf-calendar@mail.imc.org Tue Mar 13 20:14:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01345 for ; Tue, 13 Mar 2001 20:14:57 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA18653 for ietf-calendar-bks; Tue, 13 Mar 2001 17:04:03 -0800 (PST) Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA18648 for ; Tue, 13 Mar 2001 17:04:01 -0800 (PST) Received: from modem-30.pajama-cardinal.dialup.pol.co.uk ([62.137.45.158] helo=ximian.com) by cmailg3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14czhs-000303-00 for ietf-calendar@imc.org; Wed, 14 Mar 2001 01:04:04 +0000 Message-ID: <3AAE720F.CC4C1CF8@ximian.com> Date: Tue, 13 Mar 2001 19:16:31 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: VTIMEZONE issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 4.6.5 "Time Zone Component" it says: If specified, the onset for the observance defined by the time zone sub-component is defined by either the "RRULE" or "RDATE" property. If neither is specified, only one sub-component can be specified in the "VTIMEZONE" calendar component and it is assumed that the single observance specified is always in effect. But what is wrong with having just a single DTSTART in the component? It looks like I'll have to duplicate the DTSTART value in an RDATE for no particular reason. Later in section 4.6.5 it says: Alternatively, the "RDATE" property can be used to define the onset of the observance by giving the individual onset date and times. "RDATE" in this usage MUST be specified as a local DATE-TIME value in UTC time. What is a "local DATE-TIME value in UTC time"?? Surely it should either be a local DATE-TIME (like DTSTART must be) or a UTC time (like the RRULE UNTIL values must be). Damon From owner-ietf-calendar@mail.imc.org Tue Mar 13 20:15:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01361 for ; Tue, 13 Mar 2001 20:15:08 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA18649 for ietf-calendar-bks; Tue, 13 Mar 2001 17:04:01 -0800 (PST) Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA18643 for ; Tue, 13 Mar 2001 17:04:00 -0800 (PST) Received: from modem-30.pajama-cardinal.dialup.pol.co.uk ([62.137.45.158] helo=ximian.com) by cmailg3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14czhp-0002zg-00 for ietf-calendar@imc.org; Wed, 14 Mar 2001 01:04:01 +0000 Message-ID: <3AAE6B23.B4594185@ximian.com> Date: Tue, 13 Mar 2001 18:46:59 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Timezone TZID clashes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit What should an application do when it has 2 VTIMEZONE components with conflicting TZIDs? This may happen when an application receives a message from another iCalendar app which uses the same TZIDs, or when an application loads a .ics file it created itself, or that was created by an earlier version of the application. The application should probably try to ensure that the VTIMEZONE associated with a particular event remains the same, or people may turn up to meetings at the wrong time! So it would have to rename one of the TZIDs, and all references to it. For example, if there were 2 VTIMEZONEs with a TZID of "Europe/London", it would rename one of them to something like "Europe/London(2)" as well as the TZID references in the DATE/TIME values which refer to it. (Though this could lead to a slightly confusing interface for users.) We also need a way to check if the 2 VTIMEZONE components are actually the same, so we could avoid the renaming. Currently the only way to do that is to compare every sub-component in the VTIMEZONEs & their properties. It would be better if the VTIMEZONE components had a PRODID property and the LAST-MODIFIED property was made mandatory. We could then compare VTIMEZONES by just comparing the PRODID and LAST-MODIFIED. Ideally, I think the TZID property/parameter should include a product ID and a VTIMEZONE version within the TZID strings, e.g. "Europe/London:libical-3". Then we wouldn't have any problems with conflicts at all. (For libical, my current plan is to name TZIDs like this and then just ignore any TZID conflicts, i.e. the first VTIMEZONE found with that TZID is used. It seems like too much unnecessary effort to resolve conflicts.) Damon From owner-ietf-calendar@mail.imc.org Wed Mar 14 03:34:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20853 for ; Wed, 14 Mar 2001 03:34:40 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id AAA14297 for ietf-calendar-bks; Wed, 14 Mar 2001 00:21:07 -0800 (PST) Received: from web12608.mail.yahoo.com (web12608.mail.yahoo.com [216.136.173.231]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA14281 for ; Wed, 14 Mar 2001 00:21:02 -0800 (PST) Message-ID: <20010314082102.26610.qmail@web12608.mail.yahoo.com> Received: from [195.92.67.67] by web12608.mail.yahoo.com; Wed, 14 Mar 2001 08:21:02 GMT Date: Wed, 14 Mar 2001 08:21:02 +0000 (GMT) From: =?iso-8859-1?q?Andrew=20Proud?= Subject: Lotus Notes To: ietf-calendar@imc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Are there any Lotus Notes (Calendar) users on the list ? If so. Please could you tell me if there is any way of automating the importing of ics or vcs files. I am thinking of the way it works in Outlook. Outlook upon install changes the 'File Types' association, such that when you double-click on an ics file it is automatically imported into your calendar. Failing that can it be done at all ? Many thanks Andy PS MS Outlook does not perform this perfectly as per my earlier posts. ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie From owner-ietf-calendar@mail.imc.org Wed Mar 14 03:49:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20931 for ; Wed, 14 Mar 2001 03:49:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA15792 for ietf-calendar-bks; Wed, 14 Mar 2001 00:36:54 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA15780 for ; Wed, 14 Mar 2001 00:36:49 -0800 (PST) Received: from GregPc (unknown [193.14.119.115]) by ljudo.shortlist.se (Postfix) with SMTP id 6CAC1B3570 for ; Wed, 14 Mar 2001 09:36:46 +0100 (CET) From: "Greg FitzPatrick" To: Subject: SKiCal CONTROL Date: Wed, 14 Mar 2001 09:38:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3AAE78BE.84CAD563@steltor.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id AAA15792 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA20931 A brief semantic review from Greg. The word "Organizer" implies some sort of "control" over an event ("Who's in charge here, anyway?"). But this rather generic term is specifically designated in 2445 to name the controller of an "object of description", the iCal calendar components. This "object of description" may in some cases (but not always) point to an "event" which has it's own "objects of description" for example a Trade Fare. In some formalized way; contracts, rental agreements etc, the organization of the trade fare is constituted. In this formalization, responsible parties are named. As Bruce contributed, there can be quite a few such responsible parties for any given event. We suggest the property CONTROL as a place holder for designating such responsible parties, and we suggest using the parameter SKIROLE to distinguish between their functions. In the event that an EVENT had no other formalized description other than an iCal object, for example a lunch date between George and myself, CONTROL would not be needed, ORGANIZER would signify who was calling for (organizing) the meeting. But in the event our meeting involved interaction with a third party, such as the IETF, (I could be the ORGANIZER of a meeting with George at the IETF) and our meeting was influenced by the organization of the IETF meeting, then it could be important to identify who the responsible parties (controllers) of the IETF meeting are. Frank asks a pertinent question: "Is this just informational or is there some scheduling workflow requirement for this "CONTROL" information? Is there some requirement/description beyond specifying the individual that is "legally responsible" for the event?" Greg: It is informational - until used otherwise. To gain more than information status there should be some constraint on possible values. And as Shannon pointed out, there should be constraint on the SKIROLE values that qualify the CONTROL value. At this stage in SKiCal development it is up to users to apply these constraints. "Shannon J. Clark" wrote: > > This raises a question that has been bothering me for a while. > > How should "ORGANIZER" be handled for the possibly large number of events > for which it hold no meaning? Examples: Holidays; public events; tax-filing > deadlines; etc. George Babics answered: An organizer can still have a meaning. It is the person who created or published the meeting. One may ask questions about a public event to the organizer. Or if there was a mistake in the holiday event, who does one contact? One can use the CONTACT property, but then would one specify CONTACT for a holiday? Thus, who does one contact, the ORGANIZER, the CONTACT, or the CONTROL? Furthermore, who should be contacted depending on which situation? Should ORGANIZER be the default contact if CONTACT or CONTROL are not specified? In context of iTIP, one needs to organizer to be able to know who to send REFRESH and possibly other requests to. > > In the context of events, such as holidays, shared by all the users of a > given calendar system (probably by way of user groups and a group > calendar) - the concept of ORGANIZER and for that matter ATTENDEE are > counterproductive and likely confusing if displayed or revealed to an end > user. The organizer may be useful as I described above. Furthermore, one need not add attendees to an event. If one looks at the publish method in iTIP (one would normally publish a public event or holiday rather than invite people to it), the attendee attribute is not permitted. George > > CONTROL seems like a possible step in the right direction. > > A few specific questions about CONTROL. > > Where are the possible set for the SKiROLE parameter's set? Is it possible > to use anything here? Or is there a limited set being proposed? If the > SKiROLE's are intended to be mapped to a programmed response (perhaps a way > of being displayed etc) then a limited set is desirable. > > A second point - are CONTROL's intended to be mapped to a USER (however > loosely defined) within the calendar store, or are they intended to be > referencing an external agency with no other connection to the calendar > store (and therefore no requirement of any validation/security on the USER > id etc.) > > A third point - from the examples it is implied - but never clearly stated - > that there may be multiple CONTROL properties for a given vEvent. > > A fourth point - is control only intended for vEvents? Or is it suggested > for other vObjects such as vTodo's? (so a vToDO for "File your US Taxes" > might have a CONTROL of the IRS? > > Shannon > > Shannon J. Clark > CEO - JigZaw, Inc > 1.800.4.JIGZAW (454.4929) > shannon@jigzaw.com > www.jigzaw.com > > -----Original Message----- > From: owner-ietf-calendar@mail.imc.org > [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Pär Lannerö > Sent: Tuesday, March 13, 2001 9:09 AM > To: ietf-calendar@imc.org > Subject: SKICal CONTROL > > The ORGANIZER of a VEVENT is not always the organizer of the > corresponding real life event. > > If I publish an event (or more generally, a "SKiSource") and want to > indicate what organization/person is legally responsible for the event, > or what organizations are sponsors of the event, or other such roles > which are important in event directories, I cannot use ORGANIZER. > > Yet there is a need for this information to be included in a controlled > manner (that is, not as easy-to-forget free text notes in DESCRIPTION) > for many SKICal user groups. > > The following property ("CONTROL") is intended to meet this need. > I believe it is a good idea if this property replaces RESPONSIBLE, > ASSOCIATION and OTHERAGENTS in earlier SKICal specifications. It greatly > reduces the complexity of the specification. > > Comments welcome! > > -From the current SKICal draft---------------------------------------- > > Property Name: CONTROL > > Purpose: This property indicates responsibilities, jurisdictions, > ownership, and other formal or informal relationships for parties > involved in the SKiSource. > > Value Type: TEXT. (MAILTO) > > Property Parameters: Non-standard property parameters can be > specified on this property. > > Conformance: This property CAN be specified within a "VEVENT" > calendar component. > > Description: To declare relationships, responsibilities and > liabilities of formal, informal, or contractual nature amongst > parties involved in a SKiSource or particular aspects of a > SKiSource. The CONTROL property is used to define these > responsibilities and jurisdictions. > > Format Definition: The property is defined by the following notation: > > control = "CONTROL" controlparam ":" uri CRLF > > ; the value MAY be a MAILTO URI, as defined > ; by RFC-1738[4]. > > controlparam = > > ; the following is optional, > ; but MUST NOT occur more than once > (";" languageparam ) / (";" cnparam ) / (";" skiroleparam) > > ; It is highly RECOMMENDED that SKICal objects actually > ; use the cnparam since some applications will not > ; bother to read the altrep'ed vCard. > > ; the following is optional, > ; and MAY occur more than once > > (";" xparam) > ) > > Example: The following are examples of this property: > > CONTROL;SKiROLE=producer;CN=Nobelkommitten:MAILTO:info@nobel.se > CONTROL;SKiROLE=producer;CN=Opera house:MAILTO:info@opera.de > CONTROL;SKiROLE=responsible;MAILTO:jean-marie@petiteville.fr > CONTROL;SKiROLE=contracting agency:MAILTO:info@ematelstar.se > CONTROL;SKiROLE=sponsor;CN=Stockholms stad:MAILTO:kultur@stadshuset. > a.se > CONTROL;SKiROLE=in association with;CN=Svenska Turistforbundet:MAILT > O:info@stf.se > CONTROL;SKiROLE=responsible-is-member-of;CN=Rotary international:MAI > LTO:rotary@rotary.org > > -------------------------------------------------------------------------- > > /Pär From owner-ietf-calendar@mail.imc.org Wed Mar 14 08:37:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23244 for ; Wed, 14 Mar 2001 08:37:16 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id FAA17878 for ietf-calendar-bks; Wed, 14 Mar 2001 05:22:29 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA17874 for ; Wed, 14 Mar 2001 05:22:27 -0800 (PST) From: Frank.Dawson@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2EDO9w11313 for ; Wed, 14 Mar 2001 07:24:19 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 14 Mar 2001 07:22:10 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 14 Mar 2001 07:22:10 -0600 Message-ID: <30F2DED23724D311902D0008C7EABAFB03F346A4@daeis06nok> To: andywproud@yahoo.co.uk, ietf-calendar@imc.org Subject: RE: Lotus Notes Date: Wed, 14 Mar 2001 07:22:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: YES...There is a vCalendar/iCalendar importer on the www.notes.net website. You register for "Sandbox" download, then search for "Notes iCalendar Support". You can also load the "Notes vCard Support" to get vCard import/export to your address book. > -----Original Message----- > From: ext Andrew Proud [mailto:andywproud@yahoo.co.uk] > Sent: Wednesday, March 14, 2001 02:21 > To: ietf-calendar@imc.org > Subject: Lotus Notes > > > Are there any Lotus Notes (Calendar) users on the list > ? > > If so. Please could you tell me if there is any way of > automating the importing of ics or vcs files. > > I am thinking of the way it works in Outlook. Outlook > upon install changes the 'File Types' association, > such that when you double-click on an ics file it is > automatically imported into your calendar. > > Failing that can it be done at all ? > > Many thanks > > Andy > > > PS MS Outlook does not perform this perfectly as per > my earlier posts. > > > ____________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk > or your free @yahoo.ie address at http://mail.yahoo.ie > From owner-ietf-calendar@mail.imc.org Wed Mar 14 10:54:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26417 for ; Wed, 14 Mar 2001 10:54:22 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA29440 for ietf-calendar-bks; Wed, 14 Mar 2001 07:35:24 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29426 for ; Wed, 14 Mar 2001 07:35:22 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2EFg1B04976 for ; Wed, 14 Mar 2001 10:42:01 -0500 Message-ID: <3AAF9149.6BA25161@ecal.com> Date: Wed, 14 Mar 2001 10:42:01 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Damon Chaplin wrote: > What should an application do when it has 2 VTIMEZONE components > with conflicting TZIDs? > > This may happen when an application receives a message from > another iCalendar app which uses the same TZIDs, or when an > application loads a .ics file it created itself, or that was > created by an earlier version of the application. Let's see. If a VCALENDAR contains a TZID pointing to a VTIMEZONE in that same VCALENDAR, then obviously the application should use that VTIMEZONE, not the one in its own configuration. But, if the application changes the TZIDs to get uniqueness, then it's changed that VCALENDAR, and it's going to run into trouble if it's doing iTIP. So I believe the correct approach is to define a search path: "first look in the current VCALENDAR, then look in your own configuration, then see if you can download the VTIMEZONE from somewhere" (assuming we ever get a global VTIMEZONE repository). -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Think of it as evolution in action. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Mar 14 14:06:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01567 for ; Wed, 14 Mar 2001 14:06:44 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA10462 for ietf-calendar-bks; Wed, 14 Mar 2001 10:49:03 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA10454 for ; Wed, 14 Mar 2001 10:49:01 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA14134 for ; Wed, 14 Mar 2001 12:46:16 -0600 From: "Shannon J. Clark" To: Subject: Some questions raised in my recent review of RFC2445 Date: Wed, 14 Mar 2001 12:48:07 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id KAA10462 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01567 As part of my ongoing development efforts, I recently was rereading most of the standards docs, in looking at RFC2445 (iCalendar) the following questions came to mind. One - there is an assumption, though not clearly documented, that most events and interactions will be on a one event by one event basis. Indeed a very common application (MS Outlook) appears to have a problem with complex iCalendar objects containing multiple vEvents. It is frequently useful to have the ability to deal with large sets of events (for example when synchronizing between two systems or when importing one large calendar into another). Is there an explicit requirement that "iCalendar" compliant products handle MULTI-OBJECT iCalendar messages? i.e. Messages with both a vEvent and a vTodo? Or an iCalendar object with multiple vEvents? What about multiple vCalendars? Two – there is an assumption that most of the time there will only be ONE event at a given time, and that overlaps are unforgivable. This implies that all events take 100% of a person’s time, and this contributes to the stress of using calendars, and decreases their utility for most people. Most time related events are not all or nothing affairs, most of the time they are of the form “the show is on now” or “the meeting is running for at least the next 45 minutes” or the cafeteria closes at 2:00. Sure there are the cases of events in two places at once - but in a world of virtual meetings and frequent multi-tasking our tools should accommodate how we in fact work and function. Three – much value can be obtained by helping relate events to each other, by doing this deadlines can be attached to the conference they are related to etc. Yes there is a "related_to" property - but see my above question about multi-object messages, with tools that require EACH object to be dealt with as a seperate transaction and interaction - the utility of linking events and other objects is greatly lessened. Four – in interoperability I can foresee issues with the “folding” technique to handle long lines – has this been a part of the testing procedures? That is, as part of the upcoming interop testing are there explicit cases to "stress" various tool's handling of this folding efforts? - it seems to me that the reliance on whitespace has potential to be error prone especially in interop between platforms (say the simple case of messages passing between Mac users and Windows users - perhaps with a unix system thrown into the mix somewhere. More as I continue to delve into the docs. Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Wed Mar 14 14:46:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02746 for ; Wed, 14 Mar 2001 14:46:01 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id LAA11975 for ietf-calendar-bks; Wed, 14 Mar 2001 11:21:26 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA11971 for ; Wed, 14 Mar 2001 11:21:24 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2EJS4B05646 for ; Wed, 14 Mar 2001 14:28:04 -0500 Message-ID: <3AAFC643.25F84863@ecal.com> Date: Wed, 14 Mar 2001 14:28:03 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Some questions raised in my recent review of RFC2445 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > One - there is an assumption, though not clearly documented, that most > events and interactions will be on a one event by one event basis. Where do you see this, please? > Two - there is an assumption that most of the time there will only be ONE > event at a given time, and that overlaps are unforgivable. Very few users can manage to be in more than one place at the same time. (Those hypothetical users who can don't need a calendar as much, because they don't have to worry about conflicts. ;-) Anyway, 4.8.2.7 (TRANSP) contradicts you. > Three - much value can be obtained by helping relate events to each other, > by doing this deadlines can be attached to the conference they are related > to etc. But then we need to define the various possible semantics of this sort of attachment. This might be valuable eventually, but it was not needed for the initial goals. > Four - in interoperability I can foresee issues with the ?folding? technique > to handle long lines I suppose. But, really, folding is easy to implement, and easy to test. Semantic problems are harder. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |This space intentionally not left blank. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Mar 14 14:51:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02844 for ; Wed, 14 Mar 2001 14:51:42 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id LAA12738 for ietf-calendar-bks; Wed, 14 Mar 2001 11:35:09 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA12730 for ; Wed, 14 Mar 2001 11:35:06 -0800 (PST) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA10831; Wed, 14 Mar 2001 14:34:33 -0500 Received: from c-1244.steltor.com (C-1244 [101.1.46.10]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9CP2Z43; Wed, 14 Mar 2001 14:33:10 -0500 Message-Id: <5.0.0.25.0.20010314135548.02c07120@apollo> X-Sender: aland@apollo X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 14 Mar 2001 14:34:57 -0500 To: "Shannon J. Clark" From: Alan Davies Subject: Re: Some questions raised in my recent review of RFC2445 Cc: ietf-calendar@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA12733 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id LAA12738 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA02844 >events and interactions will be on a one event by one event basis. Indeed a >very common application (MS Outlook) appears to have a problem with complex >iCalendar objects containing multiple vEvents. Outlook is not the benchmark of how the Standard should be implemented, just one vendor's implementation of a subset. >Two ­ there is an assumption that most of the time there will only be ONE >event at a given time, and that overlaps are unforgivable. This implies that Where is this assumption about overlapping made? >about multi-object messages, with tools that require EACH object to be dealt >with as a seperate transaction and interaction - the utility of linking >events and other objects is greatly lessened. Again, Outlook is not the only implementation. >Four ­ in interoperability I can foresee issues with the “folding” technique >to handle long lines It seems simple enough to understand and code, and the RFC is quite specific about the character set used- it shouldn't be difficult to support this on each platform. --Alan From owner-ietf-calendar@mail.imc.org Wed Mar 14 15:18:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03342 for ; Wed, 14 Mar 2001 15:18:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA15426 for ietf-calendar-bks; Wed, 14 Mar 2001 12:06:09 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA15411 for ; Wed, 14 Mar 2001 12:06:07 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2EKClB05838 for ; Wed, 14 Mar 2001 15:12:47 -0500 Message-ID: <3AAFD0BB.2F112DFB@ecal.com> Date: Wed, 14 Mar 2001 15:12:43 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CALSCH Agenda for IETF 50 References: Content-Type: multipart/mixed; boundary="------------1E5903D4C3024348416B9FDA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1E5903D4C3024348416B9FDA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Mahoney wrote: > 2. IPTEL/CALSCH issues -John Stracke > Overview of major issues > (Will also be covered in WG dinners and such) Attached is the outline of what I'll be covering. Please let me know if there's anything unclear, or if you think it's too long, or something. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"You gotta learn to dance before you learn to| |francis@ecal.com|crawl!" -- Meatloaf, "Everything Louder than | | |Everything Else" | \==============================================================/ --------------1E5903D4C3024348416B9FDA Content-Type: text/html; charset=us-ascii; name="outline.html" Content-Disposition: inline; filename="outline.html" Content-Transfer-Encoding: 7bit IPTEL's use of iCalendar

IPTEL's use of iCalendar

  • Why IPTEL uses iCalendar
    • CPL (Call Processing Language) needs to know which rules apply when.
    • In essence, that's a recurring event: this rule applies at these times.
    • Rather than invent recurrence rules from scratch, CPL uses a subset of iCalendar's.
    • Hope is that a user's CPL rules can be populated from their calendar: "Don't call me while I'm in meetings".
  • What the problem is
    • The full iCalendar RECUR semantics are too much for CPL
      • CPL has to run in a telephony switch. CPU and memory are expensive.
      • CPL has to run in bounded time. BYSETPOS and COUNT cannot be evaluated in bounded time.
      • Also, iCalendar can specify a recurring event whose instances overlap. Nightmare.
    • So CPL defines a subset of the recurrence rules
      • Eliminates all sub-day parameters (SECONDLY, MINUTELY, HOURLY, BYSECOND, BYMINUTE, BYHOUR).
      • Eliminates BYSETPOS, COUNT.
      • Restricts DURATION to be less than 24 hours.
    • Meets CPL's needs, but cannot interoperate
      • A calendar user can specify recurrences which their IPTEL switch cannot implement.
      • If the switch and the CS are connecting behind the scenes, it will be difficult to give the user a good explanation.
      • User will wind up believing the switch just doesn't work.
      • Some users may not encounter the problem. This is worse, because, sooner or later, they will; and then it'll be a surprise.
  • The subset solution
    • iCalendar's recurrence rules are too much for calendars, too.
      • Possible to define extremely complex rules. Example:
        • occurs every 79 seconds,
        • also occurs at 3:15:25 PM on the 12th, 37th, and 159th days of the year,
        • but does not occur unless it's 13 or 23 seconds after the minute,
        • and does not occur on the second Tuesday of the month.
      • How can UI express this clearly?
      • Worse, how can the user edit it?
      • CUA's RRULE editor will work only on a subset; no other option.
      • Different CUAs will use different subsets. Might not test features outside their subset properly. Interop nightmare.
    • Suggestion: define a subset.
      • Pare down the semantics to something manageable.
      • draft-stracke-calsch-rrule-subset-XX.txt defines subset from CPL
      • Might conceivably need to be simplified still more, but this is a start.
    • My preference: this subset should become the only set.
      • When we rev 2445, we should throw out the parts that don't fit.
      • Otherwise, we still have interop problems, when a 2445bis CUA gets an iCalendar from a 2445 CUA.
--------------1E5903D4C3024348416B9FDA-- From owner-ietf-calendar@mail.imc.org Wed Mar 14 15:27:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03644 for ; Wed, 14 Mar 2001 15:27:46 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA15953 for ietf-calendar-bks; Wed, 14 Mar 2001 12:13:35 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA15947 for ; Wed, 14 Mar 2001 12:13:30 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA14239 for ; Wed, 14 Mar 2001 14:10:43 -0600 From: "Shannon J. Clark" To: Subject: RE: Some questions raised in my recent review of RFC2445 Date: Wed, 14 Mar 2001 14:12:36 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3AAFC643.25F84863@ecal.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is my point - there is an assumption on the part of the standards doc, and many implementers that the majority of events will be of the sort that cannot overlap. (I am aware of the TRANSP) My software is close to 100% focused on information that does NOT by default cause conflicts - mostly notifications of possible events, but NOT invitations to them, rather indications on your calendar that there are multiple things occurring at the same time. In my general usage of my calendars overlapping events are more often than not what I have on my calendar - I am mostly concerned with what my options are - not with deciding exactly which I will be attending (these are mostly of the category of public type events). The assumption is seen in the examples and documentation in the first few sections - I'll review the docs again and send the exact locations later this week. I was NOT considering related events as attachments to over events - I have been considering them as LINKS to other events - is this not a correct interpretation of the related to property? Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of John Stracke Sent: Wednesday, March 14, 2001 1:28 PM To: ietf-calendar@imc.org Subject: Re: Some questions raised in my recent review of RFC2445 "Shannon J. Clark" wrote: > One - there is an assumption, though not clearly documented, that most > events and interactions will be on a one event by one event basis. Where do you see this, please? > Two - there is an assumption that most of the time there will only be ONE > event at a given time, and that overlaps are unforgivable. Very few users can manage to be in more than one place at the same time. (Those hypothetical users who can don't need a calendar as much, because they don't have to worry about conflicts. ;-) Anyway, 4.8.2.7 (TRANSP) contradicts you. > Three - much value can be obtained by helping relate events to each other, > by doing this deadlines can be attached to the conference they are related > to etc. But then we need to define the various possible semantics of this sort of attachment. This might be valuable eventually, but it was not needed for the initial goals. > Four - in interoperability I can foresee issues with the ?folding? technique > to handle long lines I suppose. But, really, folding is easy to implement, and easy to test. Semantic problems are harder. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |This space intentionally not left blank. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Mar 14 15:39:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03812 for ; Wed, 14 Mar 2001 15:39:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA16892 for ietf-calendar-bks; Wed, 14 Mar 2001 12:25:15 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA16886 for ; Wed, 14 Mar 2001 12:25:14 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA14257 for ; Wed, 14 Mar 2001 14:22:27 -0600 From: "Shannon J. Clark" To: Subject: RE: Some questions raised in my recent review of RFC2445 Date: Wed, 14 Mar 2001 14:24:20 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.0.0.25.0.20010314135548.02c07120@apollo> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id MAA16892 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA03812 Alan, I am well aware that Outlook is not the benchmark, I cite it as a very commonly deployed and used application where clearly the interpretation of the standard was not clear. From an interop point of view - and thus from the perspective of moving the standard forward - it is important that we have a common understanding of WHAT the standard is for - if there are questions from major vendors overall adoption and use of a standard will suffer. As such, this appears to me to indicate that there are some assumptions that are not clearly documented within the standards - are or are not multi-object iCalendar files to be expected? Are all methods of using the various standards focused on ONE EVENT at a time OR is there is significant place within the standards efforts for actions that involve MULTIPLE iCalendar objects at a time? For example - importing a calendar (which I thought was major role for the iCalendar standard to play - to allow a complex calendar to be imported and exported between two iCalendar compliant software applications) Or a action that involved multiple RELATED objects (a vEvent and related vToDo for example)? What about actions involving multiple object that are NOT related? (Three different performances of a play?) IF they are defined by a reoccurrence rule - clearly the standards fully apply and expect this situation, I'm asking if they are also apply to non-reoccurring entries. Re the folding - I agree that it is clearly spelled out and fairly easy to implement - I was just suggesting that when we test interop we don't forget to test these seemingly "simple" portions of the code - not too infrequently the areas we "assume" we got right can contain hidden "gotchas" shouldn't be to hard to set up some test scenarios that exercise this aspect of our various applications. Shannon -----Original Message----- From: Alan Davies [mailto:aland@steltor.com] Sent: Wednesday, March 14, 2001 1:35 PM To: Shannon J. Clark Cc: ietf-calendar@imc.org Subject: Re: Some questions raised in my recent review of RFC2445 >events and interactions will be on a one event by one event basis. Indeed a >very common application (MS Outlook) appears to have a problem with complex >iCalendar objects containing multiple vEvents. Outlook is not the benchmark of how the Standard should be implemented, just one vendor's implementation of a subset. >Two ­ there is an assumption that most of the time there will only be ONE >event at a given time, and that overlaps are unforgivable. This implies that Where is this assumption about overlapping made? >about multi-object messages, with tools that require EACH object to be dealt >with as a seperate transaction and interaction - the utility of linking >events and other objects is greatly lessened. Again, Outlook is not the only implementation. >Four ­ in interoperability I can foresee issues with the “folding” technique >to handle long lines It seems simple enough to understand and code, and the RFC is quite specific about the character set used- it shouldn't be difficult to support this on each platform. --Alan From owner-ietf-calendar@mail.imc.org Wed Mar 14 16:06:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04367 for ; Wed, 14 Mar 2001 16:06:57 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA18370 for ietf-calendar-bks; Wed, 14 Mar 2001 12:51:43 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA18366 for ; Wed, 14 Mar 2001 12:51:41 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2EKwLB06017 for ; Wed, 14 Mar 2001 15:58:21 -0500 Message-ID: <3AAFDB6C.56E04688@ecal.com> Date: Wed, 14 Mar 2001 15:58:21 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Some questions raised in my recent review of RFC2445 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Shannon J. Clark" wrote: > As such, this appears to me to indicate that there are some assumptions that > are not clearly documented within the standards - are or are not > multi-object iCalendar files to be expected? 4.6 says: In addition, a complex iCalendar object is possible that is used to capture a complete snapshot of the contents of a calendar (e.g., composite of many different calendar components). What do you consider unclear? > Or a action that involved multiple RELATED objects (a vEvent and related > vToDo for example)? If you want related events, write an I-D defining them. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Misanthropology: the study of why people are so| |francis@ecal.com|stupid. | \================================================================/ From owner-ietf-calendar@mail.imc.org Wed Mar 14 16:50:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05191 for ; Wed, 14 Mar 2001 16:50:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA21142 for ietf-calendar-bks; Wed, 14 Mar 2001 13:29:20 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA21138 for ; Wed, 14 Mar 2001 13:29:17 -0800 (PST) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA13756; Wed, 14 Mar 2001 16:28:43 -0500 Received: from c-1244.steltor.com (C-1244 [101.1.46.10]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G9CP25V9; Wed, 14 Mar 2001 16:27:19 -0500 Message-Id: <5.0.0.25.0.20010314162812.00b1ca70@apollo> X-Sender: aland@apollo X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 14 Mar 2001 16:29:05 -0500 To: "Shannon J. Clark" From: Alan Davies Subject: RE: Some questions raised in my recent review of RFC2445 Cc: ietf-calendar@imc.org In-Reply-To: References: <5.0.0.25.0.20010314135548.02c07120@apollo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14:24 2001-03-14 -0600, you wrote: > Alan, > > I am well aware that Outlook is not the benchmark, I cite it as a very > commonly deployed and used application where clearly the interpretation of > the standard was not clear. From an interop point of view - and thus from > the perspective of moving the standard forward - it is important that we > have a common understanding of WHAT the standard is for - if there are > questions from major vendors overall adoption and use of a standard will > suffer. That's your interpretation of their interpretation of the standard. As you've seen from testing Outlook, it is clear that Microsoft has implemented a subset of the standards. I don't know their reasons for this, but at least it's better than nothing- it doesn't mean that there's a problem with the standard though. You're right that it's important to understand what we're all implementing, that's one goal of CalConnect. > As such, this appears to me to indicate that there are some assumptions that > are not clearly documented within the standards - are or are not > multi-object iCalendar files to be expected? Are all methods of using the > various standards focused on ONE EVENT at a time OR is there is significant > place within the standards efforts for actions that involve MULTIPLE > iCalendar objects at a time? An "iCalendar object" is a different concept from an "event", so your second question doesn't make sense. RFC2445 states that an iCalendar object can contain "one or more" components, some of which could be events: 4.6 Calendar Components The body of the iCalendar object consists of a sequence of calendar properties and one or more calendar components. The calendar properties are attributes that apply to the calendar as a whole. The calendar components are collections of properties that express a particular calendar semantic. For example, the calendar component can specify an event, a to-do, a journal entry, time zone information, or free/busy time information, or an alarm. [....] ... a complex iCalendar object is possible that is used to capture a complete snapshot of the contents of a calendar (e.g., composite of many different calendar components). > Re the folding - I agree that it is clearly spelled out and fairly easy to > implement - I was just suggesting that when we test interop we don't forget > to test these seemingly "simple" portions of the code - not too infrequently > the areas we "assume" we got right can contain hidden "gotchas" shouldn't be > to hard to set up some test scenarios that exercise this aspect of our > various applications. Yes, all details should be tested- I took your previous comment to imply that folding was a problem with the standard. --Alan From owner-ietf-calendar@mail.imc.org Wed Mar 14 19:46:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07183 for ; Wed, 14 Mar 2001 19:46:47 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA02081 for ietf-calendar-bks; Wed, 14 Mar 2001 16:34:49 -0800 (PST) Received: from tesla.umkc.edu (hilbert.umkc.edu [134.193.4.60]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA02077 for ; Wed, 14 Mar 2001 16:34:47 -0800 (PST) Received: (qmail 30408 invoked from network); 15 Mar 2001 00:33:43 -0000 Received: from nicol1.umkc.edu (HELO kasey.umkc.edu) (david@134.193.4.62) by hilbert.umkc.edu with SMTP; 15 Mar 2001 00:33:43 -0000 Message-ID: <3AB00DE7.9752A52F@kasey.umkc.edu> Date: Thu, 15 Mar 2001 00:33:43 +0000 From: "David L. Nicol" Organization: University of Missouri - Kansas City supercomputing infrastructure X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke , ietf-calendar@mail.imc.org Subject: Re: Some questions raised in my recent review of RFC2445 References: <3AAFC643.25F84863@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > "Shannon J. Clark" wrote: > > > Two - there is an assumption that most of the time there will only be ONE > > event at a given time, and that overlaps are unforgivable. > > Very few users can manage to be in more than one place at the same time. (Those > hypothetical users who can don't need a calendar as much, because they don't > have to worry about conflicts. ;-) Calendars contain entries for multiple activites, for instance all the rooms in a building hold classes which overlap; a general calendar needs to support applications besides one person's appointments! From owner-ietf-calendar@mail.imc.org Thu Mar 15 07:11:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28605 for ; Thu, 15 Mar 2001 07:11:19 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA26900 for ietf-calendar-bks; Thu, 15 Mar 2001 03:56:29 -0800 (PST) Received: from mail11.svr.pol.co.uk (mail11.svr.pol.co.uk [195.92.193.23]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA26896 for ; Thu, 15 Mar 2001 03:56:27 -0800 (PST) Received: from modem-204.dwarf-lion-fish.dialup.pol.co.uk ([62.137.4.204] helo=ximian.com) by mail11.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14dWMj-00038U-00; Thu, 15 Mar 2001 11:56:25 +0000 Message-ID: <3AB03882.EB2F35E3@ximian.com> Date: Thu, 15 Mar 2001 03:35:30 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: "ietf-calendar@imc.org" Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > Damon Chaplin wrote: > > > What should an application do when it has 2 VTIMEZONE components > > with conflicting TZIDs? > > > > This may happen when an application receives a message from > > another iCalendar app which uses the same TZIDs, or when an > > application loads a .ics file it created itself, or that was > > created by an earlier version of the application. > > Let's see. If a VCALENDAR contains a TZID pointing to a VTIMEZONE in that same > VCALENDAR, then obviously the application should use that VTIMEZONE, not the > one in its own configuration. But, if the application changes the TZIDs to get > uniqueness, then it's changed that VCALENDAR, and it's going to run into > trouble if it's doing iTIP. So I believe the correct approach is to define a > search path: "first look in the current VCALENDAR, then look in your own > configuration, then see if you can download the VTIMEZONE from somewhere" > (assuming we ever get a global VTIMEZONE repository). I don't think that really solves the conflicts, though. If the app loads/receives an iCalendar file with, for example, a "Europe/London" VTIMEZONE calendar component, and the user then creates another time with the timezone set to "Europe/London", then we have 2 "Europe/London" VTIMEZONE components to place in the iCalendar file. If you're right about iTIP problems, then it looks like it is impossible to resolve conflicts. This also suggests using a product ID and version in the TZID like I proposed so we avoid conflicts. One other thing I forgot is that currently VTIMEZONE components only have to cover the time range used within the iCalendar file. I think this is going to cause problems as well - how do you know which VTIMEZONE to keep when you have 2 VTIMEZONEs which are the same except for the time range that they cover? Are you supposed to merge the subcomponents? That would be very difficult. So I think it is better if a VTIMEZONE component must cover the entire time range. Damon From owner-ietf-calendar@mail.imc.org Thu Mar 15 10:26:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01172 for ; Thu, 15 Mar 2001 10:26:50 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA11883 for ietf-calendar-bks; Thu, 15 Mar 2001 07:04:26 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA11878 for ; Thu, 15 Mar 2001 07:04:25 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2FFB5M07679 for ; Thu, 15 Mar 2001 10:11:05 -0500 Message-ID: <3AB0DB88.AFFDA196@ecal.com> Date: Thu, 15 Mar 2001 10:11:04 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Damon Chaplin wrote: > If the app loads/receives an iCalendar file with, for example, a "Europe/London" > VTIMEZONE calendar component, and the user then creates another time with the > timezone set to "Europe/London", then we have 2 "Europe/London" VTIMEZONE > components to place in the iCalendar file. OK, yeah, in that case, the CUA may need to put them both in, and rename one of them. A slightly smarter CUA, though, would check to see whether the existing VTIMEZONE agrees with the one it knows. > If you're right about iTIP problems, then it looks like it is impossible to > resolve conflicts. This also suggests using a product ID and version in the TZID > like I proposed so we avoid conflicts. Mmm, no, I don't think that would help, necessarily. > One other thing I forgot is that currently VTIMEZONE components only have to > cover the time range used within the iCalendar file. I really can't see any sensible implementation automatically narrowing down the VTIMEZONE it sends out. It's going to be much more efficient just to send the component taken from its configuration; working up an algorithm to reduce that component to just what's necessary to cover a certain range would be ludicrously painful. Besides, what happens if the recipient COUNTERs with a time outside that original range, a time at which the original VTIMEZONE disagrees with the reduced one? > So I think it is better if a VTIMEZONE component must cover the entire time range. Er...but define "the entire time range". From now until the end of time? I would say instead: a CUA SHOULD send VTIMEZONE components which cover as large a time range as the CUA knows for that timezone. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Lollygaggers will be shot on sight!" "I didn't| |francis@ecal.com|say that!" "I was paraphrasing." | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 15 10:27:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01186 for ; Thu, 15 Mar 2001 10:27:22 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA12105 for ietf-calendar-bks; Thu, 15 Mar 2001 07:08:35 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA12100 for ; Thu, 15 Mar 2001 07:08:33 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2FFFEM07712 for ; Thu, 15 Mar 2001 10:15:14 -0500 Message-ID: <3AB0DC82.1AABFD1@ecal.com> Date: Thu, 15 Mar 2001 10:15:14 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@mail.imc.org Subject: Re: Some questions raised in my recent review of RFC2445 References: <3AAFC643.25F84863@ecal.com> <3AB00DE7.9752A52F@kasey.umkc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "David L. Nicol" wrote: > > > Two - there is an assumption that most of the time there will only be ONE > > > event at a given time, and that overlaps are unforgivable. > > > > Very few users can manage to be in more than one place at the same time. > > Calendars contain entries for multiple activites, for instance > all the rooms in a building hold classes which overlap; a general calendar > needs to support applications besides one person's appointments! And they do. But, as I said before, personal appointments are the best understood (and most challenging) part of the problem space, so that's what people were thinking about when they wrote 2445, and it probably reflects that attitude. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |This is the .sig that says... Ni! | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 15 10:29:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01206 for ; Thu, 15 Mar 2001 10:29:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA12208 for ietf-calendar-bks; Thu, 15 Mar 2001 07:10:02 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA12203 for ; Thu, 15 Mar 2001 07:10:01 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2FFGfM07732 for ; Thu, 15 Mar 2001 10:16:42 -0500 Message-ID: <3AB0DCD9.E42CE5A7@ecal.com> Date: Thu, 15 Mar 2001 10:16:41 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CALSCH Agenda for IETF 50 References: <3AAFD0BB.2F112DFB@ecal.com> Content-Type: multipart/mixed; boundary="------------9E69AA76B98A7B7F6AAEA753" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9E69AA76B98A7B7F6AAEA753 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: * Bob Mahoney wrote: > > > 2. IPTEL/CALSCH issues -John Stracke > > Overview of major issues > > (Will also be covered in WG dinners and such) > > Attached is the outline of what I'll be covering. And here's the (unsubmitted) Draft it mentions. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I'm not imaginary. I'm ontologically challenged.| |francis@ecal.com| | \=================================================================/ --------------9E69AA76B98A7B7F6AAEA753 Content-Type: text/plain; charset=us-ascii; name="draft-stracke-calsch-rrule-subset-XX.txt" Content-Disposition: inline; filename="draft-stracke-calsch-rrule-subset-XX.txt" Content-Transfer-Encoding: 7bit Internet Engineering Task Force J. Stracke INTERNET DRAFT eCal draft-stracke-calsch-rrule-subset-XX.txt J. Lennox Columbia Univ. February 2001 Expires: August 2001 A Simplified Subset of iCalendar RRULEs 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to francis@ecal.com or to the ietf-calendar@imc.org discussion list (subscription address ietf-calendar-request@imc.org; "SUBSCRIBE" or "UNSUBSCRIBE" in the body). 2. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 3. Abstract This document sets forth a subset of the RRULE syntax for [iCalen- dar]. The problem which motivated this subset is that iCalendar's recurring-event rules are extremely complex; it is difficult to eval- uate them, and well-nigh impossible to build a usable user interface Stracke, Lennox [Page 1] RRULE Subset December 2000 to edit them. 4. Introduction [iCalendar]'s recurrence rules are extremely complex. For example, it is possible to specify an event which: * occurs every 79 seconds, * also occurs at 3:15:25 PM on the 12th, 37th, and 159th days of the year, * but does not occur unless it's 13 or 23 seconds after the minute, * and does not occur on the second Tuesday of the month. While it is certainly feasible (though difficult) to write computer code which interprets such rules, it is extremely hard to be sure one has written this code correctly. Furthermore, it is probably impos- sible to create a user interface which can display (let alone edit) these rules in a comprehensible fashion. (For one thing, note that the "not unless it's 13 or 23 seconds after the minute" part con- flicts with the "3:15:25 PM" part. It is, of course, possible to write code which examines the rule for such conflicts; but then one has to figure out how to explain them to the user. A proper UI pre- vents the user from making mistakes in the first place; and that becomes nearly impossible when the mistakes are so hard to explain.) In order to make the user interface comprehensible, each CUA will probably expose only a subset of the available recurrence features to the user. The risk, then, is that different CUAs will expose differ- ent subsets, and will not be properly tested for iCalendar objects which stray outside those subsets. Even if they expand those iCalen- dar objects correctly, they may not display the full recurrence rule correctly, since that would require complicating the UI. If that happens, the user will wind up seeing that the recurrence rule for their repeating event says it occurs every Monday, but the calendar does not show the event on every Monday; there are gaps. Confusing the users like this effectively means that there will not be interop- erability: even if the underlying iCalendar implementations under- stand each other, the users don't. Finally, evaluating these rules is highly CPU-intensive. If one uses the COUNT parameter, for example, to state that the event occurs no more than 25 times, then, every time the user wishes to see their calendar, the CUA (Calendar User Agent) must evaluate that rule up to 25 times. This is sort of acceptable when it's just the CUA getting involved; but, if the CUA is making a query against a CS (Calendar Store) for all the user's events within a given range, that's an Stracke, Lennox [Page 2] RRULE Subset December 2000 extremely expensive request, computationally, to impose on a server. Servers which support such queries will not scale, unless they pre- expand their recurring events. This approach can work, but it has its own problems; it is expensive in disk space, and may create so many database entries that the database slows down. (Or, of course, it may not; the point is simply that, as things stand, this approach is the only viable one; with cheaper evaluation, we have more options, more opportunities to find the Right Thing.) The iptel working group, in defining their Call Processing Language ([CPL]), needed a way of specifying which processing rules apply when. They wanted to reuse the iCalendar specification, but they found the cost of evaluating the recurrence rules to be too high to perform in a telephony switch. So, instead, they used a subset of iCalendar recurrence rules, in which the switch can answer the ques- tion "which rule applies right now?" in O(1) time. This document lays out that subset in iCalendar terms. 5. Subset Definition In this subset, not all of the parameters defined in [iCalendar]'s section 4.3.10 (which defines the value type RECUR) are allowed. The allowed parameters are: * FREQ * INTERVAL * UNTIL * BYDAY * BYMONTHDAY * BYYEARDAY * BYWEEKNO * BYMONTH * WKST In addition, the FREQ parameter is more restricted than in [iCal- endar]; the only legal values are DAILY, WEEKLY, MONTHLY, and YEARLY (SECONDLY, MINUTELY, and HOURLY were removed). Finally, the event's DURATION must be less than 24 hours. 6. Subset Motivation (This section is non-normative.) The COUNT and BYSETPOS parameters have been removed in order to make sure that it is possible to evaluate a rule in O(1) time; since COUNT Stracke, Lennox [Page 3] RRULE Subset December 2000 and BYSETPOS rely on the concept of "Nth instance of the event", they require the implementation to loop through and evaluate at least the first N instances. If necessary, similar functionality can be obtained via UNTIL and EXDATE or RDATE. In addition, limiting FREQ's values and removing BYSECOND, BYMINUTE, and BYHOUR makes it impossible to specify an event which recurs more often than once per day. Combined with the restriction that the event's duration must be less than 24 hours, this makes sure that no two instances of a recurring event can overlap. Overlapping instances would complicate the evaluation algorithm and prevent it from being O(1); and, in any case, a user interface would be hard- pressed to display an event with overlapping instances in a coherent fashion. It might be possible to come up with some other way of pre- venting overlapping instances, but this one is simple to understand (both for implementors and for users). It is worth pointing out that the O(1) algorithm is not quite con- stant time; for example, if the VEVENT contains both an RRULE and an EXRULE, evaluation will take twice as long. If it contains N EXDATEs, evaluation will go up by an O(N) factor (the same applies for RDATEs, of course). 7. Conclusions The subset specified here is much simpler to work with than the full RECUR syntax of [iCalendar], without greatly limiting functionality; if we modify iCalendar to be limited to this subset, it ought to be easier to achieve full interoperability. It will also be simpler for users to understand, and for implementations to evaluate. 8. Security Considerations This document specifies a subset of [iCalendar], and accordingly inherits all of iCalendar's security analysis. It seems intuitively obvious (warning: handwaving ahead) that adopting this subset cannot introduce new security risks; that any risk present in this subset is also present in the original iCalendar specification. 9. An Algorithm for Resolving Time Switches (This section is non-normative. It is taken from Appendix A of [CPL].) Stracke, Lennox [Page 4] RRULE Subset December 2000 The following algorithm resolves, in constant time, whether a given instant falls within a repetition of a time-switch recurrence. Open- source Java code implementing this algorithm is available on the world wide web at . 1. Compute the time of the call, in the timezone of the time switch. (No step after this needs to consider time zones -- all calculations are done using continuously-running standard Gregorian time.) 2. If the call time is earlier than dtstart, fail NOMATCH. 3. If the call time is less than duration after dtstart, succeed MATCH. 4. Determine the smallest unit specified in a byxxx rule or by the freq. Call this the Minimum Unit. Determine the previous instant (before the call time) when all the time units smaller than the minimum unit are the same as those of dtstart. (For all minimum units, the time-of-day must be the same as dtstart. If the minimum unit is a week, the day-of-the-week must be the same as dtstart. If the minimum unit is a month, the day-of-the-month must be the same as dtstart. If the mini- mum unit is a year, the month and day-of-month must both be the same as dtstart. (Note that this means it may be necessary to roll back more than one minimum unit -- if the minimum unit is a month, then some months do not have a 31st (or 30th or 29th) day; if the minimum unit is a year, then some years do not have a February 29th. In the Gregorian calendar, it is never necessary to roll back more than two months, or eight years (four years between 1904 and 2096).) Call this instant the Candidate Start Time. 5. If the time between the candidate start time and the call time is more than the duration, fail NOMATCH. 6. If the candidate start time is later than the until parameter of the recurrence, fail NOMATCH. 7. Call the unit of the freq parameter of the recurrence the Fre- quency Unit. Determine the frequency unit enclosing the Can- didate Start Time, and that enclosing dtstart. Calculate the number of frequency units that have passed between these two times. If this is not a multiple of the interval parameter, fail NOMATCH. Stracke, Lennox [Page 5] RRULE Subset December 2000 8. For every byxxx rule, confirm that the candidate start time matches one of the options specified by that byxxx rule. If not, fail NOMATCH. 9. Succeed MATCH. 10. Authors' Addresses: John Stracke Chief Scientist eCal Corp. Email: francis@ecal.com Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: lennox@cs.columbia.edu 11. References [iCAL] Dawson, Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. [CPL] Lennox, Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", draft-ietf-iptel-cpl-04.txt, November 2000. Work in progress. Stracke, Lennox [Page 6] --------------9E69AA76B98A7B7F6AAEA753-- From owner-ietf-calendar@mail.imc.org Thu Mar 15 10:56:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01725 for ; Thu, 15 Mar 2001 10:55:58 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA15211 for ietf-calendar-bks; Thu, 15 Mar 2001 07:34:31 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA15202 for ; Thu, 15 Mar 2001 07:34:29 -0800 (PST) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: Federico Mena Quintero , ietf-calendar@imc.org Subject: Re: Semantics of date vs. date/time EXDATEs MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03082001 March 08, 2001 Message-ID: Date: Thu, 15 Mar 2001 10:42:51 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/15/2001 10:34:53 AM, Serialize complete at 03/15/2001 10:34:53 AM Content-Type: multipart/alternative; boundary="=_alternative 00555EAF85256A10_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00555EAF85256A10_= Content-Type: text/plain; charset="us-ascii" Damon asked: >Can we agree on this and add it to the spec before we get interoperability >problems? Seems there is no argument against it so I propose Eric makes it so... Anyone object, chime in now please. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00555EAF85256A10_= Content-Type: text/html; charset="us-ascii"
Damon asked:
>Can we agree on this and add it to the spec before we get interoperability
>problems?

Seems there is no argument against it so I propose Eric makes it so...  Anyone object, chime in now please.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00555EAF85256A10_=-- From owner-ietf-calendar@mail.imc.org Thu Mar 15 11:57:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03083 for ; Thu, 15 Mar 2001 11:57:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA21832 for ietf-calendar-bks; Thu, 15 Mar 2001 08:33:42 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21827 for ; Thu, 15 Mar 2001 08:33:40 -0800 (PST) From: Bruce_Kahn@iris.com MIME-Version: 1.0 To: Frank.Dawson@nokia.com Cc: ietf-calendar@imc.org, par.lannero@metamatrix.se Subject: RE: SKICal CONTROL X-Mailer: Lotus Notes Build V60_03082001 March 08, 2001 Message-ID: Date: Thu, 15 Mar 2001 11:41:02 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/15/2001 11:34:04 AM, Serialize complete at 03/15/2001 11:34:04 AM Content-Type: multipart/alternative; boundary="=_alternative 005AB10B85256A10_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005AB10B85256A10_= Content-Type: text/plain; charset="us-ascii" Frank asked: >I am >also not certain what "legally responsible" actually means compared with the >semantics for ORGANIZER, which is the person responsible for scheduling the >event. Here is the difference between ORGANIZER and CONTROL as I read it in Gregs text. Your AA organizes travel plans (ie: makes your car and hotel reservations) for anyone you interview but you (or your company more likely) are the one legally responsible if someone you are hosting gets hurt on a site tour!. In other venues like sponsored events (ie: The Boston Marathon) the ORGANIZER is just the one that coordinates, say, signups but is not necessarily the one (or the only one) legally or even financially responsible. If The Boston Marathon gets postponed for some reason, the CONTROL entities would be the ones who are liable for 'making things right'. Another example (American based, sorry non-US readers): In a recent Survivor II episode one of the people got pretty seriously injured and had to be helicopter transported to a hospital/burn unit. The CONTROL could be the Executive Producers of the show as well as sponsors like ABC (is it ABC?) Networks, Target stores, Nike shoes, etc. The ORGANIZER is simply the point of contact for organizing Survivors contestants and the other logistical stuff. Perhaps "legally responsible" is not quite 100% on the mark but it seems relatively clear to me. >Simple sounds good! Yes!! Thank you Greg! >How many times can this property appear in a VEVENT? If more than once, what >does this mean? Boy, it seems more folks noticed this too. Since you can easily have more than 1 "Sponsor" for an event you MUST have the ability to specify > 1 CONTROL. Since the value is a single URI, the only way to convey this mutiple sponsor info is to have > 1 CONTROL in the entity. I assume that the CONTROL can be on any entity (except TIMEZONE or JOURNAL but JOURNAL is suspect). But what does it mean if I have 2 VEVENTs (or 1 VEVENT and 1 VTODO) and only one has CONTROLs on it and the other is RELATED-TO it? Is there any "guilt by association" or is responsiblity ONLY valid if it specified on the entity? A solid example of this: 1 VEVENT for The Boston Marathon and 1 VEVENT for the "pre-Marathon Runners Dinner". The latter is RELATED-TO the Marathon but only the Marathon VEVENT has any CONTROL information on it. Does the pre-Marathon dinner 'inherit' the CONTROL responsiblity? Can it? Should it? For compactness I would suggest "yes" but this only works if the set of CONTROL entities are proper subsets of one another (ie: only some sponsors pay for the dinner but all pay for the marathon). It does not work well for cases where some sponsors pay for JUST the dinner (ie: the local pasta company donates the food but gives no other sponsorship $$ or goods). This makes me want to say that the CONTROL values are not 'inheritable'; they must be expressly put on all entities or they do not apply... Hmm Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005AB10B85256A10_= Content-Type: text/html; charset="us-ascii"
Frank asked:
>I am
>also not certain what "legally responsible" actually means compared with the
>semantics for ORGANIZER, which is the person responsible for scheduling the
>event.

Here is the difference between ORGANIZER and CONTROL as I read it in Gregs text.  Your AA organizes travel plans (ie: makes your car and hotel reservations) for anyone you interview but you (or your company more likely) are the one legally responsible if someone you are hosting gets hurt on a site tour!.

In other venues like sponsored events (ie: The Boston Marathon) the ORGANIZER is just the one that coordinates, say, signups but is not necessarily the one (or the only one) legally or even financially responsible.  If The Boston Marathon gets postponed for some reason, the CONTROL entities would be the ones who are liable for 'making things right'.

Another example (American based, sorry non-US readers): In a recent Survivor II episode one of the people got pretty seriously injured and had to be helicopter transported to a hospital/burn unit.  The CONTROL could be the Executive Producers of the show as well as sponsors like ABC (is it ABC?) Networks, Target stores, Nike shoes, etc.  The ORGANIZER is simply the point of contact for organizing Survivors contestants and the other logistical stuff.

Perhaps "legally responsible" is not quite 100% on the mark but it seems relatively clear to me.

>Simple sounds good!

Yes!!  Thank you Greg!

>How many times can this property appear in a VEVENT? If more than once, what
>does this mean?

Boy, it seems more folks noticed this too.  Since you can easily have more than 1 "Sponsor" for an event you MUST have the ability to specify > 1 CONTROL.  Since the value is a single URI, the only way to convey this mutiple sponsor info is to have > 1 CONTROL in the entity.

I assume that the CONTROL can be on any entity (except TIMEZONE or JOURNAL but JOURNAL is suspect).  But what does it mean if I have 2 VEVENTs (or 1 VEVENT and 1 VTODO) and only one has CONTROLs on it and the other is RELATED-TO it?  Is there any "guilt by association" or is responsiblity ONLY valid if it specified on the entity?   A solid example of this:  1 VEVENT for The Boston Marathon and 1 VEVENT for the "pre-Marathon Runners Dinner".  The latter is RELATED-TO the Marathon but only the Marathon VEVENT has any CONTROL information on it.  Does the pre-Marathon dinner 'inherit' the CONTROL responsiblity?  Can it?  Should it?  For compactness I would suggest "yes" but this only works if the set of CONTROL entities are proper subsets of one another (ie: only some sponsors pay for the dinner but all pay for the marathon).  It does not work well for cases where som! e sponsors pay for JUST the dinner (ie: the local pasta company donates the food but gives no other sponsorship $$ or goods).  This makes me want to say that the CONTROL values are not 'inheritable'; they must be expressly put on all entities or they do not apply...  Hmm

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 005AB10B85256A10_=-- From owner-ietf-calendar@mail.imc.org Thu Mar 15 12:46:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04300 for ; Thu, 15 Mar 2001 12:46:09 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA23961 for ietf-calendar-bks; Thu, 15 Mar 2001 09:25:37 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA23957 for ; Thu, 15 Mar 2001 09:25:35 -0800 (PST) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA23726 for ; Thu, 15 Mar 2001 12:25:06 -0500 Received: from pc152 (PC-152 [101.1.46.9]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G93WQP08; Thu, 15 Mar 2001 12:23:42 -0500 Message-ID: <00a401c0ad74$de8084b0$092e0165@cst.ca> From: "Graham Gilmore" To: References: Subject: Re: Some questions raised in my recent review of RFC2445 Date: Thu, 15 Mar 2001 12:25:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Shannon J. Clark" To: Sent: 14 March, 2001 15:12 Subject: RE: Some questions raised in my recent review of RFC2445 > This is my point - there is an assumption on the part of the standards doc, > and many implementers that the majority of events will be of the sort that > cannot overlap. (I am aware of the TRANSP) > > My software is close to 100% focused on information that does NOT by default > cause conflicts - mostly notifications of possible events, but NOT > invitations to them, rather indications on your calendar that there are > multiple things occurring at the same time. In my general usage of my > calendars overlapping events are more often than not what I have on my > calendar - I am mostly concerned with what my options are - not with > deciding exactly which I will be attending (these are mostly of the category > of public type events). The assumption that you mention is probably present - its validity is, apparently, arguable (e.g. your comments :). However, the TRANSParency of an event is used for calculating responses to FREEBUSY requests. It doesn't require calendaring software to prevent users from having multiple OPAQUE events in their calendar (or even confirming their attendance at said events) occurring at the same time. In any case, as you know it is possible to specify events that don't cause conflicts via the TRANSP property, so I can't really see why the aforementioned assumption would cause any problems (if you have any specific examples, please clarify!). Are you suggesting the default value for TRANSP (being OPAQUE) be changed, or perhaps removed? Graham From owner-ietf-calendar@mail.imc.org Thu Mar 15 13:19:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04880 for ; Thu, 15 Mar 2001 13:19:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA25723 for ietf-calendar-bks; Thu, 15 Mar 2001 09:51:26 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA25719 for ; Thu, 15 Mar 2001 09:51:25 -0800 (PST) Received: from earth.in.steltor.com (earth.int.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA24128; Thu, 15 Mar 2001 12:50:56 -0500 Received: from steltor.com ([101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2FHoxT04041; Thu, 15 Mar 2001 12:50:59 -0500 (EST) Message-ID: <3AB100F5.9FAC5EA@steltor.com> Date: Thu, 15 Mar 2001 12:50:45 -0500 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Reminder: Guide to Internet Calendaring Last Call Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is to remind everyone to send their comments. We did a working group last call, and hope to submit it to submit it for a last call, as an informational RFC, at the IETF meeting. George From owner-ietf-calendar@mail.imc.org Thu Mar 15 13:19:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04883 for ; Thu, 15 Mar 2001 13:19:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA25571 for ietf-calendar-bks; Thu, 15 Mar 2001 09:46:22 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA25565 for ; Thu, 15 Mar 2001 09:46:19 -0800 (PST) Received: from earth.in.steltor.com (earth.int.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA24073; Thu, 15 Mar 2001 12:45:51 -0500 Received: from steltor.com ([101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2FHjrT03422; Thu, 15 Mar 2001 12:45:53 -0500 (EST) Message-ID: <3AB0FFC3.12BB5F40@steltor.com> Date: Thu, 15 Mar 2001 12:45:39 -0500 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CAP Issues / ToDo List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All, Here is a list of issues and todos for CAP. The main goal is to have a central list, much like Doug's old list. I compiled the list from Doug's old list, and various posts and other emails. If there are things that should be added or removed, please let me know and I will do it. BTW, the more people who review the CAP documents the better. We especially need people to check the restriction tables. George Issues: ======= - A number of issues with the various restriction tables. See CAP. - CS do not preserve data integrity. Explanation/example: someone can store a multipart/signed vEvent on their own calendar via CAP but when the owner goes to read it back the sig is gone (or its been 'resigned' by the CS). For multipart/encrypted, CS's may decrypt and later reencrypt data back but it data security/preservation is not available. A by-product of this is that when an invite arrives in your calendar scheduling queue all you will be able to tell is that your server says the data got there in some safe manner; no info as to the original signature, etc. As such anyone with a valid signature can send the calendar owner entries and the CAP server will say this was signed and CAP verified it was". In eMail you can see the senders signature (somewhere in the UI); with CAP you have no visual way to see _WHO_ signed it. Another way to look at this is: you sign and save an entry. Your AA or someone else w/access to it comes in and modifies it. You later go back and reopen the entry but you will have no visual clue as to its been changed by someone else since _I_ signed and saved it since my CAP server only says "This was really signed when it was saved". Is this OK? (from Bruce) - Security issue - mutual trust model. Is it in the draft? CAP implicitly requires some form of mutual trust model. Is this explicitly called out in the draft even though it is implict in the design? Once something is outside of a firewall it is out of your realm of control just like email. (from Bruce) - JIT signing/encryption: For some cases we may wind up having signing/encryption done by 'downstream' CS's as the request routes thru. ie: Paul @ MIT sent a REQUEST to his CS w/your CalID as 1 TARGET. He sends the data unsigned/encrypted to his CS. It sees your TARGET and by some TBD CS policy it decides that the data must be signed/encrypted so that it can go over, say, iMIP. His CS does not have his key so it simply uses its own. (Additionally, if his server fanned it out to outside the firewall before this happens, the signer/encryptor is not even his CS). So the first CS that can sign it does and then that is trackable all the way to you [after resigning by each subsequent CS in the flow path is done] (from Bruce) - "Fallback/fanout to iTIP" concerns: If CAP request must get turned into iTIP then some extra coding must occur (ie: rewriting the proper ATTENDEE and ORGANIZER values from cap://... to mailto:.. ). Since this may happen anywhere down stream from the originating CS, it is not guaranteed that the mapping/rewrites are accurate or correct; they are 'assumed' to be usable ("or the request is bounced back."). Unfortunately correctness is only positively done at the starting point and not @ Yahoo on the way to Lotus. There are also cases like signed or encrypted data that would prevent this from being either doable or run the risk of voiding the signature. (from Bruce) - The workflow path may not be a true path: The iTIP workflow path was a just that; a path (msg flow out followed same logical flow back). In CAP, if 'rerouting' over iTIP occurs then the path is now a loop (CUA1->CS1->iTIP to MUA2/CUA2->MUA1/(CUA1?). The last leg of getting iTIP/iMIP replies from the MUA1 to CUA1 so it can stuff them into CS1 in the "proper place" is just handwaved (or "left up to the user or their tools to do"). There is no clear why/how CUA1 would stuff in iTIP/iMIP messages into own queue instead of having CUA1 watch the incoming MUA1 queue for iTIP msgs and pulling them in or having CS1 rewrite the address so that msgs return to it directly. Paul or Doug state that users would only be confused (at best) or not aware of (at worse) any kind of signature msgs / warnings that they may see on their receiving end. Bruce feels email is stillok in that if my MUA can see the sig then it tells me "This msg was signed by Doug Royer and its valid". He does not think there is any usefulness in seeing "This request was signed and I, your trusted CS says its valid!" (esp. if we allow downstream servers to sign 'on your behalf' or 'at your behest' via some TBD mechanism). Is data integrity within the CS necessary? Do we trust the CS to enforce integrity or not. (from Bruce) - Look at changes required by CAP to make it compatible with CRISP - Add changes to iCalendar the are required for CAP - Do we want/need the CAP server to auto-mangle (aka autoinsert) an incoming stream of data with a generated UID? Especially if > 1 operation is going to be needed (ie: "Put this on my calendar and send invitations to the ATTENDEEs" = 1 CREATE and 1 or more other operations). Wouldn't it be simpler and more efficient to have the client request a UID and have the CAP server generate and return it (ala NNTP does with Message-IDs)?? Besides, the client will _probably_ need to have the UID for other operations (like saving in its local store if is does sync work!). (from Bruce) ToDos: ====== - Review restriction tables. - Review CAP Requirements doc to make sure that we have met all requirements. - Make sure that CAP supports synch. - Get CAP related changes into iCalendar - Resolve issues with the various methods (e.g., how does one specify a specific attachment during an update). - VTIMEZONE and IANA. (Doug's list) - Remove unused definitions (Doug's list). I assume this means that we should remove all definitions that are in the definition section, but that are not used in the text. - Document MAXSIZE and MAXRESULT (Doug's list). - Document METHOD is stored in CS database (Doug's list). - Only one 'CREATE' per UID (Doug's list). - Multiple non-CREATE per UID (Doug's list). - Fix the RESPONSE's to be consistent and multiple components, one for each TARGET (Doug's list). - Section 2.4.4.2 - editor note: We need an example (Steve/Doug). Paul needs to read this note an example. (Doug's list). - Merge changes Doug made into the doc. Some changes may no longer be appropriate (George). - Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve (Doug's list). - Section 7.1.3 Need to get IANA registration (Doug's list) - Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. (Doug's list). - Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. (Doug's list). - Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. (Doug's list). - Section 12.0 (was section 13) This section is not ready for prime time. Need Paul Hill. Need an editors note. (Doug's list). - Section 15.1.4 (now section ?) Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. (Doug's list) - Editor note: Remove references to VDATA (mistake) (Doug's list) - Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 (Doug's list) - Write ABNF for VQUERY. (George) - There were a few changes made by Doug in an interim document. These changes did not make the doc we submitted since we worked from another version of the doc. Most of these changes were new examples, or small changes to existing text. - Should we provide some kind of template to follow for all the application protocol commands (CREATE, MODIFY, etc). All we have right now is a brief description followed by an example. Is there anywhere where the syntax or form that should be followed clearly specified? Examples: ========= - search - security - fanout using iMIP - basic operations that a user may do during regular use (George) - the minimum data required to create an entry - an entire short session from login to download entries, to log out. - errors - The UIDs in our examples are different than the suggested format in iCAL. From owner-ietf-calendar@mail.imc.org Thu Mar 15 15:31:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07682 for ; Thu, 15 Mar 2001 15:31:38 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA03249 for ietf-calendar-bks; Thu, 15 Mar 2001 12:01:18 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA03244 for ; Thu, 15 Mar 2001 12:01:17 -0800 (PST) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2FK1Jf20519 for ; Thu, 15 Mar 2001 12:01:20 -0800 (PST) Received: from netscape.com (dhcp-blv02-43.West.Sun.COM [129.153.115.43]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id MAA23044968 for ; Thu, 15 Mar 2001 12:06:30 -0800 (PST) Message-ID: <3AB11F7F.F13767AF@netscape.com> Date: Thu, 15 Mar 2001 12:01:03 -0800 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: comments on implementors guide Content-Type: multipart/mixed; boundary="------------1518DD4756FC75DA48D575DA" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1518DD4756FC75DA48D575DA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Definitions appear in both the implementors guide and in CAP. There's a potential for them to get out of sync. But I understand why you would put them in this guide. You mention iRIP. You should pull that. Perhaps replace it with CRISP. This will affect several paragraphs throughout the doc. Your sample Lunch event does not have a UID Your iMIP example is missing the METHOD property. Middle of page 6, there are 3 separate paragraphs that describe cap that look like they say the same thing. Page 6, first CAP example. No UID in the event. The response from the CAP server looks wrong. johns in the request is changed to johnd in the reply. I'm also confused about why you get a response for 2 calendars when the component was only targeted to one calendar. BTW, I love the little character people in the diagrams. Can't tell if they're anatomically correct. I'm about halfway through. I'll try to finish it up later today and send more comments. -Steve --------------1518DD4756FC75DA48D575DA Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------1518DD4756FC75DA48D575DA-- From owner-ietf-calendar@mail.imc.org Thu Mar 15 16:56:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09026 for ; Thu, 15 Mar 2001 16:56:16 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA09446 for ietf-calendar-bks; Thu, 15 Mar 2001 13:39:25 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA09441 for ; Thu, 15 Mar 2001 13:39:24 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2FLk6M09290 for ; Thu, 15 Mar 2001 16:46:06 -0500 Message-ID: <3AB1381E.75EEE283@ecal.com> Date: Thu, 15 Mar 2001 16:46:06 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> <3AB0DB88.AFFDA196@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > Damon Chaplin wrote: > > > If you're right about iTIP problems, then it looks like it is impossible to > > resolve conflicts. This also suggests using a product ID and version in the TZID > > like I proposed so we avoid conflicts. > > Mmm, no, I don't think that would help, necessarily. What I meant to add, and didn't: product IDs are pretty unreliable in the first place (consider HTTP User-Agent:); and they get worse if different installations of the product may have different sets of timezone data. For example, a Unix CUA might extract the system timezone information and send that out as VTIMEZONEs; the definition of each VTIMEZONE then depends on the OS version as well as the product version. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |E pui muove! -- Galileo | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 15 17:29:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09413 for ; Thu, 15 Mar 2001 17:29:41 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA11540 for ietf-calendar-bks; Thu, 15 Mar 2001 14:12:48 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA11533 for ; Thu, 15 Mar 2001 14:12:46 -0800 (PST) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA29209 for ; Thu, 15 Mar 2001 17:12:19 -0500 Received: from pc152 (PC-152 [101.1.46.9]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G93WQRSJ; Thu, 15 Mar 2001 17:10:54 -0500 Message-ID: <003f01c0ad9c$fe98bce0$092e0165@cst.ca> From: "Graham Gilmore" To: References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> <3AB0DB88.AFFDA196@ecal.com> <3AB1381E.75EEE283@ecal.com> Subject: Re: Timezone TZID clashes Date: Thu, 15 Mar 2001 17:12:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Stracke" To: Sent: 15 March, 2001 16:46 Subject: Re: Timezone TZID clashes > John Stracke wrote: > > > Damon Chaplin wrote: > > > > > If you're right about iTIP problems, then it looks like it is impossible to > > > resolve conflicts. This also suggests using a product ID and version in the TZID > > > like I proposed so we avoid conflicts. > > > > Mmm, no, I don't think that would help, necessarily. > > What I meant to add, and didn't: product IDs are pretty unreliable in the first place > (consider HTTP User-Agent:); and they get worse if different installations of the > product may have different sets of timezone data. For example, a Unix CUA might > extract the system timezone information and send that out as VTIMEZONEs; the definition > of each VTIMEZONE then depends on the OS version as well as the product version. The point of adding the product IDs would be to ensure the uniqueness of a TZID received from an external source (or at least, unique with respect to a CUA's own internal timezones), not to allow a CUA to infer that given the product IDs are the same, therefore the TZIDs with the same name refer to identical information. It basically boils down to, "ok this doesn't come from me - I'd better ignore the TZID/TZNAME and look only at the actual rule content." And maybe the first part of that phrase is even assuming too much. On the other hand, tacking the PRODUCTID on to the TZID starts to become very close, in spirit, at least, to violating section 4.7.3 of the RFC which states "This property [PRODUCTID] SHOULD not be used to alter the interpretation of an iCalendar object beyond the semantics specified in this memo. For example, it is not to be used to further the understanding of non-standard properties." Maybe generating a new UID for the TZID each time one is needed by a VTIMEZONE would be a good way to do it. Graham From owner-ietf-calendar@mail.imc.org Thu Mar 15 17:32:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09471 for ; Thu, 15 Mar 2001 17:32:32 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA11758 for ietf-calendar-bks; Thu, 15 Mar 2001 14:15:57 -0800 (PST) Received: from cmailg5.svr.pol.co.uk (cmailg5.svr.pol.co.uk [195.92.195.175]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA11753 for ; Thu, 15 Mar 2001 14:15:56 -0800 (PST) Received: from modem-65.north-dakota.dialup.pol.co.uk ([62.137.85.65] helo=ximian.com) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14dg29-00030m-00; Thu, 15 Mar 2001 22:15:50 +0000 Message-ID: <3AB10173.37AC331D@ximian.com> Date: Thu, 15 Mar 2001 17:52:51 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: "ietf-calendar@imc.org" Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> <3AB0DB88.AFFDA196@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > Damon Chaplin wrote: > > > If the app loads/receives an iCalendar file with, for example, a "Europe/London" > > VTIMEZONE calendar component, and the user then creates another time with the > > timezone set to "Europe/London", then we have 2 "Europe/London" VTIMEZONE > > components to place in the iCalendar file. > > OK, yeah, in that case, the CUA may need to put them both in, and rename one of > them. A slightly smarter CUA, though, would check to see whether the existing > VTIMEZONE agrees with the one it knows. > > > If you're right about iTIP problems, then it looks like it is impossible to > > resolve conflicts. This also suggests using a product ID and version in the TZID > > like I proposed so we avoid conflicts. > > Mmm, no, I don't think that would help, necessarily. Why not? If you have a unique product ID and a unique VTIMEZONE version number in the TZID, then how can you have a conflict? > > One other thing I forgot is that currently VTIMEZONE components only have to > > cover the time range used within the iCalendar file. > > I really can't see any sensible implementation automatically narrowing down the > VTIMEZONE it sends out. It's going to be much more efficient just to send the > component taken from its configuration; working up an algorithm to reduce that > component to just what's necessary to cover a certain range would be ludicrously > painful. Besides, what happens if the recipient COUNTERs with a time outside that > original range, a time at which the original VTIMEZONE disagrees with the reduced > one? > > > So I think it is better if a VTIMEZONE component must cover the entire time range. > > Er...but define "the entire time range". From now until the end of time? > > I would say instead: a CUA SHOULD send VTIMEZONE components which cover as large a > time range as the CUA knows for that timezone. Yep. Of course timezones change over time so you'll have to release new versions of the VTIMEZONE components, which is why I wanted to put a version number in the TZID. Damon From owner-ietf-calendar@mail.imc.org Thu Mar 15 17:38:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09604 for ; Thu, 15 Mar 2001 17:38:38 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA12316 for ietf-calendar-bks; Thu, 15 Mar 2001 14:23:34 -0800 (PST) Received: from cmailg5.svr.pol.co.uk (cmailg5.svr.pol.co.uk [195.92.195.175]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA12309 for ; Thu, 15 Mar 2001 14:23:32 -0800 (PST) Received: from modem-65.north-dakota.dialup.pol.co.uk ([62.137.85.65] helo=ximian.com) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14dg9c-00055f-00; Thu, 15 Mar 2001 22:23:32 +0000 Message-ID: <3AB140C1.3E84A2EF@ximian.com> Date: Thu, 15 Mar 2001 22:22:57 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: "ietf-calendar@imc.org" Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> <3AB0DB88.AFFDA196@ecal.com> <3AB1381E.75EEE283@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > John Stracke wrote: > > > Damon Chaplin wrote: > > > > > If you're right about iTIP problems, then it looks like it is impossible to > > > resolve conflicts. This also suggests using a product ID and version in the TZID > > > like I proposed so we avoid conflicts. > > > > Mmm, no, I don't think that would help, necessarily. > > What I meant to add, and didn't: product IDs are pretty unreliable in the first place > (consider HTTP User-Agent:); and they get worse if different installations of the > product may have different sets of timezone data. For example, a Unix CUA might > extract the system timezone information and send that out as VTIMEZONEs; the definition > of each VTIMEZONE then depends on the OS version as well as the product version. That's true, but if we specify that the product ID and version number are supposed to uniquely identify the VTIMEZONE data, then if an application doesn't do that it doesn't conform to the spec. Does anyone have any better ideas for resolving TZID clashes? (I'm supposed to have this all implemented in the next few weeks so think fast!) Damon From owner-ietf-calendar@mail.imc.org Thu Mar 15 17:56:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09870 for ; Thu, 15 Mar 2001 17:56:16 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA13634 for ietf-calendar-bks; Thu, 15 Mar 2001 14:41:20 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA13629 for ; Thu, 15 Mar 2001 14:41:18 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2FMm1M09607 for ; Thu, 15 Mar 2001 17:48:01 -0500 Message-ID: <3AB146A0.BE13861E@ecal.com> Date: Thu, 15 Mar 2001 17:48:00 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> <3AB0DB88.AFFDA196@ecal.com> <3AB1381E.75EEE283@ecal.com> <003f01c0ad9c$fe98bce0$092e0165@cst.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Graham Gilmore wrote: > The point of adding the product IDs would be to ensure the > uniqueness of a TZID received from an external source Can't do that either. If I use iTIP to invite two people using CUAs which are the same product and version, I can't be sure that they've got the same set of timezones. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Whose cruel idea was it for the word "lisp" to| |francis@ecal.com|have an "S" in it? | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Mar 15 17:57:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09892 for ; Thu, 15 Mar 2001 17:57:00 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id OAA13938 for ietf-calendar-bks; Thu, 15 Mar 2001 14:43:05 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA13933 for ; Thu, 15 Mar 2001 14:43:03 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2FMnkM09611 for ; Thu, 15 Mar 2001 17:49:46 -0500 Message-ID: <3AB14709.F167092C@ecal.com> Date: Thu, 15 Mar 2001 17:49:45 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> <3AB0DB88.AFFDA196@ecal.com> <3AB1381E.75EEE283@ecal.com> <3AB140C1.3E84A2EF@ximian.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Damon Chaplin wrote: > That's true, but if we specify that the product ID and version number are supposed to > uniquely identify the VTIMEZONE data, then if an application doesn't do that it doesn't > conform to the spec. But it's not *possible*. A CUA which gets its timezone data from an external source (even a data file packaged with the app) cannot be sure that they haven't changed from one invocation of the program to the next. If we were going to issue standards mandating the impossible, we wouldn't be engineers; we'd be politicians. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"If there's anything The Flintstones have taught| |francis@ecal.com|us, it's that pelicans can be used to mix | | |cement." -- Homer Simpson | \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri Mar 16 08:22:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02984 for ; Fri, 16 Mar 2001 08:22:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA17179 for ietf-calendar-bks; Fri, 16 Mar 2001 05:07:31 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA17174 for ; Fri, 16 Mar 2001 05:07:29 -0800 (PST) Received: from GregPc (unknown [193.14.119.115]) by ljudo.shortlist.se (Postfix) with SMTP id 20624B3571; Fri, 16 Mar 2001 14:07:23 +0100 (CET) From: "Greg FitzPatrick" To: , Cc: , Subject: SV: SKiCal CONTROL Date: Fri, 16 Mar 2001 14:06:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce wrote: >Perhaps "legally responsible" is not quite 100% on the mark but it seems relatively clear to me. Well we used to say the "WhoDoUsue" Is that better?-) Bruce: >But what does it mean if I have 2 VEVENTs (or 1 VEVENT and 1 VTODO) and only one has CONTROLs on it >and the other is RELATED-TO it? Is there any "guilt by association" or is responsibility ONLY valid >if it specified on the entity? RELATED-TO describes a relationship between calendar objects and is an essential tool in 2445 for the coupling of multi-events. They can not be described otherwise. In the case where a particular property has a stated value in one object and a null in its related-to counterpart, then the inference that the stated value "overrules" the null or vice versa, would have to be made be by the interpreting application. Since this could create dual (or more) values for every single property, there are some potential collisions here that we should perhaps consider - and not just for CONTROL! But if you recall, the SKiCal group has submitted the property: PARTREL (see below.) This relationship differs from RELATED-TO as described below. graphically: RELATED-TO descriptor <-------> descriptor | | | | v PARTREL v event <-------> event To be frank, I don't remember us ever considering inheritance of values in this scheme of things. I suppose that we took for granted that no inheritances could be inferred. Of course this is something you could solve in XML with idrefs. In any case I am glad the topic came up, we must always proceed with caution:-) Property Name: PARTREL Purpose: This property specifies another SKiSource, to which the SKiSource being declared is related. This does not imply an inheritance of properties from the external SKiSource given as a value but rather a relevance. Value Type: TEXT. (SKUID for another SKiCal/iCalendar object.) Property Parameters: Non-standard property parameters can be specified on this property. It is RECOMMENDED that a Common Name parameter (cnparam) be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: This property allows for the publisher of a SKiSource to indicate that the SKiSource is related to another SKiSource, such as a festival or a package of tourist attractions. This property differs from the RELATED-TO property of RFC-2445, since that property defines a relationship between calendar objects describing SKiSources and not between SKiSources themselves. Format Definition: The property is defined by the following notation:
partrel = "PARTREL" partrelparam ":" text CRLF partrelparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparam ) / (";" cnparam ) / (";" reltypeparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) )
Example: The following are examples of this property:
artwork> PARTREL;CN=2004 Winter Olympics:<19991202@olympic.org> PARTREL;RELTYPE=SIBLING: ]]>
From owner-ietf-calendar@mail.imc.org Fri Mar 16 10:59:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05553 for ; Fri, 16 Mar 2001 10:59:36 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA29716 for ietf-calendar-bks; Fri, 16 Mar 2001 07:48:52 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29711 for ; Fri, 16 Mar 2001 07:48:50 -0800 (PST) Received: from earth.in.steltor.com (earth.int.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id KAA04173; Fri, 16 Mar 2001 10:48:20 -0500 Received: from steltor.com ([101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2GFmMT21910; Fri, 16 Mar 2001 10:48:22 -0500 (EST) Message-ID: <3AB235B3.A7787CA5@steltor.com> Date: Fri, 16 Mar 2001 10:48:03 -0500 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: comments on implementors guide References: <3AB11F7F.F13767AF@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for the comments! Steve Mansour wrote: > > Hi, > > Definitions appear in both the implementors guide and in CAP. There's a > potential for them to get out of sync. But I understand why you would > put them in this guide. > > You mention iRIP. You should pull that. Perhaps replace it with CRISP. > This will affect several paragraphs throughout the doc. I noticed this a couple of days ago. We forgot to remove them when iRIP was dropped. > > Your sample Lunch event does not have a UID Yep. All the examples are missing a UID. I'll put them in. > > Your iMIP example is missing the METHOD property. Its also missing a DTSTAMP. I'll also put in a SEQUENCE of 0. (Even though, if 0, it is not required). > > Middle of page 6, there are 3 separate paragraphs that describe cap that > look like they say the same thing. Yes, I'll fix this. > > Page 6, first CAP example. No UID in the event. > > The response from the CAP server looks wrong. johns in the request is > changed to johnd in the reply. I'm also confused about why you get a > response for 2 calendars when the component was only targeted to one > calendar. It was targeted to two calendars: TARGET:cap://cal.example.com/johns TARGET:janed > > BTW, I love the little character people in the diagrams. Can't tell if > they're anatomically correct. > > I'm about halfway through. I'll try to finish it up later today and send > more comments. > > -Steve From owner-ietf-calendar@mail.imc.org Fri Mar 16 11:21:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06194 for ; Fri, 16 Mar 2001 11:21:52 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA01704 for ietf-calendar-bks; Fri, 16 Mar 2001 08:07:48 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA01699 for ; Fri, 16 Mar 2001 08:07:47 -0800 (PST) From: par.lannero@metamatrix.se Received: from finnegan.metamatrix.se (finnegan.metamatrix.se [193.14.119.142]) by ljudo.shortlist.se (Postfix) with ESMTP id 8A976B3572 for ; Fri, 16 Mar 2001 17:07:47 +0100 (CET) Date: Fri, 16 Mar 2001 17:07:47 +0100 (CET) X-Sender: To: Subject: SKICal PERSONS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Continuing to present SKICal properties one by one (6 more to go, I think :) Property Name: PERSONS Purpose: To facilitate for TimeSpenders the discovery of resource-entities relating to specific people - living or dead. Value Type: TEXT. Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: Persons at a SKiSource might be a shop keeper, waiter, hostess, artist, a sports team, a guide, a disc jockey or a master of ceremonies and so forth. This property specifies named persons associated with the SKiSource, working at the SKiSource or present at the SKiSource. Persons expected to perform or participate, act or speak, contribute in person to the SKiSource - or to be honored, referenced, criticized etc., in absence. Format Definition: The property is defined by the following notation: persons = "PERSONS" personsparam ":" text CRLF ; It is RECOMMENDED that the text value be ; chosen from a list, as described in Section 5 ; of this memo. personsparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparam ) / (";" personroleparam ) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: PERSONS;SKiROLE=PERFORMER:Madonna PERSONS;SKiROLE=COMMEMORATED:Madonna PERSONS:Victor Borge PERSONS;SKiROLE=Clarinetist:Woody Allen PERSONS;SKiROLE=PRESENT:The Queen of Spain PERSONS;SKiROLE=PERFORMER;LANGUAGE=sv:AIK a-laget i fotboll PERSONS;SKiROLE=INVITED:the Hawthorn High School class of 1982 PERSONS;SKiROLE=REFERENCED:Nelson Mandela PERSONS;SKiROLE=STUDIED:Socrates PERSONS;SKiROLE=HOSTESS:Martha Edwards -- ----- Par Lannero ------------ Ny mobiltelefon: 0739-442043 ----- ----- par.lannero@metamatrix.se -------- icq:306436 ------------- From owner-ietf-calendar@mail.imc.org Fri Mar 16 11:27:26 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06299 for ; Fri, 16 Mar 2001 11:27:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA02030 for ietf-calendar-bks; Fri, 16 Mar 2001 08:12:52 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02025 for ; Fri, 16 Mar 2001 08:12:50 -0800 (PST) From: par.lannero@metamatrix.se Received: from finnegan.metamatrix.se (finnegan.metamatrix.se [193.14.119.142]) by ljudo.shortlist.se (Postfix) with ESMTP id 4B6C6B3573 for ; Fri, 16 Mar 2001 17:12:50 +0100 (CET) Date: Fri, 16 Mar 2001 17:12:50 +0100 (CET) X-Sender: To: Subject: SKICal THINKS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Property Name: THINKS Purpose: To facilitate for TimeSpenders the discovery of resource-entities relating to specific topics and areas of interest. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: Could be a theory, revelation, philosophy etc. This property specifies an idea, philosophy or concept, theme, discipline etc.. Format Definition: The property is defined by the following notation: thinks = "THINKS" thinksparam ":" text CRLF ; It is RECOMMENDED that the text value be ; chosen from a list, as described in Section 5 ; of this memo. thinksparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparam ) /(";" thinksroleparam ) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: THINKS:World Peace THINKS;SKiROLE=STUDIED:Our business strategy for the new millennium THINKS;SKiROLE=ANALYZED:The work of George Lucas THINKS:Christianity, Buddhism THINKS:Transaction Cost Economics ----- Par Lannero ------------ Ny mobiltelefon: 0739-442043 ----- ----- par.lannero@metamatrix.se -------- icq:306436 ------------- From owner-ietf-calendar@mail.imc.org Fri Mar 16 11:30:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06353 for ; Fri, 16 Mar 2001 11:30:30 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA02268 for ietf-calendar-bks; Fri, 16 Mar 2001 08:17:09 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02260 for ; Fri, 16 Mar 2001 08:17:08 -0800 (PST) From: par.lannero@metamatrix.se Received: from finnegan.metamatrix.se (finnegan.metamatrix.se [193.14.119.142]) by ljudo.shortlist.se (Postfix) with ESMTP id 1308AB3572 for ; Fri, 16 Mar 2001 17:17:09 +0100 (CET) Date: Fri, 16 Mar 2001 17:17:09 +0100 (CET) X-Sender: To: Subject: SKICal THINGS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Property Name: THINGS Purpose: To facilitate for TimeSpenders the discovery of resource-entities relating to objects, things, specific goods and products, collectors items, various commodities and so forth. Value Type: TEXT. Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: Things pertaining to a resource-entity. For example; books, paintings, furniture, Gucci Handbags, Wrangler Jeans, famous wines. This property specifies things of significance exhibited, featured, for sale, for-auction, for-rent, to be given away or observed at the resource-entity. . Format Definition: The property is defined by the following notation: things = "THINGS" thingsparam ":" text CRLF ; It is RECOMMENDED that the text value be ; chosen from a list, as described in Section 5 ; of this memo. thingsparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" languageparam ) / (";" thingroleparam ) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: THINGS;SKiROLE=LECTURED-ON:German Antiques THINGS;SKiROLE=FOR-SALE:German Antiques THINGS;SKiROLE=APPRAISED:German Antiques THINGS;LANGUAGE=sv:Fritidsbatar THINGS;SKiROLE=LECTURED-ON:Ming Dynasty Porcelain THINGS;SKiROLE=SERVED:Thai cuisine THINGS;SKiROLE=AUCTIONED:The Vanderbilt Jewels THINGS;SKiROLE=REFERENCED:The holy Grail -- ----- Par Lannero ------------ Ny mobiltelefon: 0739-442043 ----- ----- par.lannero@metamatrix.se -------- icq:306436 ------------- From owner-ietf-calendar@mail.imc.org Fri Mar 16 12:06:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07322 for ; Fri, 16 Mar 2001 12:06:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA03391 for ietf-calendar-bks; Fri, 16 Mar 2001 08:51:25 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA03387 for ; Fri, 16 Mar 2001 08:51:24 -0800 (PST) From: Bruce_Kahn@iris.com To: "Greg FitzPatrick" Cc: Frank.Dawson@nokia.com, ietf-calendar@imc.org, par.lannero@metamatrix.se Subject: Re: SV: SKiCal CONTROL MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Fri, 16 Mar 2001 11:53:09 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/16/2001 11:56:22 AM, Serialize complete at 03/16/2001 11:56:22 AM Content-Type: multipart/alternative; boundary="=_alternative 005C5D3D85256A11_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C5D3D85256A11_= Content-Type: text/plain; charset="us-ascii" [Caveat: somewhat long response and 1 digression included] Greg answered: >In the case where a particular property has a stated >value in one object and a null in its related-to counterpart, then the >inference that the stated value "overrules" the null or vice versa, would >have to be made be by the interpreting application. Let me clarify something about my frame of reference when I asked all those questions: in RFC 2445 the RELATED-TO is simply used for 'linking' entries to each other but NOT used for inheriting values. Since CONTROL is something that has a very direct legal impact/use I wanted to see if it A) would inherit values (it was not clear or ruled out) and B) if so, just how should this be dealt with. The only useful text in 2445 about the use of relationship is: Changes to a calendar component referenced by this property can have an implicit impact on the related calendar component. For example, if a group event changes its start or end date or time, then the related, dependent events will need to have their start and end dates changed in a corresponding way. Similarly, if a PARENT calendar component is canceled or deleted, then there is an implied impact to the related CHILD calendar components. This property is intended only to provide information on the relationship of calendar components. It is up to the target calendar system to maintain any property implications of this relationship. This is more than a bit vague and probably on purpose since not all C&S systems have the concept of 'linked' or related events so we cannot mandate it in the RFC. The only real description of any kind of impact is changes like scheduling, not of value inheritance. Im a bit unclear if the impact is bi-directional (ie: changes to the CHILD are reflected in the PARENT) but thats a digression Eric: Put these on the Issues List please. Do we need all these linkage types if they have no real impact? That is: If I know my PARENT and can get their CHILDren then why do I need a SIBLING since it has no impact on me? Does a PARENT have to have a CHILD link on it too (or visa versa)? Perhaps the 1st line should be changed to: Changes to a calendar component referenced by this property can have an implicit impact on the related dependent calendar component(s). and the SIBLING relationship removed (for simplicity reasons). Also the following text is VERY misleading: For example, if a group event changes its start or end date or time, then the related, dependent events will need to have their start and end dates changed in a corresponding way. in that if the CHILD has its own distinct start/end date and time. It MAY need to be updated at the users discression, not automatically so "will need to have" is not always true or accurate. >Since this could create dual (or more) values for every single property, >there are some potential collisions here that we should perhaps consider - >and not just for CONTROL! Being of the KISS mindset I think you should NOT add it in; you should require the data to be expressly put in ALL 'related' or "linked' entries. That way there is no confusion or inaccurate assumptions made. >This property differs from the >RELATED-TO property of RFC-2445, since >that property defines a relationship between calendar objects describing >SKiSources and not between SKiSources themselves. Im not groking your definition of a SKiSource compared to the entry represented by, say, a VEVENT in iCalendar. So the distiction between RELATED-TO and PARTREL is nonexistant to me. Can you differentiate it better (at least for me)?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005C5D3D85256A11_= Content-Type: text/html; charset="us-ascii"
[Caveat: somewhat long response and 1 digression included]

Greg answered:
>In the case where a particular property has a stated
>value in one object and a null in its related-to counterpart, then the
>inference that the stated value "overrules" the null or vice versa, would
>have to be made be by the interpreting application.

Let me clarify something about my frame of reference when I asked all those questions: in RFC 2445 the RELATED-TO is simply used for 'linking' entries to each other but NOT used for inheriting values.  Since CONTROL is something that has a very direct legal impact/use I wanted to see if it A) would inherit values (it was not clear or ruled out) and B) if so, just how should this be dealt with.  

The only useful text in 2445 about the use of relationship is:

   Changes to a calendar component referenced by this property can have
  an implicit impact on the related calendar component. For example, if
  a group event changes its start or end date or time, then the
  related, dependent events will need to have their start and end dates
  changed in a corresponding way. Similarly, if a PARENT calendar
  component is canceled or deleted, then there is an implied impact to
  the related CHILD calendar components. This property is intended only
  to provide information on the relationship of calendar components. It
  is up to the target calendar system to maintain any property
  implications of this relationship.

This is more than a bit vague and probably on purpose since not all C&S systems have the concept of 'linked' or related events so we cannot mandate it in the RFC.  The only real description of any kind of impact is changes like scheduling, not of value inheritance.   Im a bit unclear if the impact is bi-directional (ie: changes to the CHILD are reflected in the PARENT) but thats a digression
<DIGRESSION TO ISSUES LIST>
Eric: Put these on the Issues List please.  Do we need all these linkage types if they have no real impact?  That is: If I know my PARENT and can get their CHILDren then why do I need a SIBLING since it has no impact on me?  Does a PARENT have to have a CHILD link on it too (or visa versa)?  Perhaps the 1st line should be changed to:

   Changes to a calendar component referenced by this property can have
  an implicit impact on the related dependent calendar component(s).

and the SIBLING relationship removed (for simplicity reasons).  Also the following text is VERY misleading:
                                                      For example, if
  a group event changes its start or end date or time, then the
  related, dependent events will need to have their start and end dates
  changed in a corresponding way.

in that if the CHILD has its own distinct start/end date and time.  It MAY need to be updated at the users discression, not automatically so "will need to have" is not always true or accurate.
</DIGRESSION TO ISSUES LIST>

>Since this could create dual (or more) values for every single property,
>there are some potential collisions here that we should perhaps consider -
>and not just for CONTROL!

Being of the KISS mindset I think you should NOT add it in; you should require the data to be expressly put in ALL 'related' or "linked' entries.  That way there is no confusion or inaccurate assumptions made.

>This property differs from the
>RELATED-TO property of <xref target="refs.RFC2445">RFC-2445</xref>, since
>that property defines a relationship between calendar objects describing
>SKiSources and not between SKiSources themselves.

Im not groking your definition of a SKiSource compared to the entry represented by, say, a VEVENT in iCalendar.  So the distiction between RELATED-TO and  PARTREL is nonexistant to me.  Can you differentiate it better (at least for me)??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005C5D3D85256A11_=-- From owner-ietf-calendar@mail.imc.org Fri Mar 16 12:40:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07670 for ; Fri, 16 Mar 2001 12:40:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA03992 for ietf-calendar-bks; Fri, 16 Mar 2001 09:24:46 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03988 for ; Fri, 16 Mar 2001 09:24:42 -0800 (PST) From: par.lannero@metamatrix.se Received: from finnegan.metamatrix.se (finnegan.metamatrix.se [193.14.119.142]) by ljudo.shortlist.se (Postfix) with ESMTP id 4567FB3572; Fri, 16 Mar 2001 18:24:43 +0100 (CET) Date: Fri, 16 Mar 2001 18:24:43 +0100 (CET) X-Sender: To: Lisa Lix Cc: , Subject: RE: SKICal PERSONS In-Reply-To: <45FFD0863780BF48856035CBD7E450C1D4DEF4@red-msg-02.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id JAA03992 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07670 On Fri, 16 Mar 2001, Lisa Lix wrote: > How do I get off this list?: ietf-calendar@imc.org > > I'm a new employee to Microsoft and I'm getting a ton of messages as a > result. PLEASE let me know. Thanks. You must have gotten the previous email address of Lisa Dusseault (Cc) who used to be active on this list. "To subscribe to the mailing list, send a message to ietf-calendar-request@imc.org with the single word subscribe in the body of the message. To unsubscribe from the list, use that same address with the single word unsubscribe in the body of the message." /Pär > > -----Original Message----- > From: par.lannero@metamatrix.se [mailto:par.lannero@metamatrix.se] > Sent: Friday, March 16, 2001 8:08 AM > To: ietf-calendar@imc.org > Subject: SKICal PERSONS > > > > Continuing to present SKICal properties one by one > (6 more to go, I think :) > > > > Property Name: PERSONS > > Purpose: To facilitate for TimeSpenders the discovery of > resource-entities relating to specific people - living or dead. > > Value Type: TEXT. > > Property Parameters: Non-standard property parameters can be > specified on this property. > > Conformance: This property CAN be specified within a "VEVENT" > calendar component. > > Description: Persons at a SKiSource might be a shop keeper, waiter, > hostess, artist, a sports team, a guide, a disc jockey or a > master of ceremonies and so forth. This property specifies named > persons associated with the SKiSource, working at the SKiSource > or present at the SKiSource. Persons expected to perform or > participate, act or speak, contribute in person to the SKiSource - > or to be honored, referenced, criticized etc., in absence. > > Format Definition: The property is defined by the following > notation: > > persons = "PERSONS" personsparam ":" text CRLF > ; It is RECOMMENDED that the text value be > ; chosen from a list, as described in Section 5 > ; of this memo. > > personsparam = *( > ; the following is optional, > ; but MUST NOT occur more than once > (";" languageparam ) / > (";" personroleparam ) / > ; the following is optional, > ; and MAY occur more than once > (";" xparam) ) > > Example: The following are examples of this property: > > PERSONS;SKiROLE=PERFORMER:Madonna > PERSONS;SKiROLE=COMMEMORATED:Madonna > PERSONS:Victor Borge > PERSONS;SKiROLE=Clarinetist:Woody Allen > PERSONS;SKiROLE=PRESENT:The Queen of Spain > PERSONS;SKiROLE=PERFORMER;LANGUAGE=sv:AIK a-laget i fotboll > PERSONS;SKiROLE=INVITED:the Hawthorn High School class of 1982 > PERSONS;SKiROLE=REFERENCED:Nelson Mandela > PERSONS;SKiROLE=STUDIED:Socrates > PERSONS;SKiROLE=HOSTESS:Martha Edwards > > > > > -- ----- Par Lannero ------------ Ny mobiltelefon: 0739-442043 ----- ----- par.lannero@metamatrix.se -------- icq:306436 ------------- From owner-ietf-calendar@mail.imc.org Fri Mar 16 15:03:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10184 for ; Fri, 16 Mar 2001 15:03:14 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id LAA09787 for ietf-calendar-bks; Fri, 16 Mar 2001 11:41:10 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.9.3/8.9.3) with SMTP id LAA09778 for ; Fri, 16 Mar 2001 11:41:07 -0800 (PST) Received: from 157.54.9.101 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Mar 2001 09:15:59 -0800 (Pacific Standard Time) Received: from red-msg-02.redmond.corp.microsoft.com ([157.54.12.70]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 16 Mar 2001 09:12:37 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SKICal PERSONS Date: Fri, 16 Mar 2001 09:15:56 -0800 Message-ID: <45FFD0863780BF48856035CBD7E450C1D4DEF4@red-msg-02.redmond.corp.microsoft.com> Thread-Topic: SKICal PERSONS Thread-Index: AcCuM7/GYJzN1Z/kT4GDlTkGUyWakQACMSfA From: "Lisa Lix" To: , X-OriginalArrivalTime: 16 Mar 2001 17:12:37.0807 (UTC) FILETIME=[4CEA53F0:01C0AE3C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id LAA09780 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit How do I get off this list?: ietf-calendar@imc.org I'm a new employee to Microsoft and I'm getting a ton of messages as a result. PLEASE let me know. Thanks. -----Original Message----- From: par.lannero@metamatrix.se [mailto:par.lannero@metamatrix.se] Sent: Friday, March 16, 2001 8:08 AM To: ietf-calendar@imc.org Subject: SKICal PERSONS Continuing to present SKICal properties one by one (6 more to go, I think :) Property Name: PERSONS Purpose: To facilitate for TimeSpenders the discovery of resource-entities relating to specific people - living or dead. Value Type: TEXT. Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: Persons at a SKiSource might be a shop keeper, waiter, hostess, artist, a sports team, a guide, a disc jockey or a master of ceremonies and so forth. This property specifies named persons associated with the SKiSource, working at the SKiSource or present at the SKiSource. Persons expected to perform or participate, act or speak, contribute in person to the SKiSource - or to be honored, referenced, criticized etc., in absence. Format Definition: The property is defined by the following notation: persons = "PERSONS" personsparam ":" text CRLF ; It is RECOMMENDED that the text value be ; chosen from a list, as described in Section 5 ; of this memo. personsparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparam ) / (";" personroleparam ) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: PERSONS;SKiROLE=PERFORMER:Madonna PERSONS;SKiROLE=COMMEMORATED:Madonna PERSONS:Victor Borge PERSONS;SKiROLE=Clarinetist:Woody Allen PERSONS;SKiROLE=PRESENT:The Queen of Spain PERSONS;SKiROLE=PERFORMER;LANGUAGE=sv:AIK a-laget i fotboll PERSONS;SKiROLE=INVITED:the Hawthorn High School class of 1982 PERSONS;SKiROLE=REFERENCED:Nelson Mandela PERSONS;SKiROLE=STUDIED:Socrates PERSONS;SKiROLE=HOSTESS:Martha Edwards -- ----- Par Lannero ------------ Ny mobiltelefon: 0739-442043 ----- ----- par.lannero@metamatrix.se -------- icq:306436 ------------- From owner-ietf-calendar@mail.imc.org Fri Mar 16 16:21:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13299 for ; Fri, 16 Mar 2001 16:21:55 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA14351 for ietf-calendar-bks; Fri, 16 Mar 2001 13:04:40 -0800 (PST) Received: from cmailg4.svr.pol.co.uk (cmailg4.svr.pol.co.uk [195.92.195.174]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA14346 for ; Fri, 16 Mar 2001 13:04:39 -0800 (PST) Received: from modem-91.golden-cleaner.dialup.pol.co.uk ([62.137.19.91] helo=ximian.com) by cmailg4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14e1Oo-0003ju-00; Fri, 16 Mar 2001 21:04:39 +0000 Message-ID: <3AB27EF3.869CC39A@ximian.com> Date: Fri, 16 Mar 2001 21:00:35 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: "ietf-calendar@imc.org" Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> <3AB0DB88.AFFDA196@ecal.com> <3AB1381E.75EEE283@ecal.com> <3AB140C1.3E84A2EF@ximian.com> <3AB14709.F167092C@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > Damon Chaplin wrote: > > > That's true, but if we specify that the product ID and version number are supposed to > > uniquely identify the VTIMEZONE data, then if an application doesn't do that it doesn't > > conform to the spec. > > But it's not *possible*. A CUA which gets its timezone data from an external source (even a > data file packaged with the app) cannot be sure that they haven't changed from one > invocation of the program to the next. If we were going to issue standards mandating the > impossible, we wouldn't be engineers; we'd be politicians. I'm not sure that is a problem. But I've just realized that a malicious app could use a fake product id and version number in an iTIP message and mess up an applications VTIMEZONEs, so my idea won't work. So I'm now back to renaming TZIDs when they clash. So we'd better check that iTIP can handle renamed TZIDs OK. Damon From owner-ietf-calendar@mail.imc.org Sat Mar 17 11:21:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07417 for ; Sat, 17 Mar 2001 11:21:56 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA03330 for ietf-calendar-bks; Sat, 17 Mar 2001 07:57:24 -0800 (PST) Received: from guanabana.ximian.com (IDENT:root@customer-148-223-152-205.uninet.net.mx [148.223.152.205] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA03324 for ; Sat, 17 Mar 2001 07:57:21 -0800 (PST) Received: (from federico@localhost) by guanabana.ximian.com (8.9.3/8.9.3) id VAA07913; Fri, 16 Mar 2001 21:01:31 -0600 Date: Fri, 16 Mar 2001 21:01:31 -0600 Message-Id: <200103170301.VAA07913@guanabana.ximian.com> X-Authentication-Warning: guanabana.ximian.com: federico set sender to federico@ximian.com using -f From: Federico Mena Quintero X-plosion: kaboom To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> <3AB0DB88.AFFDA196@ecal.com> <3AB1381E.75EEE283@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Stracke writes: > What I meant to add, and didn't: product IDs are pretty unreliable in the first place > (consider HTTP User-Agent:); and they get worse if different installations of the > product may have different sets of timezone data. For example, a Unix CUA might > extract the system timezone information and send that out as VTIMEZONEs; the definition > of each VTIMEZONE then depends on the OS version as well as the product version. The system's timezone database should be a set of VTIMEZONEs, not the current Unix mess. [We were discussing doing this as the lower-level mechanism for the Ximian Setup Tools, possibly translating VTIMEZONEs to Unix timezone data for compatibility with legacy stuff.] Federico From owner-ietf-calendar@mail.imc.org Sun Mar 18 03:17:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01684 for ; Sun, 18 Mar 2001 03:17:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA02089 for ietf-calendar-bks; Sun, 18 Mar 2001 00:00:20 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA02067 for ; Sun, 18 Mar 2001 00:00:15 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA08553 for ietf-calendar@imc.org; Sun, 18 Mar 2001 00:00:03 -0800 (PST) Date: Sun, 18 Mar 2001 00:00:03 -0800 (PST) From: Doug Royer Message-Id: <200103180800.AAA08553@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous Y user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and Y static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex Y text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug D C-4 VCAR examples Doug? Y C-5 PUBLISH text Y C-6 REQUEST text Y C-7 REPLY text Y C-8 ADD text Y C-9 CANCEL text Y C-10 REFRESH text Y C-11 COUNTER text Y C-12 DECLINECOUNTER Text Y C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS Y and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property Y C-16 (2.11) Query Schema Y C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Y Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS D Format? Text needs to be written. C-20 (13.) Security Considerations Y See editors note - more text. C-21 Resubmit REQUIREMENTS draft. Y C-22 Document MAXSIZE and MAXRESULT N C-23 Document METHOD is stored in CS database N Only one 'CREATE' per UID. Multple non-CREATE per UID. C-24 Fix the RESPONSE's to be consistant. N and multiple components, one for each TARGET. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: (iCal, iTIP, iMIP) Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 I-4 Add ALARMID to VALARM! I-5 iTIP error. VJOURNAL should be 0 (not 0+) for CANCEL ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com Tuesday discussion: DONE Section 2.4.3 - editor note: Change with new paragraph; Groups may be in a directory with its own ACL model and CAP should use the directory service to expand a UPN subject to the directory service access control model for the authenticated entity. DONE Section 2.4.4.1 - editor note: Your access is a union of all your grants minus a union of all your denies. (We still need to discuss ordering - allow or not. We may not want to fool with it). DONE Section 2.4.4.2 - editor note: We need an example (Steve/Doug) - Paul needs to read this note an example). Section 2.6 CALID - need to define that relative CALID must be consistent with the scheme specific part of URI as defined in RFC xxx. - Steve Section 2.9 Will be discussed earlier in draft - remove altogether. Section 7.1.3 Need to get IANA registration Section 7.1.3 Delete editors note about blank on examples. Need to add an unsuccessful login. Delete all lines except the line that starts with "The following...." - (* Who will do this example) DONE Section 7.2.1.1.1 Get rid of whole paragraph (pargraph above). If you want to generate unique relative CALids, use the GENERATE UID command and use the result as the relative CALid. (we need to make sure that the results are characters that are compatible with our definition of calids) Section 7.2.1.3. The result needs to be consistent with CALID character rules (i.e. no spaces). The example needs one more line with a dot. Steve will do this. DONE Section 7.2.1.5 This issue goes away because we are not doing heirarchial. Remove editors note Section 7.2.1.7 Add an example of a partial result - we want to get something that matches some things, and on the ones you don't have access, you don't have rights to some of the components. George will write up something. Section 7.2.2 Need restriction tables. Some are CAP - for the rest of them use iTIP tables (Steve/Doug) we all need to review the text DONE Section 7.2.3.2 Pull editors note - fix applied Section 8.0 Response codes. Need to make sure response codes in all drafts - iCal, iMip and iTip and examples. Error numbers need to be the same. Put text about error codes in comments below the examples (so that people don't look at them as being required in their text). Pat will look at the codes. Section 11.0 DTN, DTSTAMP, etc are implementations that may need to be considered. Restrictions tables may resolve these issues. Section 12.0 Leave as is until we get people to agree. On version shipped after last call, this is what we are going to enhance this section. It does not make sense to do this until working group last call. Updates to iCalendar need to be written and will not be submitted to IANA until last call to WG. Doug Section 13.0 This section is not ready for prime time. Need Paul Hill. Need an editors note. Section 14.0 Needs to be reformatted - Doug will make sure it is consistent. George will do 14 DONE Section 15.1.1. Steve - additions or changes to the CAP schema (replaces Define the Entity). Word entity needs to be removed and replaced throughout the document). Section 15.1.4 Submit entity for approval - John submitted to list. Need to find. Get John's text and add back into CAP draft. John submitted as a separate draft document. Use the MIME appeal verbage with John's additional text. Point WG at John's draft and say it should be included in the draft. We need to also submit to April Marine as well. DONE Section 16.0 Remove reference to vCard - - - - - - Assignment list: Section 2.4.4.2 - VCAR example (Steve/Doug) Sectoin 2.6 - Steve will research Section 7.1.3 - IANA registration (Pat) Section 7.1.3 - example of unsuccessful login (Who) Section 7.2.1.1. - look at Calid characters (Doug) Section 7.2.1.3 - example line (Steve) Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug) Section 7.2.2. - Restriction tables (Steve/Doug) Section 8.0 - look at consistency of Response code in all drafts (Pat) Section 12.0 - needs work. Check for consistency - Doug Section 13.0 - Paul Hill Section 14.0 - George Section 15.1.1 - replace text (Pat) Section 15.1.4 - add John's text to doc and put on list to look at proposal. - - - - - Work on Restriction table Editor note: Remove references to VDATA (mistake) Editor note: GENERATE UID is not a method. It's wrong in section 7.1.2.3 Ditto with NOOP - Section 7.2.1.6 From owner-ietf-calendar@mail.imc.org Sun Mar 18 21:47:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15357 for ; Sun, 18 Mar 2001 21:47:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA19397 for ietf-calendar-bks; Sun, 18 Mar 2001 18:36:12 -0800 (PST) Received: from mail10.speakeasy.net (mail10.speakeasy.net [216.254.0.210]) by above.proper.com (8.9.3/8.9.3) with SMTP id SAA19393 for ; Sun, 18 Mar 2001 18:36:11 -0800 (PST) Received: (qmail 17360 invoked from network); 19 Mar 2001 02:36:14 -0000 Received: from unknown (HELO ?64.20.151.242?) ([64.20.151.242]) (envelope-sender ) by mail10.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Mar 2001 02:36:14 -0000 Mime-Version: 1.0 Message-Id: Date: Sun, 18 Mar 2001 21:35:16 -0500 To: ietf-calendar@imc.org, Jonathan Rosenberg , Jonathan Lennox , "Henning G. Schulzrinne" From: Bob Mahoney Subject: Calsch dinner Monday night Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As has become traditional, those calsch folks here at the Minneapolis meeting are getting together for dinner Monday night. I'd also like to invite some of the iptel folks we've been exchanging mail with recently. Let's plan to meet at 7pm Monday night, in the Hilton near the front desk. We can develop a more detailed plan then. -Bob From owner-ietf-calendar@mail.imc.org Mon Mar 19 09:42:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11731 for ; Mon, 19 Mar 2001 09:42:10 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id GAA11097 for ietf-calendar-bks; Mon, 19 Mar 2001 06:27:41 -0800 (PST) Received: from localhost.localdomain (pcp000629pcs.wireless.meeting.ietf.org [135.222.64.129]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA11090 for ; Mon, 19 Mar 2001 06:27:39 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2HIbnW17237 for ; Sat, 17 Mar 2001 13:37:49 -0500 Message-ID: <3AB3AEFC.70EBC20C@ecal.com> Date: Sat, 17 Mar 2001 13:37:48 -0500 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Timezone TZID clashes References: <3AAE6B23.B4594185@ximian.com> <3AAF9149.6BA25161@ecal.com> <3AB03882.EB2F35E3@ximian.com> <3AB0DB88.AFFDA196@ecal.com> <3AB1381E.75EEE283@ecal.com> <200103170301.VAA07913@guanabana.ximian.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Federico Mena Quintero wrote: > The system's timezone database should be a set of VTIMEZONEs, not the > current Unix mess. (a) That's as may be; but most application developers don't get to dictate how the system is built. (b) Removing the translation step would not change that fact that the VTIMEZONEs the app sends out would depend on the OS version instead of the app version. (c) If the OS used VTIMEZONEs instead of something custom, then it would be *easier* to modify, and you'd have *more* variance among installations. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |I'm not a bibliophile, I'm a bibliophiliac. Put| |francis@ecal.com|me in a bookstore, & my wallet bleeds. | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 19 11:35:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14680 for ; Mon, 19 Mar 2001 11:35:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA21354 for ietf-calendar-bks; Mon, 19 Mar 2001 08:19:35 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21349 for ; Mon, 19 Mar 2001 08:19:33 -0800 (PST) From: Bruce_Kahn@iris.com To: George Babics Cc: ietf-calendar@imc.org Subject: Re: SKICal CONTROL MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 11:19:49 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 11:21:24 AM, Serialize complete at 03/19/2001 11:21:24 AM Content-Type: multipart/alternative; boundary="=_alternative 0059A7FD85256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059A7FD85256A14_= Content-Type: text/plain; charset="us-ascii" George wrote: > > How should "ORGANIZER" be handled for the possibly large number of events > > for which it hold no meaning? Examples: Holidays; public events; tax-filing > > deadlines; etc. > > An organizer can still have a meaning. It is the person who created > or published the meeting. One may ask questions about a public event > to the organizer. Or if there was a mistake in the holiday event, > who does one contact? > > One can use the CONTACT property, but then would one specify > CONTACT for a holiday? The functional use of ORGANIZER and CONTACT are quite clearly defined. From RFC 2445: 4.8.4.2 Contact Property Name: CONTACT Purpose: The property is used to represent contact information or alternately a reference to contact information associated with the calendar component. and 4.8.4.3 Organizer Property Name: ORGANIZER Purpose: The property defines the organizer for a calendar component. In a nutshell: Organizer is the coordination point for any workflow. Contact is a non-workflow point of contact (ie: "If you need directions to this event, contact Frank at..."). The use for an Organizer for Shannons examples is simple: the Organizer is responsible for handling any updates that may be necessary (ie:"Due to the local flooding, the Concerts on the Common scheduled for this Saturday has been cancelled." could be sent by the Town's "Organizer". In my company, the official Holiday Schedule is PUBLISHed by 1 entity. All other attempts by other Iris (or non-Iris) employees to reschedule or modify the "official" holiday set are rejected (either by me or by my client that sees an Organzier mismatch from what it was told was valid to accept). Would you want a disgruntled employee to give everyone tons of extra days off when its not company policy? Of course not. So by having updates only come from the sanctioned Organizer I can be reasonably certain I only take off the given holidays. Another example: In New England where I am a prisoner, err an employee of Iris, Patriots Day is a semi-regional holiday so if "Tax day" occurs on the same day, "Tax day" gets pushed out 1 more day. As such, the IRS may want to "update" their regular tax schedule for some of us tax payers. In order for me to accept the update, I need an Organizer that matches the original notices. > An organizer can still have a meaning. It is the person who created > or published the meeting. One may ask questions about a public event > to the organizer. Or if there was a mistake in the holiday event, > who does one contact? Workflow goes thru the ORGANZIER so a REPLY to the ORGANIZER w/your "There is a mistake" COMMENT is appropriate. One could conceivably also contact the CONTACT but that would be "out of band" from any C&S workflow. > Thus, who does one contact, the ORGANIZER, the CONTACT, or the CONTROL? > Furthermore, who should be contacted depending on which situation? Should > ORGANIZER be the default contact if CONTACT or CONTROL are not > specified? I would not expect ANY workflow msgs to be sent to the CONTROL entities. See above for ORGANIZER vs CONTACT usage. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0059A7FD85256A14_= Content-Type: text/html; charset="us-ascii"
George wrote:
> > How should "ORGANIZER" be handled for the possibly large number of events
> > for which it hold no meaning? Examples: Holidays; public events; tax-filing
> > deadlines; etc.
>
>   An organizer can still have a meaning. It is the person who created
> or published the meeting. One may ask questions about a public event
> to the organizer. Or if there was a mistake in the holiday event,
> who does one contact?
>
>   One can use the CONTACT property, but then would one specify
> CONTACT for a holiday?
The functional use of ORGANIZER and CONTACT are quite clearly defined.  From RFC 2445:

4.8.4.2 Contact

  Property Name: CONTACT

  Purpose: The property is used to represent contact information or
  alternately a reference to contact information associated with the
  calendar component.

and

4.8.4.3 Organizer

  Property Name: ORGANIZER

  Purpose: The property defines the organizer for a calendar component.

In a nutshell: Organizer is the coordination point for any workflow.  Contact is a non-workflow point of contact (ie: "If you need directions to this event, contact Frank at...").  

The use for an Organizer for Shannons examples is simple: the Organizer is responsible for handling any updates that may be necessary (ie:"Due to the local flooding, the Concerts on the Common scheduled for this Saturday has been cancelled." could be sent by the Town's "Organizer".  

In my company, the official Holiday Schedule is PUBLISHed by 1 entity.  All other attempts by other Iris (or non-Iris) employees to reschedule or modify the "official" holiday set are rejected (either by me or by my client that sees an Organzier mismatch from what it was told was valid to accept).  Would you want a disgruntled employee to give everyone tons of extra days off when its not company policy?  Of course not.  So by having updates only come from the sanctioned Organizer I can be reasonably certain I only take off the given holidays.

Another example: In New England where I am a prisoner, err an employee of Iris, Patriots Day is a semi-regional holiday so if "Tax day" occurs on the same day, "Tax day" gets pushed out 1 more day.  As such, the IRS may want to "update" their regular tax schedule for some of us tax payers.  In order for me to accept the update, I need an Organizer that matches the original notices.

>   An organizer can still have a meaning. It is the person who created
> or published the meeting. One may ask questions about a public event
> to the organizer. Or if there was a mistake in the holiday event,
> who does one contact?

Workflow goes thru the ORGANZIER so a REPLY to the ORGANIZER w/your "There is a mistake" COMMENT is appropriate.  One could conceivably also contact the CONTACT but that would be "out of band" from any C&S workflow.

>   Thus, who does one contact, the ORGANIZER, the CONTACT, or the CONTROL?
> Furthermore, who should be contacted depending on which situation? Should
> ORGANIZER be the default contact if CONTACT or CONTROL are not
> specified?

I would not expect ANY workflow msgs to be sent to the CONTROL entities.  See above for ORGANIZER vs CONTACT usage.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
 --=_alternative 0059A7FD85256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 11:36:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14719 for ; Mon, 19 Mar 2001 11:36:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA21342 for ietf-calendar-bks; Mon, 19 Mar 2001 08:19:29 -0800 (PST) Received: from Arista.iris.com ([198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21335 for ; Mon, 19 Mar 2001 08:19:26 -0800 (PST) From: Bruce_Kahn@iris.com To: George Babics Cc: ietf-calendar@imc.org Subject: Re: SKICal CONTROL MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 11:19:49 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 11:21:19 AM, Serialize complete at 03/19/2001 11:21:19 AM Content-Type: multipart/alternative; boundary="=_alternative 0059A7FD85256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059A7FD85256A14_= Content-Type: text/plain; charset="us-ascii" George wrote: > > How should "ORGANIZER" be handled for the possibly large number of events > > for which it hold no meaning? Examples: Holidays; public events; tax-filing > > deadlines; etc. > > An organizer can still have a meaning. It is the person who created > or published the meeting. One may ask questions about a public event > to the organizer. Or if there was a mistake in the holiday event, > who does one contact? > > One can use the CONTACT property, but then would one specify > CONTACT for a holiday? The functional use of ORGANIZER and CONTACT are quite clearly defined. From RFC 2445: 4.8.4.2 Contact Property Name: CONTACT Purpose: The property is used to represent contact information or alternately a reference to contact information associated with the calendar component. and 4.8.4.3 Organizer Property Name: ORGANIZER Purpose: The property defines the organizer for a calendar component. In a nutshell: Organizer is the coordination point for any workflow. Contact is a non-workflow point of contact (ie: "If you need directions to this event, contact Frank at..."). The use for an Organizer for Shannons examples is simple: the Organizer is responsible for handling any updates that may be necessary (ie:"Due to the local flooding, the Concerts on the Common scheduled for this Saturday has been cancelled." could be sent by the Town's "Organizer". In my company, the official Holiday Schedule is PUBLISHed by 1 entity. All other attempts by other Iris (or non-Iris) employees to reschedule or modify the "official" holiday set are rejected (either by me or by my client that sees an Organzier mismatch from what it was told was valid to accept). Would you want a disgruntled employee to give everyone tons of extra days off when its not company policy? Of course not. So by having updates only come from the sanctioned Organizer I can be reasonably certain I only take off the given holidays. Another example: In New England where I am a prisoner, err an employee of Iris, Patriots Day is a semi-regional holiday so if "Tax day" occurs on the same day, "Tax day" gets pushed out 1 more day. As such, the IRS may want to "update" their regular tax schedule for some of us tax payers. In order for me to accept the update, I need an Organizer that matches the original notices. > An organizer can still have a meaning. It is the person who created > or published the meeting. One may ask questions about a public event > to the organizer. Or if there was a mistake in the holiday event, > who does one contact? Workflow goes thru the ORGANZIER so a REPLY to the ORGANIZER w/your "There is a mistake" COMMENT is appropriate. One could conceivably also contact the CONTACT but that would be "out of band" from any C&S workflow. > Thus, who does one contact, the ORGANIZER, the CONTACT, or the CONTROL? > Furthermore, who should be contacted depending on which situation? Should > ORGANIZER be the default contact if CONTACT or CONTROL are not > specified? I would not expect ANY workflow msgs to be sent to the CONTROL entities. See above for ORGANIZER vs CONTACT usage. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0059A7FD85256A14_= Content-Type: text/html; charset="us-ascii"
George wrote:
> > How should "ORGANIZER" be handled for the possibly large number of events
> > for which it hold no meaning? Examples: Holidays; public events; tax-filing
> > deadlines; etc.
>
>   An organizer can still have a meaning. It is the person who created
> or published the meeting. One may ask questions about a public event
> to the organizer. Or if there was a mistake in the holiday event,
> who does one contact?
>
>   One can use the CONTACT property, but then would one specify
> CONTACT for a holiday?
The functional use of ORGANIZER and CONTACT are quite clearly defined.  From RFC 2445:

4.8.4.2 Contact

  Property Name: CONTACT

  Purpose: The property is used to represent contact information or
  alternately a reference to contact information associated with the
  calendar component.

and

4.8.4.3 Organizer

  Property Name: ORGANIZER

  Purpose: The property defines the organizer for a calendar component.

In a nutshell: Organizer is the coordination point for any workflow.  Contact is a non-workflow point of contact (ie: "If you need directions to this event, contact Frank at...").  

The use for an Organizer for Shannons examples is simple: the Organizer is responsible for handling any updates that may be necessary (ie:"Due to the local flooding, the Concerts on the Common scheduled for this Saturday has been cancelled." could be sent by the Town's "Organizer".  

In my company, the official Holiday Schedule is PUBLISHed by 1 entity.  All other attempts by other Iris (or non-Iris) employees to reschedule or modify the "official" holiday set are rejected (either by me or by my client that sees an Organzier mismatch from what it was told was valid to accept).  Would you want a disgruntled employee to give everyone tons of extra days off when its not company policy?  Of course not.  So by having updates only come from the sanctioned Organizer I can be reasonably certain I only take off the given holidays.

Another example: In New England where I am a prisoner, err an employee of Iris, Patriots Day is a semi-regional holiday so if "Tax day" occurs on the same day, "Tax day" gets pushed out 1 more day.  As such, the IRS may want to "update" their regular tax schedule for some of us tax payers.  In order for me to accept the update, I need an Organizer that matches the original notices.

>   An organizer can still have a meaning. It is the person who created
> or published the meeting. One may ask questions about a public event
> to the organizer. Or if there was a mistake in the holiday event,
> who does one contact?

Workflow goes thru the ORGANZIER so a REPLY to the ORGANIZER w/your "There is a mistake" COMMENT is appropriate.  One could conceivably also contact the CONTACT but that would be "out of band" from any C&S workflow.

>   Thus, who does one contact, the ORGANIZER, the CONTACT, or the CONTROL?
> Furthermore, who should be contacted depending on which situation? Should
> ORGANIZER be the default contact if CONTACT or CONTROL are not
> specified?

I would not expect ANY workflow msgs to be sent to the CONTROL entities.  See above for ORGANIZER vs CONTACT usage.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
 --=_alternative 0059A7FD85256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 11:44:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14950 for ; Mon, 19 Mar 2001 11:44:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA21949 for ietf-calendar-bks; Mon, 19 Mar 2001 08:31:16 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21942 for ; Mon, 19 Mar 2001 08:31:14 -0800 (PST) From: Bruce_Kahn@iris.com To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: RE: SKICal CONTROL MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 11:31:37 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 11:33:05 AM, Serialize complete at 03/19/2001 11:33:05 AM Content-Type: multipart/alternative; boundary="=_alternative 005ABC8B85256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005ABC8B85256A14_= Content-Type: text/plain; charset="us-ascii" Shannon asked: >How should "ORGANIZER" be handled for the possibly large number of events >for which it hold no meaning? Examples: Holidays; public events; tax-filing >deadlines; etc. > >In the context of events, such as holidays, shared by all the users of a >given calendar system (probably by way of user groups and a group >calendar) - the concept of ORGANIZER and for that matter ATTENDEE are >counterproductive and likely confusing if displayed or revealed to an end >user. For all the examples above there are definite uses for an Organizer. The Organizer is the one who is responsible for organizing the Holidays, public events, etc. Whom is this you may be thinking. Simple, whom ever defines it and then publishes it. Who says that in the US, "April 15th (or the closest following weekday if on a weekend) is when final tax payments are due?". The US goverment (or if you prefer, the IRS). Who would be responsible for organizing local public events like St. Patricks Day Parades, Concerts on the Town Common, etc? The local government of course. If one of the entities is going to publish some kind of event schedule or timetable then there has to be some Organizer to disseminate and possibly update that information. Nearly all of the examples Shannon asked about are the PUBLISH type. That is, the IRS does not care to get a COUNTER from me when it tells me I have taxes due on 15-Apr-01. Nor does it want a COUNTER proposal for how much (or when) I should pay. In iTIP, PUBLISHes are done w/o ATTENDEEs so there should be no confusion. One could see some cases where REQUEST is used instead of PUBLISH. For example, the local government wants to get an idea of how may folks plan to attend the local free concerts on the common so they can judge how much police or emergency services to have on hand. I doubt they would want DELEGATION or COUNTER messages from individuals but they may want to get a feel for attendance. As such, ATTENDEE is not really counterproductive or confusing; it may be a single address like "mailto:westford-residents@westford.com" and NOT likely the entire taxpayer list for Westford... However this kind of case is not likely to be as predominant as the PUBLISH case. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005ABC8B85256A14_= Content-Type: text/html; charset="us-ascii"
Shannon asked:
>How should "ORGANIZER" be handled for the possibly large number of events
>for which it hold no meaning? Examples: Holidays; public events; tax-filing
>deadlines; etc.
>
>In the context of events, such as holidays, shared by all the users of a
>given calendar system (probably by way of user groups and a group
>calendar) - the concept of ORGANIZER and for that matter ATTENDEE are
>counterproductive and likely confusing if displayed or revealed to an end
>user.

For all the examples above there are definite uses for an Organizer.  The Organizer is the one who is responsible for organizing the Holidays, public events, etc.  Whom is this you may be thinking.  Simple, whom ever defines it and then publishes it.  Who says that in the US, "April 15th (or the closest following weekday if on a weekend) is when final tax payments are due?".  The US goverment (or if you prefer, the IRS).  Who would be responsible for organizing local public events like St. Patricks Day Parades, Concerts on the Town Common, etc?  The local government of course.

If one of the entities is going to publish some kind of event schedule or timetable then there has to be some Organizer to disseminate and possibly update that information.

Nearly all of the examples Shannon asked about are the PUBLISH type.  That is, the IRS does not care to get a COUNTER from me when it tells me I have taxes due on 15-Apr-01.  Nor does it want a COUNTER proposal for how much (or when) I should pay.  In iTIP, PUBLISHes are done w/o ATTENDEEs so there should be no confusion.

One could see some cases where REQUEST is used instead of PUBLISH.  For example, the local government wants to get an idea of how may folks plan to attend the local free concerts on the common so they can judge how much police or emergency services to have on hand.  I doubt they would want DELEGATION or COUNTER messages from individuals but they may want to get a feel for attendance.  As such, ATTENDEE is not really counterproductive or confusing; it may be a single address like "mailto:westford-residents@westford.com" and NOT likely the entire taxpayer list for Westford...

However this kind of case is not likely to be as predominant as the PUBLISH case.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005ABC8B85256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 11:48:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15073 for ; Mon, 19 Mar 2001 11:48:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA22368 for ietf-calendar-bks; Mon, 19 Mar 2001 08:38:03 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA22363 for ; Mon, 19 Mar 2001 08:38:02 -0800 (PST) From: Bruce_Kahn@iris.com To: =?iso-8859-1?Q?P=E4r_Lanner=F6?= Cc: ietf-calendar@imc.org Subject: Re: SKICal CONTROL MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 11:38:11 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 11:39:53 AM, Serialize complete at 03/19/2001 11:39:53 AM Content-Type: multipart/alternative; boundary="=_alternative 005B564085256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B564085256A14_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable P=E4r proposed: controlparam =3D *(=20 ; the following is optional,=20 ; but MUST NOT occur more than once=20 (";" languageparam ) / (";" cnparam ) / (";" skiroleparam) ; It is highly RECOMMENDED that SKICal objects actually ; use the cnparam since some applications will not=20 ; bother to read the altrep'ed vCard. ; the following is optional,=20 ; and MAY occur more than once=20 =20 (";" xparam)=20 )=20 2 Questions: 1: Didnt we already have a SKIROLE vs ROLE discussion a while back? I=20 didnt notice any objection to SKiCAL adding new ROLE values using the=20 normal extension mechanism. Is there some motivation for NOT reusing ROLE = and just adding new values (and defining when they may be used)?? 2: The ABNF comment talks about "altrep'ed vCard" but the ABNF has no ALTRE= P in it. ALTREP is already defined in 2445 as: 4.2.1 Alternate Text Representation Parameter Name: ALTREP Purpose: To specify an alternate text representation for the property value. [Snip] altrepparam =3D "ALTREP" "=3D" DQUOTE uri DQUOTE so either the comment is stale or altrepparam is missing from the ABNF.=20 Which is it? Bruce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Kahn INet: Bruce=5FKahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005B564085256A14_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
P=E4r proposed:

    controlparam  = =3D *(
       ; the following is optional,
       ; but MUST NOT occur more than once
       (";" languageparam ) / (";"= cnparam ) / (";" skiroleparam)

       ; It is highly RECOMMENDED that SKICal objects = actually
       ; use the cnparam since some applications will = not
       ; bother to read the altrep'ed vCard.

       ; the following is optional,
       ; and MAY occur more than once
       
       (";" xparam)
       )

2 Questions:

1: Didnt we already have a SKIROLE v= s ROLE discussion a while back?  I didnt notice any objection to SKiCA= L adding new ROLE values using the normal extension mechanism.  Is the= re some motivation for NOT reusing ROLE and just adding new values (and def= ining when they may be used)??

2: The ABNF comment talks about &quo= t;altrep'ed vCard" but the ABNF has no ALTREP in it.  A= LTREP is already defined in 2445 as:

4.2.1 Alternate Text Representation

   Parameter Name: ALTREP

  Purpose: To specify an alternate text representation for the proper= ty
  value.
[Snip]
     altrepparam      =  =3D "ALTREP" "=3D" DQUOTE uri DQUOTE
so either the comment is stale or al= trepparam is missing from the ABNF.  Which is it?

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                   &= nbsp;            INet: Bruce=5FKahn@iris.com<= br> Iris Associates                 &nb= sp;        Phone: 978.392.5335
Westford, MA, USA 01886               &n= bsp;    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005B564085256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 12:16:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15813 for ; Mon, 19 Mar 2001 12:16:42 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA22985 for ietf-calendar-bks; Mon, 19 Mar 2001 09:04:38 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA22980 for ; Mon, 19 Mar 2001 09:04:36 -0800 (PST) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Guide: Defintion of CS MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 12:05:00 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 12:06:27 PM, Serialize complete at 03/19/2001 12:06:27 PM Content-Type: multipart/alternative; boundary="=_alternative 005DCA9C85256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DCA9C85256A14_= Content-Type: text/plain; charset="us-ascii" The latest draft says: > Calendar Store > A data store of a calendar service. A calendar service may > have several calendar stores, and each store may contain > several calendars, as well as properties and components > outside of the calendars. I do not recall seeing any text about multiple stores in a service or how a user would be able to access one store vs another in the service. TARGETs are calendars and the CSIDs in CAP were for services I thought so how do I access 1 store vs another?? Did I miss this addition to CAP?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005DCA9C85256A14_= Content-Type: text/html; charset="us-ascii"
The latest draft says:
>   Calendar Store
>      A data store of a calendar service. A calendar service may
>      have several calendar stores, and each store may contain
>      several calendars, as well as properties and components
>      outside of the calendars.
I do not recall seeing any text about multiple stores in a service or how a user would be able to access one store vs another in the service.  TARGETs are calendars and the CSIDs in CAP were for services I thought so how do I access 1 store vs another??

Did I miss this addition to CAP??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005DCA9C85256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 12:35:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16347 for ; Mon, 19 Mar 2001 12:35:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA23339 for ietf-calendar-bks; Mon, 19 Mar 2001 09:21:17 -0800 (PST) Received: from localhost.localdomain (pcp000702pcs.wireless.meeting.ietf.org [135.222.64.202]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA23335 for ; Mon, 19 Mar 2001 09:21:14 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2JHS1r01181 for ; Mon, 19 Mar 2001 12:28:01 -0500 Message-ID: <3AB641A1.1A330892@ecal.com> Date: Mon, 19 Mar 2001 11:28:01 -0600 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: SKICal CONTROL References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > controlparam = *( [...] > 1: Didnt we already have a SKIROLE vs ROLE discussion a while > back? I didnt notice any objection to SKiCAL adding new ROLE > values using the normal extension mechanism. Is there some > motivation for NOT reusing ROLE and just adding new values (and > defining when they may be used)?? Isn't ROLE just for ATTENDEEs? The CONTROL might not be an ATTENDEE. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |The Net regards censorship as damage, and routes| |francis@ecal.com|around it. -- John Gilmore | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Mar 19 13:33:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17709 for ; Mon, 19 Mar 2001 13:33:28 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA26362 for ietf-calendar-bks; Mon, 19 Mar 2001 10:14:35 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA26357 for ; Mon, 19 Mar 2001 10:14:33 -0800 (PST) From: Bruce_Kahn@iris.com To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: SKICal CONTROL MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 13:14:46 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 01:16:24 PM, Serialize complete at 03/19/2001 01:16:24 PM Content-Type: multipart/alternative; boundary="=_alternative 00642DE685256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00642DE685256A14_= Content-Type: text/plain; charset="us-ascii" John replied: > Isn't ROLE just for ATTENDEEs? The CONTROL might not be an > ATTENDEE. Actually its not restricted to ATTENDEEs. We defined it separately from the ATTENDEE definition and as such there is nothing precluding another property from also having it. The actual definition from 2445 says: 4.2.16 Participation Role Parameter Name: ROLE Purpose: To specify the participation role for the calendar user specified by the property. It does not say "specified by the ATTENDEE property value" or any variant of that. It is a property parameter that, until now, has not been needed or logical for other properties besides ATTENDEE. It does make sense for CONTROL and for SKiCAL it may also make sense to have new values for some ATTENDEEs (but thats up to SKiCAL to define clearly). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00642DE685256A14_= Content-Type: text/html; charset="us-ascii"
John replied:
> Isn't ROLE just for ATTENDEEs? The CONTROL might not be an
> ATTENDEE.
Actually its not restricted to ATTENDEEs.  We defined it separately from the ATTENDEE definition and as such there is nothing precluding another property from also having it.  The actual definition from 2445 says:

4.2.16 Participation Role

  Parameter Name: ROLE

  Purpose: To specify the participation role for the calendar user
  specified by the property.

It does not say "specified by the ATTENDEE property value" or any variant of that.  It is a property parameter that, until now, has not been needed or logical for other properties besides ATTENDEE.  It does make sense for CONTROL and for SKiCAL it may also make sense to have new values for some ATTENDEEs (but thats up to SKiCAL to define clearly).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00642DE685256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 14:09:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18660 for ; Mon, 19 Mar 2001 14:09:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA28752 for ietf-calendar-bks; Mon, 19 Mar 2001 10:58:14 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA28746 for ; Mon, 19 Mar 2001 10:58:13 -0800 (PST) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Guide: Protocol Requirements MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 13:59:25 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 01:58:43 PM, Serialize complete at 03/19/2001 01:58:43 PM Content-Type: multipart/alternative; boundary="=_alternative 006823E785256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006823E785256A14_= Content-Type: text/plain; charset="us-ascii" Under "2.2 Protocol requirements" the text All the other protocols depend on [ICAL], so all elements of a standards-based calendaring and scheduling systems will have to interpret [ICAL]. makes efforts like SKiCAL and CAP unusable per say because it restricts the protocols to RFC 2445 data only. Our intent is not that so I propose the text be changed to: All the other protocols depend on [ICAL] or extensions to [ICAL], so all elements of a standards-based calendaring and scheduling systems will have to interpret [ICAL] and extensions to [ICAL]. Since all extensions to [ICAL] must adhere to the rules of [ICAL] parsing of extensions should be possible without necessarily being able to interpret the extension. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006823E785256A14_= Content-Type: text/html; charset="us-ascii"
Under "2.2 Protocol requirements" the text

         All the other protocols depend on [ICAL], so all elements
        of a standards-based calendaring and scheduling systems
        will have to interpret [ICAL].

makes efforts like SKiCAL and CAP unusable per say because it restricts the protocols to RFC 2445 data only.  Our intent is not that so I propose the text be changed to:

         All the other protocols depend on [ICAL] or extensions to
         [ICAL], so all elements of a standards-based calendaring
         and scheduling systems will have to interpret [ICAL] and
         extensions to [ICAL].  Since all extensions to [ICAL] must
         adhere to the rules of [ICAL] parsing of extensions should
         be possible without necessarily being able to interpret
         the extension.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006823E785256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 14:21:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19020 for ; Mon, 19 Mar 2001 14:21:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id LAA29505 for ietf-calendar-bks; Mon, 19 Mar 2001 11:10:16 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA29501 for ; Mon, 19 Mar 2001 11:10:15 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id NAA23065 for ; Mon, 19 Mar 2001 13:05:12 -0600 From: "Shannon J. Clark" To: Subject: RE: SKICal CONTROL Date: Mon, 19 Mar 2001 13:09:17 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Should the standard state exactly which parameters can be attached to which properties? If we don't I suspect we will see some serious interoperability issues - especially since these will be cases of "standard" parameters being used in various places - vs. the less serious case of X-* parameters or properties which each system should be written to ignore if it doesn't understand. So, should we state somewhere which parameters can optionally be used by which properties? Shannon Shannon J. Clark CEO - JigZaw, Inc 1.800.4.JIGZAW (454.4929) shannon@jigzaw.com www.jigzaw.com -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Bruce_Kahn@iris.com Sent: Monday, March 19, 2001 12:15 PM To: John Stracke Cc: ietf-calendar@imc.org Subject: Re: SKICal CONTROL John replied: > Isn't ROLE just for ATTENDEEs? The CONTROL might not be an > ATTENDEE. Actually its not restricted to ATTENDEEs. We defined it separately from the ATTENDEE definition and as such there is nothing precluding another property from also having it. The actual definition from 2445 says: 4.2.16 Participation Role Parameter Name: ROLE Purpose: To specify the participation role for the calendar user specified by the property. It does not say "specified by the ATTENDEE property value" or any variant of that. It is a property parameter that, until now, has not been needed or logical for other properties besides ATTENDEE. It does make sense for CONTROL and for SKiCAL it may also make sense to have new values for some ATTENDEEs (but thats up to SKiCAL to define clearly). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Mon Mar 19 14:46:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19679 for ; Mon, 19 Mar 2001 14:46:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA00746 for ietf-calendar-bks; Mon, 19 Mar 2001 11:33:10 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA00739 for ; Mon, 19 Mar 2001 11:33:04 -0800 (PST) From: Bruce_Kahn@iris.com To: ietf-calendar@imc.org Subject: Guide to Internet Calendaring Pass 01 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 14:34:51 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 02:33:38 PM, Serialize complete at 03/19/2001 02:33:38 PM Content-Type: multipart/alternative; boundary="=_alternative 006B627585256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B627585256A14_= Content-Type: text/plain; charset="us-ascii" Bob and George put some work into the Guide but in doing at least a first or second pass on it I I have some comments/questions. (Of course I do, otherwise I wouldnt be sending this, no??) This is going to be long but each item is brief. I will put large issues in separate documents; Im only putting small stuff in this 1 big posting since I expect little need for followup discussion on the items below. There are 21 tidbits, mostly small but a couple that require more than a simple typo fix. #1: Status or TOC? >Status of this Memo > > 1. Introduction > Terminology > 2. Requirements There is no Status text; there is a Table of Contents though... #2: Page numbers? The TOC is simply entries: > 1. Introduction > Terminology > 2. Requirements > Fundamental Need > Protocol Requirements > 3. Standards Solution > Examples > Systems > Standalone single-user system > Single-user systems communicating There are no line numbers that are normally found in Drafts and RFCs... Please add 'em so I can index faster on paper. #3: Sub-items are not numbered: Look at the snippet above and you will see that only the top sections have numbers. There is no 1.1 or 2.3, etc. (unless you read the body and find "1.1 Terminology", etc). This is necessary for proper discussion and publishing beyond Draft. It may be an artifact of your text editor but it needs fixing... #4: Internet only? > understanding, and potentially help implementors in the design of > their internet calendaring and scheduling systems. Since C&S is intranet as well as internet the phrase "their internet" in the last line is misleaing. How about "their standards based" (or 'oriented') instead? #5: Bibliography nits: > [IRIP] draft-ietf-calsch-irip iCalendar Real-time Interoperability > Protocol > [CAP] draft-ietf-calsch-cap Calendar Access Protocol It is normal draft practice to cite actual revision numbers for drafts if known. Since iRIP is expired, it should be noted as such in the Bibliography. The CAP draft is now at 04 so it should be reflected in its entry. #6: Bibliography nits 02: > [ICAL] [RFC-2445] Calendaring and Scheduling Core Object > Specification > [ITIP] [RFC-2446] iCalendar Transport-Independent Interoperability > Protocol > [IMIP] [RFC-2447] iCalendar Message-Based Interoperability Protocol 3 nits: 1: There are no references to "[RFC-244x]" anywhere in the draft so they do not belong in the index as notations. In fact there are NO RFC citations ANYWHERE in the draft so why are there any for MIME, etc if they are not referenced?? 2: Why are our RFCs cited differently than the others like MIME? The reference format is not the 'standard' one Ive always seen. Normally it would look like: [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996. We should be consistant. 3: In the text we should use "iCalendar [RFC 2445]" instead of "[ICAL]" and remove the non-semi-standard [ICAL], etc refs in favor of [RFC 2445], etc. This also applies to "[ITIP]" and "[IMIP]". #7: Definition nit If "Delegate" is defined then "Delegator" should also be defined. As it stands now, both are defined under 1 heading. #8: Definition nit 2 "Local Store" is defined starting with "A CS which" but the abreviation "CS" is not clearly indicated. The same can be said for CU and others. Only CUA is properly notated next to the term in the definitions. The same goes for "Remote Store". Add all abreviations to the proper defintions! #9: Definition nit 3 "Remote Store" is defined but never used. Remove it or use it in the text. #10: Unclear phrasing/description: The phrase: iMIP is "expressing it in email terminology" an EMAIL dictionary is unclear. I assume some punctuation after the last DQUOTE is missing or the "an EMAIL dictionary" is residual. Clarify and fix up the analogy. #11: Bibliography nit 03: "RFC822" is used often but never clearly defined in the Bibliography. Add it and use the "[RFC 822]" format in the text... #12: Slightly askew Relationship text: The text: iTIP is how you use the language. iMIP is further definition for use over email. iRIP is the language used over a real-time transport is slightly misleading when describing iMIP and iRIP. iMIP is not a "further definition" of iCalendar; it is the "definition of how to send iTIP messages over eMail". iRIP is (or was) "how to send iTIP messages over a real-time transport". iMIP does not extend iTIP, it 'instanciates' it. The same for iRIP. Also, the description: CAP is how to use the language, in real-time, to access a calendar server is also slightly misleading. CAP describes not only how to _access_ the server but also data stored on the server (in the store in various calendars or on entries in the store). Finally, the text: (scheduling not booking) is not grammatically correct in its context. Should it have a comma before the "not"? If you are drawing a line between Calendaring and Scheduling (or booking) then you need to define these terms. #13: Unclear "it" usage: The analogy text: iMIP is "expressing it in email terminology" an EMAIL dictionary CAP/iRIP is "expressing it for use in a Real Time transport" has a dangling 'it' in the dquoted phrases. Please clarify the reference or expand the phrasing a bit. #14: Under 2.1 Fundamental Needs: Some examples do not quite demonstrate the stated need. For example, 'a' does not really describe the need for "with only one CUA." It describes a need to be able to access a calendar w/any CUA, not just 1 CUA. Examples 'a' and 'b' could easily be combined into 1 "Need", the one that 'b' currently has. At best, the real difference between 'a' and 'b' is that one is Intranet and the other is Internet... Example 'd' is not quite gramatically correct; "to book time slot" should be "to book a time slot". Also, the need is too narrowing. "Schedule calendar events and todos" precludes a teacher having the students send 'progress reports' (ala VJOURNALs) to him. Why not use the more generic phrase "Schedule calendar entries" instead? The same comment applies to example 'f'. Example 'e' is the logical opposite of 'c' and 'd' is the opposite of 'f' so why not swap 'd' and 'e' so that the "Share" cases are together and the "Schedule" cases are too? Since all the examples really have a "possibly from different vendors" clause that is applicable but only some have it, why not put a statement about ALL the examples being in both a homogeneous and heterogenous enviorment? For example, 'a' could easily be a Palm handlheld accessing his Domino server. Its a single CUA accessing a single calendar but it is not simply a Notes CUA accessing a Domino calendar server... #15: Bad iTIP example in 2.2 Protocol requirements The example is missing a DTSTAMP, METHOD, UID and maybe more. If the example is not supposed to be iTIP then a frame of reference is needed. At least include the normally "mandatory" stuff like UID and DTSTAMP even if its not iTIP so we dont get "Is the example wrong?" questions later in last call or beyond. For the labeled iTIP example, the missing UID MUST be put in #16: Editorial nit: The phrase "decline counters to, the various" does not require a comma in it. #17: Editoral nit: Is there any need for the phrase " Both CUAs and calendar services may have [ITIP] interpreters." where it currently is?? I dont think so... #18: Odd/misleading CAP descriptions [CAP] also provides a real-time binding for the calendar management messages. is misleading as we currently have no calendar management messages in iTIP or iCal. I think the phrase should have been something like: [CAP] also provides a real-time binding for the [ITIP] messages. Also, above that is a very misleading paragraph: [CAP] describes the messages used to manage calendars. These messages are represented in [ICAL], and have semantics such as being a search for data, being data in response to a search or the being the creation of a meeting. Again, nothing CAP uses for managing calendars is currently in 2445. We are working on extensions to 2445 to do this. The comments above about phrasing to include "[ICAL] and extentensions to [ICAL]" apply here too. It also applies to the rest of the CAP description paragraphs in this section. #19: Bad C/S example: The C:/S: example is bad. The example has: C:content-transfer-encoding: 7bit C:BEGIN:VCALENDAR but there should be a "C:" between them (to have a CRLF in the stream between the header and the body). Also the server response is illegal since it has: S: END:VCALENDAR S: Content-Type:text/calendar; method=RESPONSE; which blurs the header of the second response into the body of the 1st. KISS the example and make it simply create the entry on one calendar. The text "Furthermore, CAP is still a draft, thus the details of one can create such an event may change." has a dangling "one" reference that needs a home. Its unclear if the reference is to the example is in flux for CAP or what... #20 Editorial nit: When specified using correct iCalendar grammar, we refer to these event representations or operation requests as " calendar object representations is missing a final dquote. #21 What did they say??? After reading and then rereading the following paragraph: A system may implement the first methodology only. The second one is dependent on iTIP. It requires understanding of iTIP and the ability to communicate with other CAP servers using iTIP. Since, currently, iMIP is the only binding of iTIP, the second method is also dependent on iMIP. I just had to say "Huh?!?". Questions I have include: 1: What are you referring to with "A system"? This is all in the context of the ICAL/ITIP/CAP and so I assume its "A calendaring system" but thats not a defined term so Im still assuming... 2: Both methodologies (not shown above) are dependent on iTIP, NOT just "the second one". Ya cant implement iMIP w/o knowing iTIP. So why single out "the second one"?? 3: Why does the CAP require "the ability to communicate with other CAP servers using iTIP" instead of requiring the ability to speak CAP to other CAP servers??? One server does not speak iMIP to another CAP server (unless you are trying to tie in CRISP here but I dont think it works that way.) 4: The entire last line is circular reasoning and wrong. CAP is new but so are CAP servers so there wont be any that only speak iMIP (they will speak CAP from the start!). There is nothing in CAP (last I read it end to end) that mandates iMIP support so the last tidbit about dependence on iMIP is wrong. A CAP server should speak CAP to another CAP server, NOT iMIP or some other "store and forward" binding. Thats enough for now. My 9 fingers are cramping up and I have other tasks I need to focus on for now. More comments later... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006B627585256A14_= Content-Type: text/html; charset="us-ascii"
Bob and George put some work into the Guide but in doing at least a first or second pass on it I I have some comments/questions.  (Of course I do, otherwise I wouldnt be sending this, no??)

This is going to be long but each item is brief.  I will put large issues in separate documents; Im only putting small stuff in this 1 big posting since I expect little need for followup discussion on the items below.  There are 21 tidbits, mostly small but a couple that require more than a simple typo fix.

#1: Status or TOC?

>Status of this Memo
>
>   1.  Introduction
>       Terminology
>   2.  Requirements

There is no Status text; there is a Table of Contents though...

#2: Page numbers?

The TOC is simply entries:
>   1.  Introduction
>       Terminology
>   2.  Requirements
>       Fundamental Need
>       Protocol Requirements
>   3.  Standards Solution
>       Examples
>       Systems
>       Standalone single-user system
>       Single-user systems communicating

There are no line numbers that are normally found in Drafts and RFCs...  Please add 'em so I can index faster on paper.

#3: Sub-items are not numbered:

Look at the snippet above and you will see that only the top sections have numbers.  There is no 1.1 or 2.3, etc. (unless you read the body and find "1.1 Terminology", etc).  This is necessary for proper discussion and publishing beyond Draft.  It may be an artifact of your text editor but it needs fixing...

#4: Internet only?

>   understanding, and potentially help implementors in the design of
>   their internet calendaring and scheduling systems.

Since C&S is intranet as well as internet the phrase "their internet" in the last line is misleaing.  How about "their standards based" (or 'oriented') instead?

#5: Bibliography nits:

>   [IRIP] draft-ietf-calsch-irip iCalendar Real-time Interoperability
>   Protocol
>   [CAP] draft-ietf-calsch-cap Calendar Access Protocol

It is normal draft practice to cite actual revision numbers for drafts if known.  Since iRIP is expired, it should be noted as such in the Bibliography.  The CAP draft is now at 04 so it should be reflected in its entry.

#6: Bibliography nits 02:

>   [ICAL] [RFC-2445] Calendaring and Scheduling Core Object
>   Specification
>   [ITIP] [RFC-2446] iCalendar Transport-Independent Interoperability
>   Protocol
>   [IMIP] [RFC-2447] iCalendar Message-Based Interoperability Protocol

3 nits:

1: There are no references to "[RFC-244x]" anywhere in the draft so they do not belong in the index as notations.  In fact there are NO RFC citations ANYWHERE in the draft so why are there any for MIME, etc if they are not referenced??
2: Why are our RFCs cited differently than the others like MIME?  The reference format is not the 'standard' one Ive always seen.  Normally it would look like:
   [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
             Extensions (MIME) - Part One: Format of Internet Message
             Bodies", RFC 2045, November 1996.
We should be consistant.
3: In the text we should use "iCalendar [RFC 2445]" instead of "[ICAL]" and remove the non-semi-standard [ICAL], etc refs in favor of [RFC 2445], etc.  This also applies to "[ITIP]" and "[IMIP]".

#7: Definition nit

If "Delegate" is defined then "Delegator" should also be defined.  As it stands now, both are defined under 1 heading.

#8: Definition nit 2

"Local Store" is defined starting with "A CS which" but the abreviation "CS" is not clearly indicated.  The same can be said for CU and others.  Only CUA is properly notated next to the term in the definitions. The same goes for "Remote Store".  Add all abreviations to the proper defintions!

#9: Definition nit 3

"Remote Store" is defined but never used.  Remove it or use it in the text.

#10: Unclear phrasing/description:

The phrase:
      iMIP is "expressing it in email terminology" an
     EMAIL dictionary
is unclear.  I assume some punctuation after the last DQUOTE is missing or the "an EMAIL dictionary" is residual.  Clarify and fix up the analogy.

#11: Bibliography nit 03:

"RFC822" is used often but never clearly defined in the Bibliography.  Add it and use the "[RFC 822]" format in the text...

#12: Slightly askew Relationship text:

The text:

      iTIP is how you use the language.
     iMIP is further definition for use over email.
     iRIP is the language used over a real-time transport

is slightly misleading when describing iMIP and iRIP.  iMIP is not a "further definition" of iCalendar; it is the "definition of how to send iTIP messages over eMail".  iRIP is (or was) "how to send iTIP messages over a real-time transport".  iMIP does not extend iTIP, it 'instanciates' it.  The same for iRIP.

Also, the description:
      CAP is how to use the language, in real-time, to access a
     calendar server
is also slightly misleading.  CAP describes not only how to _access_ the server but also data stored on the server (in the store in various calendars or on entries in the store).

Finally, the text:
  (scheduling not booking)
is not grammatically correct in its context.  Should it have a comma before the "not"?  If you are drawing a line between Calendaring and Scheduling (or booking) then you need to define these terms.

#13: Unclear "it" usage:

The analogy text:

      iMIP is "expressing it in email terminology" an
     EMAIL dictionary
     CAP/iRIP is "expressing it for use in a Real Time transport"
has a dangling 'it' in the dquoted phrases.  Please clarify the reference or expand the phrasing a bit.

#14: Under 2.1 Fundamental Needs:

Some examples do not quite demonstrate the stated need.  For example, 'a' does not really describe the need for "with only one CUA."   It describes a need to be able to access a calendar w/any CUA, not just 1 CUA.

Examples 'a' and 'b' could easily be combined into 1 "Need", the one that 'b' currently has.  At best, the real difference between 'a' and 'b' is that one is Intranet and the other is Internet...

Example 'd' is not quite gramatically correct; "to book time slot" should be "to book a time slot".  Also, the need is too narrowing.  "Schedule calendar events and todos" precludes a teacher having the students send 'progress reports' (ala VJOURNALs) to him.  Why not use the more generic phrase "Schedule calendar entries" instead? The same comment applies to example 'f'.

Example 'e' is the logical opposite of 'c' and 'd' is the opposite of 'f' so why not swap 'd' and 'e' so that the "Share" cases are together and the "Schedule" cases are too?

Since all the examples really have a "possibly from different vendors" clause that is applicable but only some have it, why not put a statement about ALL the examples being in both a homogeneous and heterogenous enviorment?  For example, 'a' could easily be a Palm handlheld accessing his Domino server.  Its a single CUA accessing a single calendar but it is not simply a Notes CUA accessing a Domino calendar server...

#15: Bad iTIP example in 2.2 Protocol requirements

The example is missing a DTSTAMP, METHOD, UID and maybe more.  If the example is not supposed to be iTIP then a frame of reference is needed.  At least include the normally "mandatory" stuff like UID and DTSTAMP even if its not iTIP so we dont get "Is the example wrong?" questions later in last call or beyond.

For the labeled iTIP example, the missing UID MUST be put in

#16: Editorial nit:

The phrase "decline counters to, the various" does not require a comma in it.

#17: Editoral nit:

Is there any need for the phrase "
        Both CUAs and calendar services may have [ITIP]
        interpreters."
where it currently is??  I dont think so...

#18: Odd/misleading CAP descriptions

         [CAP] also provides a real-time binding for the calendar
        management messages.

is misleading as we currently have no calendar management messages in iTIP or iCal.  I think the phrase should have been something like:

         [CAP] also provides a real-time binding for the [ITIP]
        messages.

Also, above that is a very misleading paragraph:

         [CAP] describes the messages used to manage calendars. These
        messages are represented in [ICAL], and have semantics such as
        being a search for data, being data in response to a search or
        the being the creation of a meeting.

Again, nothing CAP uses for managing calendars is currently in 2445.  We are working on extensions to 2445 to do this.  The comments above about phrasing to include "[ICAL] and extentensions to [ICAL]" apply here too.  It also applies to the rest of the CAP description paragraphs in this section.

#19: Bad C/S example:

The C:/S: example is bad.  The example has:

            C:content-transfer-encoding: 7bit
           C:BEGIN:VCALENDAR
but there should be a "C:" between them (to have a CRLF in the stream between the header and the body).  Also the server response is illegal since it has:

            S: END:VCALENDAR
           S: Content-Type:text/calendar; method=RESPONSE;
which blurs the header of the second response into the body of the 1st.  KISS the example and make it simply create the entry on one calendar.  

The text "Furthermore, CAP
        is still a draft, thus the details of one can create
        such an event may change."
has a dangling "one" reference that needs a home.  Its unclear if the reference is to the example is in flux for CAP or what...

#20 Editorial nit:

      When specified using correct iCalendar grammar, we refer to these
     event representations or operation requests as " calendar object
     representations

is missing a final dquote.

#21 What did they say???

After reading and then rereading the following paragraph:

      A system may implement the first methodology only. The second one
     is dependent on iTIP. It requires understanding of iTIP and the
     ability to communicate with other CAP servers using iTIP. Since,
     currently, iMIP is the only binding of iTIP, the second method
     is also dependent on iMIP.

I just had to say "Huh?!?". Questions I have include:

1: What are you referring to with "A system"?  This is all in the context of the ICAL/ITIP/CAP and so I assume its "A calendaring system" but thats not a defined term so Im still assuming...
2: Both methodologies (not shown above) are dependent on iTIP, NOT just "the second one".  Ya cant implement iMIP w/o knowing iTIP.  So why single out "the second one"??
3: Why does the CAP require "the ability to communicate with other CAP servers using iTIP" instead of requiring the ability to speak CAP to other CAP servers???  One server does not speak iMIP to another CAP server (unless you are trying to tie in CRISP here but I dont think it works that way.)
4: The entire last line is circular reasoning and wrong.  CAP is new but so are CAP servers so there wont be any that only speak iMIP (they will speak CAP from the start!).  There is nothing in CAP (last I read it end to end) that mandates iMIP support so the last tidbit about dependence on iMIP is wrong.  A CAP server should speak CAP to another CAP server, NOT iMIP or some other "store and forward" binding.

Thats enough for now.  My 9 fingers are cramping up and I have other tasks I need to focus on for now.  More comments later...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 006B627585256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 15:37:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20974 for ; Mon, 19 Mar 2001 15:37:33 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA04547 for ietf-calendar-bks; Mon, 19 Mar 2001 12:18:05 -0800 (PST) Received: from agony.busboom.org (24-25-199-49.san.rr.com [24.25.199.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA04543 for ; Mon, 19 Mar 2001 12:18:04 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.0/8.11.0) with ESMTP id f2JKI6J19277 for ; Mon, 19 Mar 2001 12:18:06 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 19 Mar 2001 12:18:05 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Text of Proposed Changes to iCalendar Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is a new version of the proposed text for the issues on the iCalendar issues list. The list is online at: http://softwarestudio.org/iCal/2445Issues.html and the proposed text is online at: http://softwarestudio.org/iCal/ProposedChanges.txt Please read and comment on the proposed text. I haven't had many comments yet and I need your comments on the test before I incorporate them into the RFC. eric. From owner-ietf-calendar@mail.imc.org Mon Mar 19 16:29:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22331 for ; Mon, 19 Mar 2001 16:29:19 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id NAA07636 for ietf-calendar-bks; Mon, 19 Mar 2001 13:16:33 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA07626 for ; Mon, 19 Mar 2001 13:16:29 -0800 (PST) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: ietf-calendar@imc.org Subject: Re: Timezone TZID clashes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 16:18:11 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 04:17:03 PM, Serialize complete at 03/19/2001 04:17:03 PM Content-Type: multipart/alternative; boundary="=_alternative 0074D87685256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0074D87685256A14_= Content-Type: text/plain; charset="us-ascii" Damon proposed: >It would be better if the VTIMEZONE components had a PRODID property >and the LAST-MODIFIED property was made mandatory. We could then compare >VTIMEZONES by just comparing the PRODID and LAST-MODIFIED. This wont fix the problem, just move it around a bit. If a VTIMEZONE is updated to reflect additions instead of a change to an existing VDAYLIGHT or VSTANDARD then the LAST-MODIFIED would be different. As such, a sub-component by sub-component comparison would still be necessary to detect that only an addition was really made. Also, given the hackery that goes on in HTTP land with User-Agent and various tools/download managers/etc I would NOT want to rely on PRODID as a key for doing detection/comparison. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0074D87685256A14_= Content-Type: text/html; charset="us-ascii"
Damon proposed:
>It would be better if the VTIMEZONE components had a PRODID property
>and the LAST-MODIFIED property was made mandatory. We could then compare
>VTIMEZONES by just comparing the PRODID and LAST-MODIFIED.

This wont fix the problem, just move it around a bit.  If a VTIMEZONE is updated to reflect additions instead of a change to an existing VDAYLIGHT or VSTANDARD then the LAST-MODIFIED would be different.  As such, a sub-component by sub-component comparison would still be necessary to detect that only an addition was really made.

Also, given the hackery that goes on in HTTP land with User-Agent and various tools/download managers/etc I would NOT want to rely on PRODID as a key for doing detection/comparison.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0074D87685256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 16:50:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22873 for ; Mon, 19 Mar 2001 16:50:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA10138 for ietf-calendar-bks; Mon, 19 Mar 2001 13:39:23 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA10133 for ; Mon, 19 Mar 2001 13:39:22 -0800 (PST) From: Bruce_Kahn@iris.com To: John Stracke Cc: "ietf-calendar@imc.org" Subject: Re: Timezone TZID clashes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 16:41:09 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 04:39:53 PM, Serialize complete at 03/19/2001 04:39:53 PM Content-Type: multipart/alternative; boundary="=_alternative 0076F29E85256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076F29E85256A14_= Content-Type: text/plain; charset="us-ascii" John wrote: >Besides, what happens if the recipient COUNTERs with a time outside that >original range, a time at which the original VTIMEZONE disagrees with the reduced >one? Not an issue. The COUNTER is not relative to the REQUESTs TZ, it can be ANY date/time the ATTENDEE wants to COUNTER with. As such, it would use and send its own VTIMEZONE definitions, not reuse the REQUESTs. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0076F29E85256A14_= Content-Type: text/html; charset="us-ascii"
John wrote:
>Besides, what happens if the recipient COUNTERs with a time outside that
>original range, a time at which the original VTIMEZONE disagrees with the reduced
>one?

Not an issue.  The COUNTER is not relative to the REQUESTs TZ, it can be ANY date/time the ATTENDEE wants to COUNTER with.  As such, it would use and send its own VTIMEZONE definitions, not reuse the REQUESTs.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0076F29E85256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 16:51:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22915 for ; Mon, 19 Mar 2001 16:51:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA09795 for ietf-calendar-bks; Mon, 19 Mar 2001 13:35:28 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA09790 for ; Mon, 19 Mar 2001 13:35:26 -0800 (PST) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: John Stracke , ietf-calendar@imc.org Subject: Re: Timezone TZID clashes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03142001 March 14, 2001 Message-ID: Date: Mon, 19 Mar 2001 16:37:12 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 04:35:58 PM, Serialize complete at 03/19/2001 04:35:58 PM Content-Type: multipart/alternative; boundary="=_alternative 0076963A85256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076963A85256A14_= Content-Type: text/plain; charset="us-ascii" Damon replied with: >If the app loads/receives an iCalendar file with, for example, a "Europe/London" >VTIMEZONE calendar component, and the user then creates another time with the >timezone set to "Europe/London", then we have 2 "Europe/London" VTIMEZONE >components to place in the iCalendar file. Ok, Im probably too defocused on iCal right now but I do not quite grok the scenario fully. I get an invite from Damon w/a VTIMEZONE in it for "Europe/London". My CUA will crack open the incoming REQUEST and VTIMEZONE and converts it (at least internally) to, say, some UTC format relative to my default/configured TZ. How then do I create "another time" (a different entry or REQUEST??) for "Europe/London" that utilizies a different definition of that TZ? The new entry/event would utilize _my_ definition of "Europe/London" and when I send out REQUESTs it would contain _my_ VTIMEZONE for "Europe/London", not the one I received from Damon. Ahh, is it the case that your CUA uses iCalendar as the native file format and it just stores the raw streams together in some indexed way??? I would stipulate that the CUA that does this needs to 'localize' the entry if it can to avoid problems like you are mulling over. When I say 'localize' I mean TZ match and shift to its own definitions that match the ones coming in and use the matched defintions and change the date/time values accordingly before saving to a file. Matching is not always a trivial task (ie: RRULE on the REQUEST but RDATEs in the CUA for the same TZ definition) but its not as hard as some of our other workflow cases (like Delegation chains) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0076963A85256A14_= Content-Type: text/html; charset="us-ascii"
Damon replied with:
>If the app loads/receives an iCalendar file with, for example, a "Europe/London"
>VTIMEZONE calendar component, and the user then creates another time with the
>timezone set to "Europe/London", then we have 2 "Europe/London" VTIMEZONE
>components to place in the iCalendar file.

Ok, Im probably too defocused on iCal right now but I do not quite grok the scenario fully.  I get an invite from Damon w/a VTIMEZONE in it for "Europe/London".  My CUA will crack open the incoming REQUEST and VTIMEZONE and converts it (at least internally) to, say, some UTC format relative to my default/configured TZ.  How then do I create "another time" (a different entry or REQUEST??) for "Europe/London" that utilizies a different definition of that TZ?  The new entry/event would utilize _my_ definition of "Europe/London" and when I send out REQUESTs it would contain _my_ VTIMEZONE for "Europe/London", not the one I received from Damon.

Ahh, is it the case that your CUA uses iCalendar as the native file format and it just stores the raw streams together in some indexed way???  I would stipulate that the CUA that does this needs to 'localize' the entry if it can to avoid problems like you are mulling over.  When I say 'localize' I mean TZ match and shift to its own definitions that match the ones coming in and use the matched defintions and change the date/time values accordingly before saving to a file.  Matching is not always a trivial task (ie: RRULE on the REQUEST but RDATEs in the CUA for the same TZ definition) but its not as hard as some of our other workflow cases (like Delegation chains)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0076963A85256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 17:45:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24470 for ; Mon, 19 Mar 2001 17:45:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA13383 for ietf-calendar-bks; Mon, 19 Mar 2001 14:24:26 -0800 (PST) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA13378 for ; Mon, 19 Mar 2001 14:24:25 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2JMOTf08351 for ; Mon, 19 Mar 2001 14:24:29 -0800 (PST) Received: from netscape.com ([205.217.228.68]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GAGU8U00.N3C; Mon, 19 Mar 2001 14:24:30 -0800 Message-ID: <3AB68706.39633ADC@netscape.com> Date: Mon, 19 Mar 2001 14:24:06 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org Subject: Re: Guide: Defintion of CS References: Content-Type: multipart/mixed; boundary="------------415021EC96F8A01BD1538C3F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------415021EC96F8A01BD1538C3F Content-Type: multipart/alternative; boundary="------------9E13037B24D9765BBF833527" --------------9E13037B24D9765BBF833527 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > The latest draft says: > > Calendar Store > > A data store of a calendar service. A calendar service may > > have several calendar stores, and each store may contain > > several calendars, as well as properties and components > > outside of the calendars. > > I do not recall seeing any text about multiple stores in a service or > how a user would be able to access one store vs another in the > service. TARGETs are calendars and the CSIDs in CAP were for services > I thought so how do I access 1 store vs another?? > > Did I miss this addition to CAP?? Isn't this covered in section 2.6 ? Calendar Addresses. We have many examples of fully qualified csids. -Steve --------------9E13037B24D9765BBF833527 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:
The latest draft says:
>   Calendar Store
>      A data store of a calendar service. A calendar service may
>      have several calendar stores, and each store may contain
>      several calendars, as well as properties and components
>      outside of the calendars.

I do not recall seeing any text about multiple stores in a service or how a user would be able to access one store vs another in the service.  TARGETs are calendars and the CSIDs in CAP were for services I thought so how do I access 1 store vs another??

Did I miss this addition to CAP??

Isn't this covered in section 2.6 ?   Calendar Addresses.  We have many examples of fully qualified csids.

-Steve --------------9E13037B24D9765BBF833527-- --------------415021EC96F8A01BD1538C3F Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------415021EC96F8A01BD1538C3F-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 18:04:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24902 for ; Mon, 19 Mar 2001 18:04:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA14939 for ietf-calendar-bks; Mon, 19 Mar 2001 14:49:27 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA14934 for ; Mon, 19 Mar 2001 14:49:26 -0800 (PST) From: Bruce_Kahn@iris.com To: sman@netscape.com (Steve Mansour) Cc: ietf-calendar@imc.org Subject: Re: Guide: Defintion of CS MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_03182001 March 18, 2001 Message-ID: Date: Mon, 19 Mar 2001 17:49:49 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/19/2001 05:49:57 PM, Serialize complete at 03/19/2001 05:49:57 PM Content-Type: multipart/alternative; boundary="=_alternative 007D706485256A14_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007D706485256A14_= Content-Type: text/plain; charset="us-ascii" Steve responded with: > The latest draft says: > > Calendar Store > > A data store of a calendar service. A calendar service may > > have several calendar stores, and each store may contain > > several calendars, as well as properties and components > > outside of the calendars. > > I do not recall seeing any text about multiple stores in a service > or how a user would be able to access one store vs another in the > service. TARGETs are calendars and the CSIDs in CAP were for > services I thought so how do I access 1 store vs another?? > > Did I miss this addition to CAP?? > > Isn't this covered in section 2.6 ? Calendar Addresses. We have > many examples of fully qualified csids. Ok, I need to clarify my concerns. "The Guide" has the following definition for Calendar Store: Calendar Store A data store of a calendar service. A calendar service may have several calendar stores, and each store may contain several calendars, as well as properties and components outside of the calendars. but in CAP (Section 1.3 Defintions actually) it is defined as: Calendar Service An implementation of a Calendar Store that manages one or more calendars. Calendar Store (CS) The data and service model definition for a Calendar Service. Anyone else notice a distinct difference?? The entire tidbit about "several stores"! This is a non-trivial difference and one that is new to me. I _hope_ its just an editing remnant from an earlier version, NOT a new definition for CS. After all, what is the use of multiple stores in 1 server if TARGETs are not (STORE, CALENDAR) specific? Anyone care to imagine 1 server with 5 stores and the same CALENDAR in each?? Thats just another level of unwanted complexity. Ugh! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007D706485256A14_= Content-Type: text/html; charset="us-ascii"
Steve responded with:
> The latest draft says:
> >   Calendar Store
> >      A data store of a calendar service. A calendar service may
> >      have several calendar stores, and each store may contain
> >      several calendars, as well as properties and components
> >      outside of the calendars.
>
> I do not recall seeing any text about multiple stores in a service
> or how a user would be able to access one store vs another in the
> service.  TARGETs are calendars and the CSIDs in CAP were for
> services I thought so how do I access 1 store vs another??
>
> Did I miss this addition to CAP??
>
> Isn't this covered in section 2.6 ?   Calendar Addresses.  We have
> many examples of fully qualified csids.

Ok, I need to clarify my concerns.  "The Guide" has the following definition for Calendar Store:

   Calendar Store
     A data store of a calendar service. A calendar service may
     have several calendar stores, and each store may contain
     several calendars, as well as properties and components
     outside of the calendars.

but in CAP (Section 1.3 Defintions actually) it is defined as:

          Calendar Service
         
                 An implementation of a Calendar Store that manages
                 one or more calendars.

          Calendar Store (CS)
         
                 The data and service model definition for a Calendar
                 Service.

Anyone else notice a distinct difference??  The entire tidbit about "several stores"!  This is a non-trivial difference and one that is new to me.  I _hope_ its just an editing remnant from an earlier version, NOT a new definition for CS.  

After all, what is the use of multiple stores in 1 server if TARGETs are not (STORE, CALENDAR) specific?  Anyone care to imagine 1 server with 5 stores and the same CALENDAR in each??  Thats just another level of unwanted complexity.  Ugh!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007D706485256A14_=-- From owner-ietf-calendar@mail.imc.org Mon Mar 19 22:41:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04442 for ; Mon, 19 Mar 2001 22:41:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA26889 for ietf-calendar-bks; Mon, 19 Mar 2001 19:27:57 -0800 (PST) Received: from zeus.corpsite.com (zeus.corpsite.com [38.234.171.233]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA26884 for ; Mon, 19 Mar 2001 19:27:55 -0800 (PST) Received: from dhickman (cs27115-111.houston.rr.com [24.27.115.111]) (authenticated) by zeus.corpsite.com (8.11.1/8.11.1) with ESMTP id f2K3Ri526699 for ; Mon, 19 Mar 2001 22:27:44 -0500 (EST) Reply-To: From: "Dan Hickman" To: Subject: iCalendar vs. Microsoft Hailstorm? Date: Mon, 19 Mar 2001 21:28:19 -0600 Message-ID: <005501c0b0ed$d0d176e0$6f731b18@houston.rr.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01C0B0BB.863706E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C0B0BB.863706E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Greetings All ! Some of you may remember me. I've been away from the working group for a while now. I'd like to get some feedback on what everyone thinks of Microsoft's press release today that they will be providing calendar services as part of their Hailstorm web services (http://microsoft.com/presspass/features/2001/mar01/03-19hailstorm.asp). It doesn't seem as though Microsoft is participating in the working group anymore. Does this mean that they are abandoning iCalendar? Does anyone know why they are no longer active in the group? Regards, Dan Hickman Rockin' Software dhickman@rockinsoftware.com http://www.rockinsoftware.com ------=_NextPart_000_0056_01C0B0BB.863706E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Greetings All !
 
Some=20 of you may remember me.  I've been away from the working group for = a while=20 now.  I'd like to get some feedback on what everyone thinks of = Microsoft's=20 press release today that they will be providing calendar services as = part of=20 their Hailstorm web services (http://microsoft.com/presspass/features/2001/mar01/03-19hailstorm= .asp).
 
It=20 doesn't seem as though Microsoft is participating in the working group=20 anymore.  Does this mean that they are abandoning iCalendar?  = Does=20 anyone know why they are no longer active in the = group?
 
Regards,
Dan Hickman
Rockin' = Software
dhickman@rockinsoftware.com
http://www.rockinsoftware.com<= BR>
------=_NextPart_000_0056_01C0B0BB.863706E0-- From owner-ietf-calendar@mail.imc.org Tue Mar 20 00:41:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08427 for ; Tue, 20 Mar 2001 00:41:40 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id VAA28683 for ietf-calendar-bks; Mon, 19 Mar 2001 21:29:20 -0800 (PST) Received: from localhost.localdomain (pcp000702pcs.wireless.meeting.ietf.org [135.222.64.202]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA28678 for ; Mon, 19 Mar 2001 21:29:18 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2K5a8B03970; Tue, 20 Mar 2001 00:36:08 -0500 Message-ID: <3AB6D6D4.7AF17EFE@ecal.com> Date: Mon, 19 Mar 2001 22:04:36 -0600 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: calsch WG , iptel@lists.bell-labs.com Subject: Current thinking on CPL/iCalendar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit We talked about the CPL/iCalendar issue at the calsch dinner tonight. The outcome (such as it is): * Some of us, at least, like the idea of cutting back iCalendar's RECUR semantics to match the CPL semantics (as I described in the informal Draft I posted last Monday). * The changes: o In order to prevent overlapping instances, which complicate evaluation: + Recurring events cannot have a DURATION over 24 hours. + The interval between instances must be less than 24 hours. + All the RECUR parameters for sub-day values (e.g., BYSEC, BYMIN, BYHOUR) are removed. o COUNT and BYSETPOS are removed, so that you don't have to step through the instances linearly in order to evaluate the rule. * Possible impact on existing (or potential) applications: o No overlapping instances--can anybody provide a plausible scenario where you'd want them? o Unable to schedule sub-day recurrences--is this a problem? They were apparently put in for people who wanted to schedule bandwidth allocation at a very fine granularity; is anybody still interested in this? o COUNT can be replaced with UNTIL. o BYSETPOS can be replaced with EXDATEs. So. Please think it over so we can discuss it in the meeting Wednesday. (If you're not here, it'd be helpful if you can post before the meeting.) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |This space intentionally not left blank. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 20 08:18:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04779 for ; Tue, 20 Mar 2001 08:18:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA13716 for ietf-calendar-bks; Tue, 20 Mar 2001 05:05:01 -0800 (PST) Received: from pivsbh1.ms.com (pivsbh1.ms.com [199.89.64.103]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA13708 for ; Tue, 20 Mar 2001 05:04:55 -0800 (PST) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id IAA21839; Tue, 20 Mar 2001 08:01:47 -0500 (EST) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9850933071.021830; Tue, 20 Mar 01 08:01:47 -0500 Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/8.11.2) id IAA21801; Tue, 20 Mar 2001 08:01:47 -0500 (EST) Received: from unknown(144.14.206.187) by pivsbh1 via smap (4.1) id sma.9850933051.021763; Tue, 20 Mar 01 08:01:45 -0500 Received: from msdw.com (vpn2766036.morgan.com [172.27.66.36]) by pismh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id IAA06031; Tue, 20 Mar 2001 08:01:45 -0500 (EST) Message-ID: <3AB754BA.880F293C@msdw.com> Date: Tue, 20 Mar 2001 08:01:46 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.75 [en]C-CCK-MCD MS4.75 V20000913.1 (Windows NT 5.0; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: John Stracke CC: calsch WG , iptel@lists.bell-labs.com Subject: Re: Current thinking on CPL/iCalendar References: <3AB6D6D4.7AF17EFE@ecal.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms24960309373B4D10199F8F3D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms24960309373B4D10199F8F3D Content-Type: multipart/mixed; boundary="------------8F237154C511476F9C919E6E" This is a multi-part message in MIME format. --------------8F237154C511476F9C919E6E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > We talked about the CPL/iCalendar issue at the calsch dinner > tonight. The outcome (such as it is): > > + The interval between instances must be less than > 24 hours. I'm assuming this is reversed and should be "more". Otherwise my weekly meetings are going to be a bit difficult. A counter example would be the pill that I have to take every four hours. > * Possible impact on existing (or potential) applications: > o No overlapping instances--can anybody provide a > plausible scenario where you'd want them? Our training dept schedules multiple instances of the "same" class which sometimes overlap. I could easily be swayed by the argument that there should be multiple "threads" on a per instructor basis, or perhaps by room. Just pointing out one possibility. > o Unable to schedule sub-day recurrences--is this a > problem? They were apparently put in for people who > wanted to schedule bandwidth allocation at a very fine > granularity; is anybody still interested in this? My pill example Wish I could be there... dmadeo --------------8F237154C511476F9C919E6E Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;pager:dmadeo@skytel.com or 888-354-8513 tel;cell:917-295-9893 tel;fax:1877-545-8846 tel;work:212-762-2348 x-mozilla-html:TRUE url:www.msdw.com org:Information Technology;Morgan Stanley, Dean Witter and Discover adr:;;750 Seventh Ave;New York;NY;10019;US version:2.1 email;internet:david.madeo@msdw.com title:Vice President fn:David Madeo end:vcard --------------8F237154C511476F9C919E6E-- --------------ms24960309373B4D10199F8F3D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKbAYJKoZIhvcNAQcCoIIKXTCCClkCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDUwggUTMIIEfKADAgECAhAmLAz9r3s0IQlzFUGDnfQHMA0GCSqGSIb3DQEBBAUAMIGPMR8w HQYDVQQKExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSkwJwYDVQQLFCBNb3JnYW4gU3Rhbmxl eSBEZWFuIFdpdHRlciAmIENvLjFBMD8GA1UECxQ4TW9yZ2FuIFN0YW5sZXkgRGVhbiBXaXR0 ZXIgJiBDby4gQ2xhc3MgMiAtIEluZGl2aWR1YWwgQ0EwHhcNMDAwMzMwMDAwMDAwWhcNMDEw MzMwMjM1OTU5WjCB4zEpMCcGA1UEChQgTW9yZ2FuIFN0YW5sZXkgRGVhbiBXaXR0ZXIgJiBD by4xIDAeBgNVBAsUF0NsYXNzIDIgLSBJbmRpdmlkdWFsIENBMUYwRAYDVQQLEz13d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2 MREwDwYDVQQMFAhFbXBsb3llZTEUMBIGA1UEAxMLRGF2aWQgTWFkZW8xIzAhBgkqhkiG9w0B CQEWFGRhdmlkLm1hZGVvQG1zZHcuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCz hjCOwOgqHm4CYiTiAseSXn0z+6zv6O/llTC1ToFiyN0+uXJK02NCfKxB641qLfi2aMZEkJXX KRrW0hLFAI2lzCrLkO4njbMFsr9E/jVTgTWHu5IlADSSgqVhL/v4a7K3SofP1iuzh0nd3S6q 1GvaXZnjTAM0jgMJeAR0iGm4BwIDAQABo4ICGDCCAhQwCQYDVR0TBAIwADBkBgNVHR8EXTBb MFmgV6BVhlNodHRwOi8vb25zaXRlY3JsLnZlcmlzaWduLmNvbS9Nb3JnYW5TdGFubGV5RGVh bldpdHRlckNvQ2xhc3MySW5kaXZpZHVhbENBL0xhdGVzdENSTDALBgNVHQ8EBAMCB4AwgawG A1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEB Gj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3 IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDARBgpghkgBhvhFAQYJBAMBAf8wgb4GCmCG SAGG+EUBBg4Ega8WgaxPQ1hHYnFsaEtjRjhqVDN3REFwMDloNkhLdkozcm5INzhOeEo3N0po WnRaeGc5Y05oSXgwSTZZNXo4Ull0dmwrTXg5QzhpVG43VldFWmlFdmNRRmthemwwNFdIZFh6 QTRodWQ4RDNrMi9kNnZIY1o2Vm9yeW0rdXNOK3RqSExBdFR6VHUzNVVWY0t5ZExSd0pOdkxW NTdVY05MTytzS09zMzBJR2NINnhsQlk9MA0GCSqGSIb3DQEBBAUAA4GBAIRHJ1FbQ2mHYug2 H0ZI+2C2RT1cd2280GTtE4K1PK4uZhVKkAfLeKOktIp53BQhyP21gUQupXnWaOx5/lCCtQa9 EAg6z66++v9RFX0885mmpCJsT6/KOWoqWPkPIsKd27a3d+i7bYV35feb+ZZkvVzDO/hWyE5O JvK325pdQpC4MIIDGjCCAoOgAwIBAgIRAIx4wGZDfh2AKJUmqcr3Mn0wDQYJKoZIhvcNAQEE BQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5D bGFzcyAyIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDQz MDAwMDAwMFoXDTAzMDQzMDIzNTk1OVowgY8xHzAdBgNVBAoTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxKTAnBgNVBAsUIE1vcmdhbiBTdGFubGV5IERlYW4gV2l0dGVyICYgQ28uMUEwPwYD VQQLFDhNb3JnYW4gU3RhbmxleSBEZWFuIFdpdHRlciAmIENvLiBDbGFzcyAyIC0gSW5kaXZp ZHVhbCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtZlEfyqZK1R38UYr148tIZTe 29Jpr01x+6SNN9JvnCZGi2eFfCudAzDC7xDnDFzcFtBIRHk4i03axe1ZkDSHiGmuWTfL0Bmp elMtWYP0GOC6JrQXiBcJs9RpMjXJ8aHZNxx/FLAIYccTf6HzZTJhWIdVX/N8Bf78bkovu5L2 G+UCAwEAAaOBpDCBoTAoBgNVHREEITAfpB0wGzEZMBcGA1UEAxMQUHJpdmF0ZUxhYmVsMS00 NjARBglghkgBhvhCAQEEBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcBATAqMCgGCCsG AQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vUlBBMA8GA1UdEwQIMAYBAf8CAQAw CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAGOBvA7CnnJnpd7i/K2oXnazlmCQgEM7 Mur7kfsXgsHX+CLHR3IMTqg1FjXOM5wkLwQ62YcISPuqKIEBqFr7irLgTQiAfIF7sIy/RzK3 +JqekTP7DQ6J1b9V3N2XaQwfaVIKgatOAWkpnHB8vthizZC+f558u5eprm0m1XgTKZpIMYIB /zCCAfsCAQEwgaQwgY8xHzAdBgNVBAoTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxKTAnBgNV BAsUIE1vcmdhbiBTdGFubGV5IERlYW4gV2l0dGVyICYgQ28uMUEwPwYDVQQLFDhNb3JnYW4g U3RhbmxleSBEZWFuIFdpdHRlciAmIENvLiBDbGFzcyAyIC0gSW5kaXZpZHVhbCBDQQIQJiwM /a97NCEJcxVBg530BzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAxMDMyMDEzMDE0NlowIwYJKoZIhvcNAQkEMRYEFNKDMkiJbn+H YuXdAK1J6d6uzsK3MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAHgAd68pgEXDxboKL3AIxwiRnqfwE4BHmcmifMBLnqLE+lGtbndBFzMocS/eFnvnN s2Ly9pEqXtkPT1Ubi9e6gS81gF6KIEjt5aDK/4JHEdZRaIM6tiimsPuyjGanCewIdYyx2aPL JCaHP2yUGS4/wrByC6OJZzSTvKueD2eA/HA= --------------ms24960309373B4D10199F8F3D-- From owner-ietf-calendar@mail.imc.org Tue Mar 20 09:48:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07868 for ; Tue, 20 Mar 2001 09:48:07 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id GAA19626 for ietf-calendar-bks; Tue, 20 Mar 2001 06:31:24 -0800 (PST) Received: from cisco.com (nordic.cisco.com [144.254.116.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA19618 for ; Tue, 20 Mar 2001 06:31:21 -0800 (PST) Received: from [135.222.95.169] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA23772; Tue, 20 Mar 2001 15:30:42 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3AB754BA.880F293C@msdw.com> References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> Date: Tue, 20 Mar 2001 08:30:32 -0600 To: David Madeo , John Stracke From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Current thinking on CPL/iCalendar Cc: calsch WG , iptel@lists.bell-labs.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id GAA19626 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA07868 At 08.01 -0500 01-03-20, David Madeo wrote: >John Stracke wrote: > >> We talked about the CPL/iCalendar issue at the calsch dinner >> tonight. The outcome (such as it is): >> >> + The interval between instances must be less than >> 24 hours. > >I'm assuming this is reversed and should be "more". Otherwise my >weekly meetings are going to be a bit difficult. >A counter example would be the pill that I have to take every four >hours. Question: Is not the requirement for O(1) that the interval between events have to be longer than the length of the event itself? I.e. removing support for sub-24h recurrances seems too arbitrary if not really needed. > > * Possible impact on existing (or potential) applications: >> o No overlapping instances--can anybody provide a >> plausible scenario where you'd want them? > >Our training dept schedules multiple instances of the "same" class >which sometimes overlap. I could easily be swayed by the argument >that there should be multiple "threads" on a per instructor basis, or >perhaps by room. Just pointing out one possibility. The need for non-overlapping events is the largest requirement for O(1) isn't it? Because of this I think it should be stated as the main goal for these changes. paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-6859131 (San Jose) +1-408-525-8509 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-calendar@mail.imc.org Tue Mar 20 10:00:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08267 for ; Tue, 20 Mar 2001 10:00:47 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id GAA20794 for ietf-calendar-bks; Tue, 20 Mar 2001 06:49:14 -0800 (PST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA20787 for ; Tue, 20 Mar 2001 06:49:13 -0800 (PST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA03869; Tue, 20 Mar 2001 09:49:06 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id JAA17542; Tue, 20 Mar 2001 09:49:05 -0500 (EST) Message-ID: <3AB7990D.3AF869C0@cs.columbia.edu> Date: Tue, 20 Mar 2001 09:53:17 -0800 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Current thinking on CPL/iCalendar References: <3AB6D6D4.7AF17EFE@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit One related item discussed was whether some elements (such as COUNT) can be retained if CPL-implementing servers are "willing" to convert COUNT to UNTIL when the CPL script is uploaded, so that the actual call handling is still O(1). This obviously makes sense only if the upload frequency is significantly lower than the call frequency. John Stracke wrote: > > We talked about the CPL/iCalendar issue at the calsch dinner > tonight. The outcome (such as it is): > > * Some of us, at least, like the idea of cutting back > iCalendar's RECUR semantics to match the CPL semantics (as I > described in the informal Draft I posted last Monday). > * The changes: > o In order to prevent overlapping instances, which > complicate evaluation: > + Recurring events cannot have a DURATION over 24 > hours. > + The interval between instances must be less than > 24 hours. > + All the RECUR parameters for sub-day values (e.g., > BYSEC, BYMIN, BYHOUR) are removed. > o COUNT and BYSETPOS are removed, so that you don't have > to step through the instances linearly in order to > evaluate the rule. > * Possible impact on existing (or potential) applications: > o No overlapping instances--can anybody provide a > plausible scenario where you'd want them? > o Unable to schedule sub-day recurrences--is this a > problem? They were apparently put in for people who > wanted to schedule bandwidth allocation at a very fine > granularity; is anybody still interested in this? > o COUNT can be replaced with UNTIL. > o BYSETPOS can be replaced with EXDATEs. > > So. Please think it over so we can discuss it in the meeting > Wednesday. (If you're not here, it'd be helpful if you can post > before the meeting.) > > -- > /==============================================================\ > |John Stracke | http://www.ecal.com |My opinions are my own.| > |Chief Scientist |=============================================| > |eCal Corp. |This space intentionally not left blank. | > |francis@ecal.com| | > \==============================================================/ > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel From owner-ietf-calendar@mail.imc.org Tue Mar 20 10:17:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08961 for ; Tue, 20 Mar 2001 10:17:07 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA21654 for ietf-calendar-bks; Tue, 20 Mar 2001 07:05:08 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA21650 for ; Tue, 20 Mar 2001 07:05:07 -0800 (PST) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2KF57920406; Tue, 20 Mar 2001 07:05:07 -0800 (PST) Received: from netscape.com (sera-nuq-205-217-228-94.mcom.com [205.217.228.94]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id HAA24169224; Tue, 20 Mar 2001 07:10:11 -0800 (PST) Message-ID: <3AB77183.53C3B387@netscape.com> Date: Tue, 20 Mar 2001 07:04:35 -0800 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: David Madeo , John Stracke , calsch WG , iptel@lists.bell-labs.com Subject: Re: Current thinking on CPL/iCalendar References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> Content-Type: multipart/mixed; boundary="------------771BC2432BC928B142B2216F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------771BC2432BC928B142B2216F Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA21654 Content-Transfer-Encoding: quoted-printable Patrik F=E4ltstr=F6m wrote: > At 08.01 -0500 01-03-20, David Madeo wrote: > >John Stracke wrote: > > > >> We talked about the CPL/iCalendar issue at the calsch dinner > >> tonight. The outcome (such as it is): > >> > >> + The interval between instances must be less than > >> 24 hours. > > > >I'm assuming this is reversed and should be "more". Otherwise my > >weekly meetings are going to be a bit difficult. > >A counter example would be the pill that I have to take every four > >hours. > > Question: Is not the requirement for O(1) that the interval between > events have to be longer than the length of the event itself? yes, that is the spirit of what we're after. Even durations must be shor= ter than the recurrence interval. It turns out that one of the editor's implementa= tion was driving the need for the 24hr number in the proposal. > I.e. removing support for sub-24h recurrances seems too arbitrary if > not really needed. > > > > * Possible impact on existing (or potential) applications: > >> o No overlapping instances--can anybody provide a > >> plausible scenario where you'd want them? > > > >Our training dept schedules multiple instances of the "same" class > >which sometimes overlap. I could easily be swayed by the argument > >that there should be multiple "threads" on a per instructor basis, or > >perhaps by room. Just pointing out one possibility. > > The need for non-overlapping events is the largest requirement for > O(1) isn't it? Overlapping events are common. I think the need is for non-overlapping recurrences. -Steve --------------771BC2432BC928B142B2216F Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------771BC2432BC928B142B2216F-- From owner-ietf-calendar@mail.imc.org Tue Mar 20 10:19:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09080 for ; Tue, 20 Mar 2001 10:19:36 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA21593 for ietf-calendar-bks; Tue, 20 Mar 2001 07:02:32 -0800 (PST) Received: from mail2.svr.pol.co.uk (mail2.svr.pol.co.uk [195.92.193.210]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA21588 for ; Tue, 20 Mar 2001 07:02:30 -0800 (PST) Received: from modem-189.keyhole-angel.dialup.pol.co.uk ([62.137.34.189] helo=ximian.com) by mail2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14fNeQ-000417-00; Tue, 20 Mar 2001 15:02:23 +0000 Message-ID: <3AB76FE3.72EA811E@ximian.com> Date: Tue, 20 Mar 2001 14:57:39 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: John Stracke , ietf-calendar@imc.org Subject: Re: Timezone TZID clashes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > Damon replied with: > >If the app loads/receives an iCalendar file with, for example, a "Europe/London" > >VTIMEZONE calendar component, and the user then creates another time with the > >timezone set to "Europe/London", then we have 2 "Europe/London" VTIMEZONE > >components to place in the iCalendar file. > > Ok, Im probably too defocused on iCal right now but I do not quite grok the scenario fully. I get an invite from Damon w/a VTIMEZONE in it for > "Europe/London". My CUA will crack open the incoming REQUEST and VTIMEZONE and converts it (at least internally) to, say, some UTC format relative to my > default/configured TZ. How then do I create "another time" (a different entry or REQUEST??) for "Europe/London" that utilizies a different definition of that > TZ? The new entry/event would utilize _my_ definition of "Europe/London" and when I send out REQUESTs it would contain _my_ VTIMEZONE for "Europe/London", > not the one I received from Damon. > > Ahh, is it the case that your CUA uses iCalendar as the native file format and it just stores the raw streams together in some indexed way??? Yes, we just save a user's calendar in one big iCalendar file. > I would > stipulate that the CUA that does this needs to 'localize' the entry if it can to avoid problems like you are mulling over. When I say 'localize' I mean TZ > match and shift to its own definitions that match the ones coming in and use the matched defintions and change the date/time values accordingly before saving > to a file. Matching is not always a trivial task (ie: RRULE on the REQUEST but RDATEs in the CUA for the same TZ definition) but its not as hard as some of > our other workflow cases (like Delegation chains) If you have a complex, infinite RRULE I think it would be very difficult to convert from one VTIMEZONE to another. Even if it is possible, do we really want iCalendar to be this complex? John said there may be a problem with iTIP if we rename TZIDs when they conflict. Do you know if that is the case? If not, I'm hoping to do that. The only other thing I can think of doing is just ignore conflicts (in the hope that everyone is shipping perfect VTIMEZONE files). Damon From owner-ietf-calendar@mail.imc.org Tue Mar 20 10:32:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09621 for ; Tue, 20 Mar 2001 10:31:59 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA22343 for ietf-calendar-bks; Tue, 20 Mar 2001 07:18:15 -0800 (PST) Received: from cisco.com (nordic.cisco.com [144.254.116.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA22334 for ; Tue, 20 Mar 2001 07:18:08 -0800 (PST) Received: from [135.222.95.169] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA05564; Tue, 20 Mar 2001 16:17:01 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3AB77183.53C3B387@netscape.com> References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> <3AB77183.53C3B387@netscape.com> Date: Tue, 20 Mar 2001 09:16:31 -0600 To: Steve Mansour From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Current thinking on CPL/iCalendar Cc: David Madeo , John Stracke , calsch WG , iptel@lists.bell-labs.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA22343 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09621 At 07.04 -0800 01-03-20, Steve Mansour wrote: >Patrik Fältström wrote: > > > Question: Is not the requirement for O(1) that the interval between >> events have to be longer than the length of the event itself? > >yes, that is the spirit of what we're after. Even durations must be >shorter than the recurrence interval. It turns out that one of the >editor's implementation was driving the need for the 24hr number in >the proposal. So, you are saying that my suggestion to change the 24h limit to instead a comparison between the length of the event and the length of the interval? > > The need for non-overlapping events is the largest requirement for >> O(1) isn't it? > >Overlapping events are common. I think the need is for non-overlapping >recurrences. Of course. My mistake. This was what I wanted to write... paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-6859131 (San Jose) +1-408-525-8509 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-calendar@mail.imc.org Tue Mar 20 10:34:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09710 for ; Tue, 20 Mar 2001 10:34:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA22844 for ietf-calendar-bks; Tue, 20 Mar 2001 07:22:18 -0800 (PST) Received: from localhost.localdomain (pcp000702pcs.wireless.meeting.ietf.org [135.222.64.202]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA22839 for ; Tue, 20 Mar 2001 07:22:17 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2KFT5v04966; Tue, 20 Mar 2001 10:29:05 -0500 Message-ID: <3AB77741.D9E3C548@ecal.com> Date: Tue, 20 Mar 2001 09:29:05 -0600 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: calsch WG CC: iptel@lists.bell-labs.com Subject: Re: Current thinking on CPL/iCalendar References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA22844 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09710 Patrik Fältström wrote: > Question: Is not the requirement for O(1) that the interval between > events have to be longer than the length of the event itself? > > I.e. removing support for sub-24h recurrances seems too arbitrary if > not really needed. We thought about that; but a straightforward limit like this is much easier to explain to a user, and incorporate in a UI. > The need for non-overlapping events is the largest requirement for > O(1) isn't it? Yes. > Because of this I think it should be stated as the main goal for these changes. OK. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Think of it as evolution in action. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 20 10:39:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09898 for ; Tue, 20 Mar 2001 10:39:37 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA24418 for ietf-calendar-bks; Tue, 20 Mar 2001 07:28:50 -0800 (PST) Received: from localhost.localdomain (pcp000702pcs.wireless.meeting.ietf.org [135.222.64.202]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA24411 for ; Tue, 20 Mar 2001 07:28:49 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2KFZbv05006 for ; Tue, 20 Mar 2001 10:35:37 -0500 Message-ID: <3AB778C8.D6C0DF4F@ecal.com> Date: Tue, 20 Mar 2001 09:35:36 -0600 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: iCalendar vs. Microsoft Hailstorm? References: <005501c0b0ed$d0d176e0$6f731b18@houston.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dan Hickman wrote: > It doesn't seem as though Microsoft is participating in the > working group anymore. Does this mean that they are abandoning > iCalendar? They've been implementing iCalendar in their newer desktop apps. However, I could envision them making an argument that, in the Hailstorm world, where the data all lives on the server, data exchange is a moot point. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Please do not look into laser with remaining | |francis@ecal.com|eyeball. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 20 10:42:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10019 for ; Tue, 20 Mar 2001 10:42:05 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA23898 for ietf-calendar-bks; Tue, 20 Mar 2001 07:26:33 -0800 (PST) Received: from localhost.localdomain (pcp000702pcs.wireless.meeting.ietf.org [135.222.64.202]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA23887 for ; Tue, 20 Mar 2001 07:26:32 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f2KFXLv04991; Tue, 20 Mar 2001 10:33:21 -0500 Message-ID: <3AB77840.8134F167@ecal.com> Date: Tue, 20 Mar 2001 09:33:21 -0600 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: calsch WG CC: iptel@lists.bell-labs.com Subject: Re: Current thinking on CPL/iCalendar References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit David Madeo wrote: > John Stracke wrote: > > > + The interval between instances must be less than > > 24 hours. > > I'm assuming this is reversed and should be "more". Yes. > Otherwise my > weekly meetings are going to be a bit difficult. > A counter example would be the pill that I have to take every four > hours. Yeah, we thought of that one. The problem is that such usages are really the 5% case; and supporting them complicates the 95% case. Your every-four-hours event could be implemented as six related every-twenty-four-hours events--ugly, but the current recurrence grammar is even uglier. > > o No overlapping instances--can anybody provide a > > plausible scenario where you'd want them? > > Our training dept schedules multiple instances of the "same" class > which sometimes overlap. I could easily be swayed by the argument > that there should be multiple "threads" on a per instructor basis, or > perhaps by room. Yes, that's what we were thinking of. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I'm not imaginary. I'm ontologically challenged.| |francis@ecal.com| | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Mar 20 10:48:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10259 for ; Tue, 20 Mar 2001 10:48:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA25031 for ietf-calendar-bks; Tue, 20 Mar 2001 07:31:17 -0800 (PST) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA25005 for ; Tue, 20 Mar 2001 07:31:11 -0800 (PST) From: Bruce_Kahn@iris.com Subject: Re: Current thinking on CPL/iCalendar To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: David Madeo , John Stracke , calsch WG , iptel@lists.bell-labs.com X-Mailer: Lotus Notes Build V60_03012001 March 01, 2001 Message-ID: Date: Tue, 20 Mar 2001 10:31:33 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V507_02052001 |February 5, 2001) at 03/20/2001 10:33:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id HAA25007 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA25031 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10259 Patrik replied: > Question: Is not the requirement for O(1) that the interval between > events have to be longer than the length of the event itself? > > I.e. removing support for sub-24h recurrances seems too arbitrary if > not really needed. It may be part of the IPTEL but its not part of CALSCH's requirements. I dont see any rationale for this need so Im not sure _why_ it would exist. > >Our training dept schedules multiple instances of the "same" class > >which sometimes overlap. I could easily be swayed by the argument > >that there should be multiple "threads" on a per instructor basis, or > >perhaps by room. Just pointing out one possibility. > > The need for non-overlapping events is the largest requirement for > O(1) isn't it? Perhaps Im just not focused enough on O(1) but I do not see how restricting to non-overlapping entries makes the performace faster. I can understand restricting the use or values in, say, an RRULEs due to potentially heavy roll times. I dont see how overlapping, explicit RDATEs violates or prohibits O(1) so can someone please codify why? Similar example to Daves: A theatre lists a movie once but it may have overlapping show times. It is not that logical to have them PUBLISH movie times based on each individual thatre; its more logical to just list all the showing times for a title. A museum or company that conducts tours may have staggered schedules. Instead of scheduling on a tour guide by tour guide basis, they are scheduling on a tour by tour schedule. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... owner-ietf-calendar@mail.imc.org wrote on 03/20/2001 09:30:32 AM: > At 08.01 -0500 01-03-20, David Madeo wrote: > >John Stracke wrote: > > > >> We talked about the CPL/iCalendar issue at the calsch dinner > >> tonight. The outcome (such as it is): > >> > >> + The interval between instances must be less than > >> 24 hours. > > > >I'm assuming this is reversed and should be "more". Otherwise my > >weekly meetings are going to be a bit difficult. > >A counter example would be the pill that I have to take every four > >hours. > > > > > * Possible impact on existing (or potential) applications: > >> o No overlapping instances--can anybody provide a > >> plausible scenario where you'd want them? > > > >Our training dept schedules multiple instances of the "same" class > >which sometimes overlap. I could easily be swayed by the argument > >that there should be multiple "threads" on a per instructor basis, or > >perhaps by room. Just pointing out one possibility. > > The need for non-overlapping events is the largest requirement for > O(1) isn't it? > > Because of this I think it should be stated as the main goal for > these changes. > > paf > > > -- > Patrik Fältström Internet Engineering Task Force > Area Director, Applications Area http://www.ietf.org > Phone: (Stockholm) +46-8-6859131 (San Jose) +1-408-525-8509 > PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-calendar@mail.imc.org Tue Mar 20 11:00:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10809 for ; Tue, 20 Mar 2001 11:00:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA27573 for ietf-calendar-bks; Tue, 20 Mar 2001 07:44:13 -0800 (PST) Received: from cisco.com (nordic.cisco.com [144.254.116.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA27545 for ; Tue, 20 Mar 2001 07:44:10 -0800 (PST) Received: from [135.222.95.169] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA11393; Tue, 20 Mar 2001 16:43:38 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <3AB77741.D9E3C548@ecal.com> References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> <3AB77741.D9E3C548@ecal.com> Date: Tue, 20 Mar 2001 09:41:57 -0600 To: John Stracke , calsch WG From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Current thinking on CPL/iCalendar Cc: iptel@lists.bell-labs.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA27573 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA10809 At 09.29 -0600 01-03-20, John Stracke wrote: >Patrik Fältström wrote: > >> Question: Is not the requirement for O(1) that the interval between > > events have to be longer than the length of the event itself? > > > > I.e. removing support for sub-24h recurrances seems too arbitrary if > > not really needed. > >We thought about that; but a straightforward limit like this is much easier to >explain to a user, and incorporate in a UI. ...but it means that you can never have recurrance rules which handle the "medication problem"...or a recurrance rule which tells when the busses are leaving for a social event (starting 17:00, every 15 minutes, 5 times). You are the ones making the decision, but I think you should think very hard wether you want this kind of limitation (a fixed limit) when the overlap is the most important thing, and the problem you try to solve. An application can still prohibit the user from entering whatever if it wants to... paf From owner-ietf-calendar@mail.imc.org Tue Mar 20 11:02:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10857 for ; Tue, 20 Mar 2001 11:02:00 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA27551 for ietf-calendar-bks; Tue, 20 Mar 2001 07:44:11 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA27483 for ; Tue, 20 Mar 2001 07:44:05 -0800 (PST) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2KFi9927135; Tue, 20 Mar 2001 07:44:09 -0800 (PST) Received: from netscape.com (sera-nuq-205-217-228-72.mcom.com [205.217.228.72]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id HAA24252187; Tue, 20 Mar 2001 07:49:12 -0800 (PST) Message-ID: <3AB77AA8.33919371@netscape.com> Date: Tue, 20 Mar 2001 07:43:36 -0800 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: David Madeo , John Stracke , calsch WG , iptel@lists.bell-labs.com Subject: Re: Current thinking on CPL/iCalendar References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> <3AB77183.53C3B387@netscape.com> Content-Type: multipart/mixed; boundary="------------42291FB2DA82C29B839554C6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------42291FB2DA82C29B839554C6 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA27551 Content-Transfer-Encoding: quoted-printable Patrik F=E4ltstr=F6m wrote: > At 07.04 -0800 01-03-20, Steve Mansour wrote: > >Patrik F=E4ltstr=F6m wrote: > > > > > Question: Is not the requirement for O(1) that the interval betwee= n > >> events have to be longer than the length of the event itself? > > > >yes, that is the spirit of what we're after. Even durations must be > >shorter than the recurrence interval. It turns out that one of the > >editor's implementation was driving the need for the 24hr number in > >the proposal. > > So, you are saying that my suggestion to change the 24h limit to > instead a comparison between the length of the event and the length > of the interval? > That is what I would prefer. Seems like the right thing to do. I know tha= t there were people who wanted recurrence intervals less than 24 hours when= we were writing iCalendar. Seems like it would be a bad move to pull that capability away -- especially if we have no alternative way to describe recurrence intervals less than a day. As far as removing the COUNT, this is bad but I understand their reasonin= g, and at least there is a way to get pretty much the same functionality usi= ng UNTIL. I will be interested to see how the group at large reacts to this proposal. -Steve --------------42291FB2DA82C29B839554C6 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------42291FB2DA82C29B839554C6-- From owner-ietf-calendar@mail.imc.org Tue Mar 20 11:12:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11345 for ; Tue, 20 Mar 2001 11:12:21 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id HAA29389 for ietf-calendar-bks; Tue, 20 Mar 2001 07:55:45 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29379 for ; Tue, 20 Mar 2001 07:55:44 -0800 (PST) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2KFtk929009; Tue, 20 Mar 2001 07:55:46 -0800 (PST) Received: from netscape.com (sera-nuq-205-217-228-72.mcom.com [205.217.228.72]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id IAA24117045; Tue, 20 Mar 2001 08:00:50 -0800 (PST) Message-ID: <3AB77D65.B9A4BBA6@netscape.com> Date: Tue, 20 Mar 2001 07:55:17 -0800 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: calsch WG , iptel@lists.bell-labs.com Subject: Re: Current thinking on CPL/iCalendar References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> <3AB77741.D9E3C548@ecal.com> Content-Type: multipart/mixed; boundary="------------A9E8CE0A501CC4EF7B7E0048" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A9E8CE0A501CC4EF7B7E0048 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id HAA29389 Content-Transfer-Encoding: quoted-printable John Stracke wrote: > Patrik F=E4ltstr=F6m wrote: > > > Question: Is not the requirement for O(1) that the interval between > > events have to be longer than the length of the event itself? > > > > I.e. removing support for sub-24h recurrances seems too arbitrary if > > not really needed. > > We thought about that; but a straightforward limit like this is much ea= sier to > explain to a user, and incorporate in a UI. That is true. But a UI of an application can enforce the 24 hr limit with= out imposing that limit on iCalendar. -Steve --------------A9E8CE0A501CC4EF7B7E0048 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------A9E8CE0A501CC4EF7B7E0048-- From owner-ietf-calendar@mail.imc.org Tue Mar 20 11:17:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11609 for ; Tue, 20 Mar 2001 11:17:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA00522 for ietf-calendar-bks; Tue, 20 Mar 2001 08:04:51 -0800 (PST) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA00510 for ; Tue, 20 Mar 2001 08:04:45 -0800 (PST) Received: from seasnake.red.iplanet.com (seasnake.red.iplanet.com [192.18.124.85]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2KG4n900609; Tue, 20 Mar 2001 08:04:49 -0800 (PST) Received: from netscape.com (sera-nuq-205-217-228-72.mcom.com [205.217.228.72]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id IAA24177504; Tue, 20 Mar 2001 08:09:52 -0800 (PST) Message-ID: <3AB77F83.22ADEA46@netscape.com> Date: Tue, 20 Mar 2001 08:04:19 -0800 From: Steve Mansour X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , David Madeo , John Stracke , calsch WG , iptel@lists.bell-labs.com Subject: Re: Current thinking on CPL/iCalendar References: Content-Type: multipart/mixed; boundary="------------EA2407A238775198406E1D50" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------EA2407A238775198406E1D50 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > Patrik replied: > > Question: Is not the requirement for O(1) that the interval between > > events have to be longer than the length of the event itself? > > > > I.e. removing support for sub-24h recurrances seems too arbitrary if > > not really needed. > > It may be part of the IPTEL but its not part of CALSCH's requirements. I > dont see any rationale for this need so Im not sure _why_ it would exist. > > > >Our training dept schedules multiple instances of the "same" class > > >which sometimes overlap. I could easily be swayed by the argument > > >that there should be multiple "threads" on a per instructor basis, or > > >perhaps by room. Just pointing out one possibility. > > > > The need for non-overlapping events is the largest requirement for > > O(1) isn't it? > > Perhaps Im just not focused enough on O(1) but I do not see how restricting > to non-overlapping entries makes the performace faster. I can understand > restricting the use or values in, say, an RRULEs due to potentially heavy > roll times. I dont see how overlapping, explicit RDATEs violates or > prohibits O(1) so can someone please codify why? > > Similar example to Daves: > A theatre lists a movie once but it may have overlapping show times. but they will be in different locations. > It is > not that logical to have them PUBLISH movie times based on each individual > thatre; its more logical to just list all the showing times for a title. I don't know. It doesn't seems more logical to me if I was generating PUBLISH events. How would you list the LOCATIONs ? > A museum or company that conducts tours may have staggered schedules. > Instead of scheduling on a tour guide by tour guide basis, they are > scheduling on a tour by tour schedule. So in other words, the tour is 2 hours, there's two of them every day, they start at 10:00 and 10:30 ? This could be done with two separate recurring meetings as well. May not be as elegant, but then I can't envision the UI that would allow you to create such meetings as a single event. Seems like there is a reasonable workaround for the overlapping recurrences. A clarification stating that recurrence intervals must be greater than the duration of the event seems like it does a lot more good than harm. -Steve --------------EA2407A238775198406E1D50 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------EA2407A238775198406E1D50-- From owner-ietf-calendar@mail.imc.org Tue Mar 20 11:27:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12025 for ; Tue, 20 Mar 2001 11:27:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA00834 for ietf-calendar-bks; Tue, 20 Mar 2001 08:09:51 -0800 (PST) Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA00828 for ; Tue, 20 Mar 2001 08:09:47 -0800 (PST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA20380; Tue, 20 Mar 2001 11:12:38 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Mar 2001 11:11:18 -0500 Message-ID: From: Jonathan Rosenberg To: "'Bruce_Kahn@iris.com'" , =?iso-8859-1?Q?Patri?= =?iso-8859-1?Q?k_F=E4ltstr=F6m?= Cc: David Madeo , John Stracke , calsch WG , iptel@lists.bell-labs.com Subject: RE: Current thinking on CPL/iCalendar Date: Tue, 20 Mar 2001 11:11:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id IAA00831 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id IAA00834 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12025 > -----Original Message----- > From: Bruce_Kahn@iris.com [mailto:Bruce_Kahn@iris.com] > Sent: Tuesday, March 20, 2001 10:32 AM > To: Patrik Fältström > Cc: David Madeo; John Stracke; calsch WG; iptel@lists.bell-labs.com > Subject: Re: Current thinking on CPL/iCalendar > > > > Patrik replied: > > Question: Is not the requirement for O(1) that the interval between > > events have to be longer than the length of the event itself? > > > > I.e. removing support for sub-24h recurrances seems too arbitrary if > > not really needed. > > It may be part of the IPTEL but its not part of CALSCH's > requirements. I > dont see any rationale for this need so Im not sure _why_ it > would exist. > > > >Our training dept schedules multiple instances of the "same" class > > >which sometimes overlap. I could easily be swayed by the argument > > >that there should be multiple "threads" on a per > instructor basis, or > > >perhaps by room. Just pointing out one possibility. > > > > The need for non-overlapping events is the largest requirement for > > O(1) isn't it? > > Perhaps Im just not focused enough on O(1) but I do not see > how restricting > to non-overlapping entries makes the performace faster. I > can understand > restricting the use or values in, say, an RRULEs due to > potentially heavy > roll times. I dont see how overlapping, explicit RDATEs violates or > prohibits O(1) so can someone please codify why? > > Similar example to Daves: > A theatre lists a movie once but it may have overlapping show > times. It is > not that logical to have them PUBLISH movie times based on > each individual > thatre; its more logical to just list all the showing times > for a title. > A museum or company that conducts tours may have staggered schedules. > Instead of scheduling on a tour guide by tour guide basis, they are > scheduling on a tour by tour schedule. I'll let others comment on the computational implications of overlapping events. Another issue is problem space. For the CPL application, we are interested in mapping people's schedules to call processing rules, i.e., "don't call me when I'm in this meeting". For schedules for people, I don't see how there would ever be overlapping recurring instances. Even if there were, it seems we could handle this like we are handling COUNT, which is to expand them to N sets of non-overlapping recurrences. -Jonathan R. From owner-ietf-calendar@mail.imc.org Tue Mar 20 11:43:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12656 for ; Tue, 20 Mar 2001 11:43:54 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA02371 for ietf-calendar-bks; Tue, 20 Mar 2001 08:27:08 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02365 for ; Tue, 20 Mar 2001 08:27:06 -0800 (PST) From: ned.freed@mrochek.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01K1ETULRPTS00157Q@mauve.mrochek.com> for ietf-calendar@imc.org; Tue, 20 Mar 2001 08:27:07 -0800 (PST) Date: Tue, 20 Mar 2001 08:16:52 -0800 (PST) Subject: Re: Current thinking on CPL/iCalendar In-reply-to: "Your message dated Tue, 20 Mar 2001 09:41:57 -0600" To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: John Stracke , calsch WG , iptel@lists.bell-labs.com Message-id: <01K1EW040HFQ00157Q@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> <3AB77741.D9E3C548@ecal.com> <3AB77741.D9E3C548@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > > Question: Is not the requirement for O(1) that the interval between > > > events have to be longer than the length of the event itself? > > > I.e. removing support for sub-24h recurrances seems too arbitrary if > > > not really needed. > > We thought about that; but a straightforward limit like this is much easier to > > explain to a user, and incorporate in a UI. I don't agree. Part of explaining a limitation is justifying it. It may be a bit easier to say or imply in a UI that short recurrances aren't allowed, but it is pretty hard to justify. Whereas prohibiting overlap may manifest in a more obvious way but seems a lot more natural. > ...but it means that you can never have recurrance rules which handle > the "medication problem"...or a recurrance rule which tells when the > busses are leaving for a social event (starting 17:00, every 15 > minutes, 5 times). ... or when the tour starts every 15 minutes. ... or when the presentation at the trade show begins 5 minutes after the hour, every hour. ... or when the film loop restarts every hour on the hour. Heck, they make single-hand standup clocks specifically to show this sort of stuff. It is a _common_ schedule for things to have. > You are the ones making the decision, but I think you should think > very hard wether you want this kind of limitation (a fixed limit) > when the overlap is the most important thing, and the problem you try > to solve. I agree. Ned From owner-ietf-calendar@mail.imc.org Tue Mar 20 11:45:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12730 for ; Tue, 20 Mar 2001 11:45:46 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA02907 for ietf-calendar-bks; Tue, 20 Mar 2001 08:33:36 -0800 (PST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02902 for ; Tue, 20 Mar 2001 08:33:35 -0800 (PST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA12738; Tue, 20 Mar 2001 11:33:36 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA18066; Tue, 20 Mar 2001 11:33:35 -0500 (EST) Message-ID: <3AB7B18C.56C0D4CC@cs.columbia.edu> Date: Tue, 20 Mar 2001 11:37:48 -0800 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: John Stracke , calsch WG , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Re: Current thinking on CPL/iCalendar References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> <3AB77741.D9E3C548@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > You are the ones making the decision, but I think you should think > very hard wether you want this kind of limitation (a fixed limit) > when the overlap is the most important thing, and the problem you try > to solve. > > An application can still prohibit the user from entering whatever if > it wants to... I don't think the latter option is viable. If application A allows it, but application B doesn't, then shipping CPL or calsch elements from A to B is going to be very confusing to the user. How would the B user change the interval from 4 to 5 hours? As I said before, the O(1) requirement can be relaxed somewhat if reasonable expansion or translation is possible when the CPL arrives at the server. The question is whether any existing UI support these corner-cases. From owner-ietf-calendar@mail.imc.org Tue Mar 20 11:57:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13255 for ; Tue, 20 Mar 2001 11:57:11 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA03980 for ietf-calendar-bks; Tue, 20 Mar 2001 08:45:04 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA03974 for ; Tue, 20 Mar 2001 08:45:03 -0800 (PST) From: ned.freed@mrochek.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01K1ETULRPTS00157Q@mauve.mrochek.com> for ietf-calendar@imc.org; Tue, 20 Mar 2001 08:45:03 -0800 (PST) Date: Tue, 20 Mar 2001 08:43:17 -0800 (PST) Subject: Re: [IPTEL] Re: Current thinking on CPL/iCalendar In-reply-to: "Your message dated Tue, 20 Mar 2001 11:37:48 -0800" <3AB7B18C.56C0D4CC@cs.columbia.edu> To: Henning Schulzrinne Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , John Stracke , calsch WG , iptel@lists.bell-labs.com Message-id: <01K1EWMD2T5Q00157Q@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <3AB6D6D4.7AF17EFE@ecal.com> <3AB754BA.880F293C@msdw.com> <3AB77741.D9E3C548@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > > > You are the ones making the decision, but I think you should think > > very hard wether you want this kind of limitation (a fixed limit) > > when the overlap is the most important thing, and the problem you try > > to solve. > > > > An application can still prohibit the user from entering whatever if > > it wants to... > I don't think the latter option is viable. If application A allows it, > but application B doesn't, then shipping CPL or calsch elements from A > to B is going to be very confusing to the user. How would the B user > change the interval from 4 to 5 hours? There's always a problem if we impose a requirement on what's allowed in the protocol and some implementations don't conform to it. I see little difference between the problems that arise when an implementation fails to prohibit overlaps and the problems that arise when an implementation fails to respect a minimum-time-between-occurances restriction. Ned From owner-ietf-calendar@mail.imc.org Tue Mar 20 13:08:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16413 for ; Tue, 20 Mar 2001 13:08:53 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id JAA06164 for ietf-calendar-bks; Tue, 20 Mar 2001 09:56:23 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA06159 for ; Tue, 20 Mar 2001 09:56:21 -0800 (PST) Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA13621; Tue, 20 Mar 2001 12:55:21 -0500 Received: from c-1192.steltor.com (host1.vpn.cst.ca [192.168.6.1]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HJ8MHV0T; Tue, 20 Mar 2001 12:53:52 -0500 Message-Id: <5.0.0.25.0.20010320103722.00a77020@apollo.cst.ca> X-Sender: aland@apollo.cst.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 20 Mar 2001 11:57:35 -0600 To: lennox@cs.columbia.edu From: Alan Davies Subject: Re: Current thinking on CPL/iCalendar Cc: schulzrinne@cs.columbia.edu, ietf-calendar@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been having a think about alternative ways of solving the problem, and it seems that there should be a way to find if a time matches a given rule in constant time without any restrictions on the duration or recurrence interval (I haven't looked into COUNT or BYSETPOS- it seems too obvious that you're right on those). The algorithm that you proposed in the CPL draft relied on certain restrictions to ensure that it could complete in constant time. We had a look at trying to apply some simple set theory to the problem, and it seemed that it should be solvable, so I bashed out some simple formulas, which are given below. In an RRULE, there are a bunch of parameters that are easy to check for- BYWEEKNO, BYYEARDAY, etc.- we can ignore those as they're not causing any problems. The question comes with the FREQ, INTERVAL, and DURATION. However, if this were written as an equation or inequality, these would all be constants, only the instance number would vary. It seems that the problem we're trying to solve then is this: Does an integer value of n exist such that both k * n >= target date and k * n + d < target date are true? (k is a constant representing the interval and frequency, start date has been factored out, d is a constant representing duration) Dividing target by k and flooring to the nearest whole number gives us a candidate value of n. This can be then run through the above inequalities. If this candidate matches, then an earlier value of n MAY also match (i.e. if d is greater than k), but if this candidate doesn't match, then no value of n will. Is this a gross oversimplification? --Alan From owner-ietf-calendar@mail.imc.org Tue Mar 20 13:22:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17057 for ; Tue, 20 Mar 2001 13:22:38 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA07227 for ietf-calendar-bks; Tue, 20 Mar 2001 10:11:26 -0800 (PST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA07222 for ; Tue, 20 Mar 2001 10:11:24 -0800 (PST) Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA21391; Tue, 20 Mar 2001 13:11:24 -0500 (EST) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id NAA72828; Tue, 20 Mar 2001 13:11:24 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15031.40268.310931.789352@conrail.cs.columbia.edu> Date: Tue, 20 Mar 2001 13:11:24 -0500 (EST) To: calsch WG , iptel@lists.bell-labs.com Subject: Re: Current thinking on CPL/iCalendar In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 19.34.1 X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA07224 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id KAA07227 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17057 On Tuesday, March 20 2001, "Bruce_Kahn@iris.com" wrote to "Patrik Fältström, David Madeo, John Stracke, calsch WG, iptel@lists.bell-labs.com" saying: > Perhaps Im just not focused enough on O(1) but I do not see how restricting > to non-overlapping entries makes the performace faster. I can understand > restricting the use or values in, say, an RRULEs due to potentially heavy > roll times. I dont see how overlapping, explicit RDATEs violates or > prohibits O(1) so can someone please codify why? They don't. The prohibition is on overlapping recurrences within an RRULE, not on overlapping recurrences within an entire RECUR. (For IPTel folks: this means "the prohibition is on overlapping recurrences within a