From owner-ietf-calendar@mail.imc.org Wed Nov 1 15:10:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14052 for ; Wed, 1 Nov 2000 15:10:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06503 for ietf-calendar-bks; Wed, 1 Nov 2000 11:40:35 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06498 for ; Wed, 1 Nov 2000 11:40:33 -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 OAA21023; Wed, 1 Nov 2000 14:45:52 -0500 Received: from steltor.com (cc-1106.int.cst.ca [192.168.1.105]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V8ZJLNQG; Wed, 1 Nov 2000 14:46:15 -0500 Message-ID: <3A0072AC.FE97E42B@steltor.com> Date: Wed, 01 Nov 2000 14:44:44 -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: iTIP updates References: <39FEF681.1F12E87B@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: > > Hi All, > > Here are the list of iTIP updates. Somebody made a suggestion for #2 (I think it was George Babics) about an additional use for the ATTCOUNTER parameter -- there was some other situation where we needed to determine who was doing an action -- I think it had to do with delegation. But I didn't add it to this list. Whoever it was please reply so we can review it and put it in if it makes sense. No it was not me. (Or, if it was me, I forgot :)). George From owner-ietf-calendar@mail.imc.org Wed Nov 1 21:26:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11573 for ; Wed, 1 Nov 2000 21:26:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA16335 for ietf-calendar-bks; Wed, 1 Nov 2000 18:04:04 -0800 (PST) Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16331 for ; Wed, 1 Nov 2000 18:04:02 -0800 (PST) Received: from modem-116.high-hat.dialup.pol.co.uk ([62.137.27.116] helo=helixcode.com) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13r9pf-0007qp-00; Thu, 02 Nov 2000 02:10:23 +0000 Message-ID: <3A00883B.9EFAFDB9@helixcode.com> Date: Wed, 01 Nov 2000 21:16:43 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: Federico Mena Quintero Subject: Recurrence UNTIL/RDATE/EXDATE properties with DATE values 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 I'm a bit unsure of the semantics of UNTIL/RDATE/EXDATE recurrence properties that have DATE values (as opposed to DATE-TIME values). If only a DATE is given, do you just assume that the time is 00:00:00, or do you do something more. For example - If an UNTIL property has a DATE value does it mean: a) until 12 am on that date (i.e. you just assume 00:00:00). b) until the last occurrence on that date (i.e. you take it as 23:59:59). If an RDATE property has a DATE value does it mean: a) an occurrence on 12 am on that date. b) an occurrence at the same time as the initial occurrence, but on the given date. If an EXDATE property has a DATE value does it mean: a) exclude any occurrence at 12 am on that date. b) exclude all occurrences on that date. I think all the (a) answers are more intuitive but I don't think the iCalendar spec is specific about these. Damon From owner-ietf-calendar@mail.imc.org Thu Nov 2 10:12:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18412 for ; Thu, 2 Nov 2000 10:12:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14701 for ietf-calendar-bks; Thu, 2 Nov 2000 06:45:41 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14692 for ; Thu, 2 Nov 2000 06:45:39 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eA2EtPi12136 for ; Thu, 2 Nov 2000 09:55:25 -0500 Message-ID: <3A017414.6868800B@ecal.com> Date: Thu, 02 Nov 2000 09:03: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: Recurrence UNTIL/RDATE/EXDATE properties with DATE values References: <3A00883B.9EFAFDB9@helixcode.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: > I'm a bit unsure of the semantics of UNTIL/RDATE/EXDATE recurrence > properties that have DATE values (as opposed to DATE-TIME values). I would suggest that we might want to just ban DATE values, to reduce ambiguity; in all the cases Damon gives, whether you pick (a) or (b), you can get the same effect with DATE-TIME values. Does anybody remember the motivation for permitting DATE values in the first place? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |How many roads must a man walk down before he| |francis@ecal.com|admits he is LOST? | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 2 10:18:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20712 for ; Thu, 2 Nov 2000 10:18:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14702 for ietf-calendar-bks; Thu, 2 Nov 2000 06:45:41 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14693 for ; Thu, 2 Nov 2000 06:45:40 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eA2EtQi12144 for ; Thu, 2 Nov 2000 09:55:26 -0500 Message-ID: <3A01767C.2B172A25@ecal.com> Date: Thu, 02 Nov 2000 09:13:16 -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: CalSched IETF Subject: Re: iTIP updates References: <39FEF681.1F12E87B@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: > 3. Adding/deleting ATTENDEEs > > Problem: If the Organizer adds or deletes an > ATTENDEE, do they really have to send the reschedule > to all of the other ATTENDEEs? The iTIP specification > is not clear on this point. > > Proposal: No, the Organizer can send the REQUEST > w/the new ATTENDEE info to just the new ATTENDEE. It > is up to the CUA. > I think we should specify that the Organizer SHOULD send the REQUEST to all ATTENDEEs, but let the user override. When we discussed this before, I was swayed by the argument that you might be inviting someone who doesn't want everyone to know he'll be there; but I think that's the exception. Most of the time, you should let all the ATTENDEEs know who's going to be there, because it might influence their decision on whether to attend. ("I'm not going to the party if Joe Rude is going to be there." "Fred and I don't both need to go to the meeting.") In other words, the ATTENDEE list is part of the description of the event, and we should try to transmit it as accurately as possible. > It is an implementation dependent issue if the > SEQUENCE number needs to be incremented when you > add/delete an ATTENDEE. iCalendar does not require an > updated SEQUENCE number if a new ATTENDEE is added so > this won't break iCalendar as it stands today. > I think, if the ATTENDEE list is considered part of the information that we're distributing, a change to the list should imply a change to the SEQUENCE number. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Where's your sense of adventure?" "In front of| |francis@ecal.com|a roaring fire with a cup of cocoa." | \================================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 2 11:17:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06883 for ; Thu, 2 Nov 2000 11:17:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA22566 for ietf-calendar-bks; Thu, 2 Nov 2000 07:52:40 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22551 for ; Thu, 2 Nov 2000 07:52:06 -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 eA2FoZD23813 for ; Thu, 2 Nov 2000 07:50:35 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G3EN0J00.J6Y; Thu, 2 Nov 2000 07:57:55 -0800 Message-ID: <3A018EFD.28C485A9@netscape.com> Date: Thu, 02 Nov 2000 07:57:49 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: CalSched IETF Subject: Re: iTIP updates References: <39FEF681.1F12E87B@netscape.com> <3A01767C.2B172A25@ecal.com> Content-Type: multipart/mixed; boundary="------------E68CEA7FBDCB79A8B2F07FF5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E68CEA7FBDCB79A8B2F07FF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > Steve Mansour wrote: > > > 3. Adding/deleting ATTENDEEs > > > > Problem: If the Organizer adds or deletes an > > ATTENDEE, do they really have to send the reschedule > > to all of the other ATTENDEEs? The iTIP specification > > is not clear on this point. > > > > Proposal: No, the Organizer can send the REQUEST > > w/the new ATTENDEE info to just the new ATTENDEE. It > > is up to the CUA. > > > I think we should specify that the Organizer SHOULD send the > REQUEST to all ATTENDEEs, but let the user override. When we > discussed this before, I was swayed by the argument that you > might be inviting someone who doesn't want everyone to know he'll > be there; but I think that's the exception. Most of the time, > you should let all the ATTENDEEs know who's going to be there, > because it might influence their decision on whether to attend. > ("I'm not going to the party if Joe Rude is going to be there." > "Fred and I don't both need to go to the meeting.") In other > words, the ATTENDEE list is part of the description of the event, > and we should try to transmit it as accurately as possible. Any objections to this? > > It is an implementation dependent issue if the > > SEQUENCE number needs to be incremented when you > > add/delete an ATTENDEE. iCalendar does not require an > > updated SEQUENCE number if a new ATTENDEE is added so > > this won't break iCalendar as it stands today. > > > I think, if the ATTENDEE list is considered part of the > information that we're distributing, a change to the list should > imply a change to the SEQUENCE number. I'm starting to think the same thing. We actually came up with a few circumstances where odd things could happen in our iTIP implementation if we don't bump the sequence number. iCalendar does not require this, but we could say that a conformant iTIP implementation needs to support it. Any objections to this? --------------E68CEA7FBDCB79A8B2F07FF5 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:650-937-2103 tel;work:650-937-2378 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 --------------E68CEA7FBDCB79A8B2F07FF5-- From owner-ietf-calendar@mail.imc.org Thu Nov 2 11:35:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11607 for ; Thu, 2 Nov 2000 11:35:50 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23050 for ietf-calendar-bks; Thu, 2 Nov 2000 08:08:46 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23046 for ; Thu, 2 Nov 2000 08:08:45 -0800 (PST) From: Bruce_Kahn@iris.com To: John Stracke Cc: "ietf-calendar@imc.org" Subject: Re: Recurrence UNTIL/RDATE/EXDATE properties with DATE values X-Mailer: Lotus Notes Build V60_10292000 October 29, 2000 Message-ID: Date: Thu, 2 Nov 2000 11:15:00 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/02/2000 11:15:11 AM, Serialize complete at 11/02/2000 11:15:12 AM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/02/2000 11:15:12 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005974E28525698B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005974E28525698B_= Content-Type: text/plain; charset="us-ascii" John asked: >Does anybody remember the motivation for permitting DATE values in the first place? Sure, for all day events like Bastille Day (Hi Franks favorite), New Years Day, etc. Another use is to block out (in the case of EXDATES) _all_ instances of a repeat set that occur on a particular day. For example, a movie shows ~4-6 times a day but the theatre will be closed on New Years Day so they want to exclude ALL instances on that date. Also, dont forget that we declared (somewhere, honest!) that times are inherited from the DTSTART/DTEND (or DURATION) if none are specfied on the RDATE, EXDATE (and probably implied on the UNTIL too but Im not sure). 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 005974E28525698B_= Content-Type: text/html; charset="us-ascii"
John asked:
>Does anybody remember the motivation for permitting DATE values in the first place?

Sure, for all day events like Bastille Day (Hi Franks favorite), New Years Day, etc.  

Another use is to block out (in the case of EXDATES) _all_ instances of a repeat set that occur on a particular day.  For example, a movie shows ~4-6 times a day but the theatre will be closed on New Years Day so they want to exclude ALL instances on that date.

Also, dont forget that we declared (somewhere, honest!) that times are inherited from the DTSTART/DTEND (or DURATION) if none are specfied on the RDATE, EXDATE (and probably implied on the UNTIL too but Im not sure).

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 005974E28525698B_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 2 12:26:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25430 for ; Thu, 2 Nov 2000 12:26:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27587 for ietf-calendar-bks; Thu, 2 Nov 2000 09:00:47 -0800 (PST) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27578 for ; Thu, 2 Nov 2000 09:00:44 -0800 (PST) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: Automated action list X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 2 Nov 2000 17:06:58 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/02/2000 12:07:09 PM, Serialize complete at 11/02/2000 12:07:09 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0042A5BC8025698B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0042A5BC8025698B_= Content-Type: text/plain; charset="us-ascii" The automated action list that comes from Doug Royer is currently out of date. Mr. Royer is unavailable at the current time and we have no way to "turn off" his automated list. Until such time as that list becomes current again, please ignore the updates. I will be sending out a list weekly that is current and up to date, especially with the December meeting coming up soon. We will be posting new drafts in order to get them on the "docket" so keep the comments coming. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0042A5BC8025698B_= Content-Type: text/html; charset="us-ascii"
The automated action list that comes from Doug Royer is currently out of date.  Mr. Royer is unavailable at the current time and we have no way to "turn off" his automated list.  Until such time as that list becomes current again, please ignore the updates.  I will be sending out a list weekly that is current and up to date, especially with the December meeting coming up soon.  We will be posting new drafts in order to get them on the "docket" so keep the comments coming.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0042A5BC8025698B_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 2 13:53:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16505 for ; Thu, 2 Nov 2000 13:53:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02920 for ietf-calendar-bks; Thu, 2 Nov 2000 10:31:20 -0800 (PST) Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02914 for ; Thu, 2 Nov 2000 10:31:19 -0800 (PST) Received: from modem-85.oklahoma.dialup.pol.co.uk ([62.137.87.85] helo=helixcode.com) by mail1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13rPF9-00029q-00; Thu, 02 Nov 2000 18:37:44 +0000 Message-ID: <3A01B482.2BE1C95D@helixcode.com> Date: Thu, 02 Nov 2000 18:37:54 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , Federico Mena Quintero Subject: Re: Recurrence UNTIL/RDATE/EXDATE properties with DATE values References: <3A00883B.9EFAFDB9@helixcode.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: > I think all the (a) answers are more intuitive but I don't think the iCalendar > spec is specific about these. Oops. I meant (b) there. Damon From owner-ietf-calendar@mail.imc.org Sat Nov 4 23:43:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19490 for ; Sat, 4 Nov 2000 23:43:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA08667 for ietf-calendar-bks; Sat, 4 Nov 2000 20:21:41 -0800 (PST) Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08663 for ; Sat, 4 Nov 2000 20:21:40 -0800 (PST) Received: from imc.org ([216.209.82.195]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001105042747.FZUB20301.tomts7-srv.bellnexxia.net@imc.org> for ; Sat, 4 Nov 2000 23:27:47 -0500 MIME-Version: 1.0 From: Mary@ns.secondary.com REPLY-TO: group3us@yahoo.com To: ietf-calendar@imc.org Subject: Ebay4Sex Gets Laid!!!!! Content-Type: multipart/mixed; boundary=Uniqque-Boundary Message-Id: <20001105042747.FZUB20301.tomts7-srv.bellnexxia.net@imc.org> Date: Sat, 4 Nov 2000 23:27:48 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [ Random garbage here ] --Uniqque-Boundary Content-type: text/html; charset=US-ASCII Brought to you by

 

 

Brought to you by;
EVERYTHINGAMATEUR.COM

 

for advertising information
webmaster@everythingamateur.com

--Uniqque-Boundary-- From owner-ietf-calendar@mail.imc.org Sun Nov 5 00:09:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA19491 for ; Sat, 4 Nov 2000 23:43:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA08720 for ietf-calendar-bks; Sat, 4 Nov 2000 20:23:02 -0800 (PST) Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08715 for ; Sat, 4 Nov 2000 20:23:01 -0800 (PST) Received: from imc.org ([216.209.82.195]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001105042908.VAXE10530.tomts6-srv.bellnexxia.net@imc.org> for ; Sat, 4 Nov 2000 23:29:08 -0500 MIME-Version: 1.0 From: Mary@ns.secondary.com REPLY-TO: group3us@yahoo.com To: ietf-calendar@imc.org Subject: Ebay4Sex Gets Laid!!!!! Content-Type: multipart/mixed; boundary=Uniqque-Boundary Message-Id: <20001105042908.VAXE10530.tomts6-srv.bellnexxia.net@imc.org> Date: Sat, 4 Nov 2000 23:29:09 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [ Random garbage here ] --Uniqque-Boundary Content-type: text/html; charset=US-ASCII Brought to you by

 

 

Brought to you by;
EVERYTHINGAMATEUR.COM

 

for advertising information
webmaster@everythingamateur.com

--Uniqque-Boundary-- From owner-ietf-calendar@mail.imc.org Sun Nov 5 03:28:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05362 for ; Sun, 5 Nov 2000 03:28:08 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA25750 for ietf-calendar-bks; Sat, 4 Nov 2000 23:53:40 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA25741 for ; Sat, 4 Nov 2000 23:53:38 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA13670 for ietf-calendar@imc.org; Sun, 5 Nov 2000 00:00:05 -0800 (PST) Date: Sun, 5 Nov 2000 00:00:05 -0800 (PST) From: Doug Royer Message-Id: <200011050800.AAA13670@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 Nov 6 11:13:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08157 for ; Mon, 6 Nov 2000 11:13:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA13308 for ietf-calendar-bks; Mon, 6 Nov 2000 07:43:22 -0800 (PST) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13303 for ; Mon, 6 Nov 2000 07:43:20 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eA6Fr0o31869 for ; Mon, 6 Nov 2000 10:53:00 -0500 Message-ID: <3A06D3DC.43CF9698@ecal.com> Date: Mon, 06 Nov 2000 10:53: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: Recurrence UNTIL/RDATE/EXDATE properties with DATE values 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: > John asked: > >Does anybody remember the motivation for permitting DATE > values in the first place? > > Sure, for all day events like Bastille Day (Hi Franks > favorite), New Years Day, etc. OK, in this case, *all* the values involved will be DATEs; there will be no DATE-TIMEs at all. > Another use is to block out (in the case of EXDATES) _all_ > instances of a repeat set that occur on a particular day. For > example, a movie shows ~4-6 times a day but the theatre will be > closed on New Years Day so they want to exclude ALL instances > on that date. > > Also, dont forget that we declared (somewhere, honest!) that > times are inherited from the DTSTART/DTEND (or DURATION) if > none are specfied on the RDATE, EXDATE (and probably implied on > the UNTIL too but Im not sure). These two statements are inconsistent. An EXDATE with no time can't *both* default to the same time as DTSTART *and* be a wildcard. In addition, both of them are superfluous. The wildcard case can be expressed with multiple EXDATEs with DATE-TIME values; the default case can be expressed by specifying the EXDATE as a DATE-TIME. So permitting DATE values for EXDATE does not add functionality, and does add ambiguity. I suggest that we mandate that all the various date[-time] values in a given recurrence rule be the same type: either they're all DATEs (for all-day events), or they're all DATE-TIMEs. Combining the two is just too confusing. -- /================================================================\ |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 Mon Nov 6 11:14:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08253 for ; Mon, 6 Nov 2000 11:14:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA13360 for ietf-calendar-bks; Mon, 6 Nov 2000 07:44:56 -0800 (PST) Received: from localhost.localdomain (thibault.org [207.8.144.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13354 for ; Mon, 6 Nov 2000 07:44:55 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eA6Fsao31888 for ; Mon, 6 Nov 2000 10:54:36 -0500 Message-ID: <3A06D43B.DB15838F@ecal.com> Date: Mon, 06 Nov 2000 10:54:35 -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: Automated action list 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: > The automated action list that comes from Doug Royer is > currently out of date. Mr. Royer is unavailable at the current > time and we have no way to "turn off" his automated list. Can it be blocked by the mailing list? -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |The Player's Litany: The Wind is the Storm, and| |francis@ecal.com|the Storm is Data, and the Data is Life. | | |--Daniel Keys Moran | \================================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 6 16:59:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15496 for ; Mon, 6 Nov 2000 16:59:21 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA01444 for ietf-calendar-bks; Mon, 6 Nov 2000 13:23:52 -0800 (PST) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01437 for ; Mon, 6 Nov 2000 13:23:50 -0800 (PST) From: pregen@egenconsulting.com To: John Stracke Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Automated action list X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 6 Nov 2000 21:30:31 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/06/2000 04:30:35 PM, Serialize complete at 11/06/2000 04:30:35 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005ACA228025698F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005ACA228025698F_= Content-Type: text/plain; charset="us-ascii" Not sure. Good Idea. I'll check with the IMC.org group. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 John Stracke Sent by: owner-ietf-calendar@mail.imc.org 11/06/00 03:54 PM To: ietf-calendar@imc.org cc: Subject: Re: Automated action list pregen@egenconsulting.com wrote: > The automated action list that comes from Doug Royer is > currently out of date. Mr. Royer is unavailable at the current > time and we have no way to "turn off" his automated list. Can it be blocked by the mailing list? -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |The Player's Litany: The Wind is the Storm, and| |francis@ecal.com|the Storm is Data, and the Data is Life. | | |--Daniel Keys Moran | \================================================================/ --=_alternative 005ACA228025698F_= Content-Type: text/html; charset="us-ascii"
Not sure.  Good Idea. I'll check with the IMC.org group.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


John Stracke <francis@ecal.com>
Sent by: owner-ietf-calendar@mail.imc.org

11/06/00 03:54 PM

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: Automated action list



pregen@egenconsulting.com wrote:

> The automated action list that comes from Doug Royer is
> currently out of date.  Mr. Royer is unavailable at the current
> time and we have no way to "turn off" his automated list.

Can it be blocked by the mailing list?

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |The Player's Litany: The Wind is the Storm, and|
|francis@ecal.com|the Storm is Data, and the Data is Life.       |
|                |--Daniel Keys Moran                            |
\================================================================/

--=_alternative 005ACA228025698F_=-- From owner-ietf-calendar@mail.imc.org Sun Nov 12 03:31:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07101 for ; Sun, 12 Nov 2000 03:31:23 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA23315 for ietf-calendar-bks; Sat, 11 Nov 2000 23:53:06 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23306 for ; Sat, 11 Nov 2000 23:53:04 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA20481 for ietf-calendar@imc.org; Sun, 12 Nov 2000 00:00:03 -0800 (PST) Date: Sun, 12 Nov 2000 00:00:03 -0800 (PST) From: Doug Royer Message-Id: <200011120800.AAA20481@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 Nov 12 15:01:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22495 for ; Sun, 12 Nov 2000 15:01:16 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA18152 for ietf-calendar-bks; Sun, 12 Nov 2000 11:32:11 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18141 for ; Sun, 12 Nov 2000 11:32:06 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id C826FB34FA; Sun, 12 Nov 2000 20:39:14 +0100 (CET) From: "Greg FitzPatrick" To: "Greg FitzPatrick" , Cc: "Ietf" Subject: SV: SKiCal & Roles Date: Sun, 12 Nov 2000 20:39:20 +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 At a recent SKiCal meeting we went through the comments that were brought forth by our last call to this list. We were in agreement that the only reason for adding three additional property parameters was to avoid conflict with 2445. Bruce who brought this to our attention had written: Bruce Kahn: Ok, I revisited SKiCal draft for another pass or two. One quick thing that popped out was the addition of "DIPROLE", "DITROLE" and "DITHROLE" to the current "ROLE" property parameter. I'm more than a bit curious why these new property parameters are necessary instead of just reusing "ROLE" on the new properties and adding new values. We already have some precedence for that in RFC 2445. In section 4.2.12 Participation Status we defined the allowed values for PARTSTAT for each component type (ie: the vEvent list is different from the vToDos, etc). To which we replied: Our philosophy has always been not to bend the properties and parameters of RFC2445 out of their intended uses and end up creating ambiguity. Nor have we felt that it was a good idea to try to change 2445 merely to accommodate SKiCal, though we did make some suggestions to that effect originally. In this particular case we would have to for starters change 4.2.16 Participation Role, since the properties concerned are not necessarily of a CAL-ADDRESS value type. And we would have to do something about the default value of the property being "REQ-PARTICIPANT" see below "4.2.16 Participation Role - Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter specifies the participation role for the calendar user specified by the property in the group schedule calendar component. If not specified on a property that allows this parameter, the default value is REQ-PARTICIPANT." Though I agree that simplified term "ROLE" would suffice in denoting the role of a person, thing or theme in an event if it was coupled to the respective properties of PERSONS, THINGS, and THINKS, it is quite a stretch on the original intention for "ROLE" in 2445. ... shortly afterwards a typo was discovered by Marin Neimeier in 2445 Chapter 5 iCalendar Object Examples (on Page 136) ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com Which sort of highlights the fact that ROLE is quite constrained as to its intended use. So for one last time I would like to hear everyone's opinion - should we create these three new property parameters or reuse ROLE as it was not intended to be used? From owner-ietf-calendar@mail.imc.org Tue Nov 14 12:44:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29520 for ; Tue, 14 Nov 2000 12:44:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA07363 for ietf-calendar-bks; Tue, 14 Nov 2000 09:06:50 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07353 for ; Tue, 14 Nov 2000 09:06:46 -0800 (PST) From: Bruce_Kahn@iris.com To: Martin Neimeier Cc: IETF-Calendar-Mailinglist Subject: Re: VALARMs and VEVENTs ? X-Mailer: Lotus Notes Build V60_11022000 November 02, 2000 Message-ID: Date: Tue, 14 Nov 2000 12:13:50 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/14/2000 12:14:13 PM, Serialize complete at 11/14/2000 12:14:13 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005EE18E85256997_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005EE18E85256997_= Content-Type: text/plain; charset="us-ascii" It seems this got lost in the chatter lately... Martin asked: >is it possible to specify a relative-VALARM for a VEVENT which has a DTSTART-property of VALUE=DATE? >If yes, what time should be used ? I do not see any reason why not. A VALUE=DATE has an implicit floating time of 000000 local to the recipient. (That is, New Years Day starts at 12:00 AM in your TZ, NOT when its 12:00 AM in the the UK) so the implicit reference time to be used is 000000 (or 12:00 AM local to the recipient) >Whats the trigger-time for the above sample ? >Is it 20001211T1900Z ? Nope, the trigger time is 20001211T190000. No Z, its relative. 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 005EE18E85256997_= Content-Type: text/html; charset="us-ascii"
It seems this got lost in the chatter lately...

Martin asked:
>is it possible to specify a relative-VALARM for a VEVENT which has a DTSTART-property of VALUE=DATE?
>If yes, what time should be used ?

I do not see any reason why not.  A VALUE=DATE has an implicit floating time of 000000 local to the recipient.  (That is, New Years Day starts at 12:00 AM in your TZ, NOT when its 12:00 AM in the the UK) so the implicit reference time to be used is 000000 (or 12:00 AM local to the recipient)

>Whats the trigger-time for the above sample ?
>Is it 20001211T1900Z ?

Nope, the trigger time is 20001211T190000.  No Z, its relative.

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 005EE18E85256997_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 14 14:55:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11424 for ; Tue, 14 Nov 2000 14:55:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA14468 for ietf-calendar-bks; Tue, 14 Nov 2000 11:28:05 -0800 (PST) Received: from star-cycle.star-cycle.com (www.star-cycle.com [210.227.70.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14455; Tue, 14 Nov 2000 11:27:59 -0800 (PST) From: mp3segaplayer@yahoo.com Received: from 1Cust105.tnt3.corpus-christi3.tx.da.uu.net_[63.30.30.105] (1Cust105.tnt3.corpus-christi3.tx.da.uu.net [63.30.30.105]) by star-cycle.star-cycle.com (8.8.8/3.7W-star-cycle) with SMTP id EAA13043; Wed, 15 Nov 2000 04:17:39 +0900 (JST) Received: from by 1Cust105.tnt3.corpus-christi3.tx.da.uu.net with ESMTP; Tue, 14 Nov 2000 12:16:34 -0500 Message-ID: <000068094a3f$0000176f$00007ccb@> To: Subject: DVD-MP3 Sega Player...FREE Star Wars Movie Date: Tue, 14 Nov 2000 12:16:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 1 X-MSMail-Priority: High Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id LAA14468 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA11424 The 8050+ DVD PLAYER!!! PLAYS ALL DVDS, Mp3's and VCDS.......ALLOWS COPYING OF DVDS!! For more info or to place an order call: 1-800-659-1991 Special Offer Code: 300, without this code your order can't be processed. (Toll Free in U.S. Outside of U.S. receive $5.00 phone credit off order price)   Did you know that with 6 different types of DVD disks on the market, not all players can play all DVDs?? That's right...The low end DVD models in most stores can't play all DVD movies!! Now, not available in U.S. stores , get a Region Free DVD Player capable off playing all types of DVDs!! Compare at thousands of dollars!! The 8050+ DVD,CD MP3 Player ..... REGION FREE ...Play DVDS from all over the world. The 8050+ DVD,CD MP 3 Player . Comparable to the $1500 DVD players found in Europe and Asia. Your Price: ONLY $249.95 From owner-ietf-calendar@mail.imc.org Tue Nov 14 20:49:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08008 for ; Tue, 14 Nov 2000 20:49:35 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA22947 for ietf-calendar-bks; Tue, 14 Nov 2000 17:07:12 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22943 for ; Tue, 14 Nov 2000 17:07:09 -0800 (PST) From: Bruce_Kahn@iris.com To: "Greg FitzPatrick" Cc: "Ietf" Subject: Re: SV: SKiCal & Roles X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Tue, 14 Nov 2000 20:14:28 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/14/2000 08:18:51 PM, Serialize complete at 11/14/2000 08:18:51 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000707B585256998_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000707B585256998_= Content-Type: text/plain; charset="us-ascii" Greg wrote: >Our philosophy has always been not to bend the properties and parameters of >RFC2445 out of their intended uses and end up creating ambiguity. Nor have >we felt that it was a good idea to try to change 2445 merely to accommodate >SKiCal, though we did make some suggestions to that effect originally. Adding new values is not necessarily creating ambiguity. We designed the ABNF so that extensions are easily done (as long as they do not directly conflict w/prior work). Hence my original suggestion/question. >In this particular case we would have to for starters change >4.2.16 Participation Role, since the properties concerned are not >necessarily >of a CAL-ADDRESS value type. And we would have to do something about the >default value of the property being "REQ-PARTICIPANT" The former part may be an issue but it is NOT one that affects the reuse of ROLE property parameter; its an issue w/the data type of the ATTENDEE property. Its not clear to me _why_ the default value is a real issue since any given value supercedes the default one... >Though I agree that simplified term "ROLE" would suffice in denoting the >role of a person, thing or theme in an event if it was coupled to the >respective properties of PERSONS, THINGS, and THINKS, it is quite a stretch >on the original intention for "ROLE" in 2445. The original definition was based on the collective views of the roles used in "Interpersonal C&S". SKiCal is a different critter but it still needs to convey the same basic intent that the original ROLE was designed for. There is a reason we defined the ABNF with: roleparam = "ROLE" "=" [Snip, snip] / x-name ; Experimental role / iana-token) ; Other IANA role (so that oversights or additions can easily be done...) >So for one last time I would like to hear everyone's opinion - should we >create these three new property parameters or reuse ROLE as it was not >intended to be used? Ill go back to the KISS mantra and vote for a reuse. After all the intent is the same, why make parsers / clients do more work than necessary. 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 000707B585256998_= Content-Type: text/html; charset="us-ascii"
Greg wrote:
>Our philosophy has always been not to bend the properties and parameters of
>RFC2445 out of their intended uses and end up creating ambiguity.  Nor have
>we felt that it was a good idea to try to change 2445 merely to accommodate
>SKiCal, though we did make some suggestions to that effect originally.

Adding new values is not necessarily creating ambiguity.  We designed the ABNF so that extensions are easily done (as long as they do not directly conflict w/prior work).  Hence my original suggestion/question.

>In this particular case we would have to for starters change
>4.2.16 Participation Role, since the properties concerned are not
>necessarily
>of a CAL-ADDRESS value type.  And we would have to do something about the
>default value of the property being "REQ-PARTICIPANT"

The former part may be an issue but it is NOT one that affects the reuse of ROLE property parameter; its an issue w/the data type of the ATTENDEE property.  Its not clear to me _why_ the default value is a real issue since any given value supercedes the default one...

>Though I agree that simplified term "ROLE" would suffice in denoting the
>role of a person, thing or theme in an event if it was coupled to the
>respective properties of PERSONS, THINGS, and THINKS, it is quite a stretch
>on the original intention for "ROLE" in 2445.

The original definition was based on the collective views of the roles used in "Interpersonal C&S".  SKiCal is a different critter but it still needs to convey the same basic intent that the original ROLE was designed for.  There is a reason we defined the ABNF with:

    roleparam  = "ROLE" "="
[Snip, snip]
               / x-name                ; Experimental role
               / iana-token)           ; Other IANA role
(so that oversights or additions can easily be done...)

>So for one last time I would like to hear everyone's opinion - should we
>create these three new property parameters or reuse ROLE as it was not
>intended to be used?

Ill go back to the KISS mantra and vote for a reuse.  After all the intent is the same, why make parsers / clients do more work than necessary.

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 000707B585256998_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 15 13:03:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07466 for ; Wed, 15 Nov 2000 13:03:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA05069 for ietf-calendar-bks; Wed, 15 Nov 2000 09:26:32 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05050 for ; Wed, 15 Nov 2000 09:26:30 -0800 (PST) From: Bruce_Kahn@iris.com To: sman@netscape.com (Steve Mansour) Cc: CalSched IETF Subject: Re: iTIP updates X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Wed, 15 Nov 2000 12:38:06 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/15/2000 12:38:15 PM, Serialize complete at 11/15/2000 12:38:15 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0060B3E885256998_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0060B3E885256998_= Content-Type: text/plain; charset="us-ascii" You should add the iTIP / DUE / Repeat issue I raised back on ~5-Sep-00 titled "iTIP & Repeat/DUE/Duration restrictions". The change was already proposed so its just a matter of adding to the list (unless you are only listing 'new' issues). 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 0060B3E885256998_= Content-Type: text/html; charset="us-ascii"
You should add the iTIP / DUE / Repeat issue I raised back on ~5-Sep-00 titled "iTIP & Repeat/DUE/Duration restrictions".  The change was already proposed so its just a matter of adding to the list (unless you are only listing 'new' issues).

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 0060B3E885256998_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 16 11:48:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10675 for ; Thu, 16 Nov 2000 11:47:59 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA00849 for ietf-calendar-bks; Thu, 16 Nov 2000 08:11:11 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00822 for ; Thu, 16 Nov 2000 08:11:05 -0800 (PST) From: Bruce_Kahn@iris.com To: John Stracke Cc: "ietf-calendar@imc.org" Subject: Re: Recurrence UNTIL/RDATE/EXDATE properties with DATE values X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Thu, 16 Nov 2000 11:18:27 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/16/2000 11:18:46 AM, Serialize complete at 11/16/2000 11:18:46 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0059CE4085256999_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059CE4085256999_= Content-Type: text/plain; charset="us-ascii" John replied: >> John asked: >> >Does anybody remember the motivation for permitting DATE >> values in the first place? >> >> Sure, for all day events like Bastille Day (Hi Franks >> favorite), New Years Day, etc. > >OK, in this case, *all* the values involved will be DATEs; there >will be no DATE-TIMEs at all. Correct. The times are implied to be 00:00:00 relative to the recipient. You asked for cases where VALUE=DATE were used and I gave 'em to you. Did I miss something? >> Also, dont forget that we declared (somewhere, honest!) that >> times are inherited from the DTSTART/DTEND (or DURATION) if >> none are specfied on the RDATE, EXDATE (and probably implied on >> the UNTIL too but Im not sure). > >These two statements are inconsistent. An EXDATE with no time >can't *both* default to the same time as DTSTART *and* be a >wildcard. Ok, I tried to find the text but gave up after a few min trying to find it. I recall we discussed and had some final agreement that VALUE=DATE on exceptions would not act the same as for recurrences. That way the cited example of blocking multiple instances on a single date could be done quickly. If just a instance were to be blocked then a VALUE=DATE-TIME would have to be used. If this text did not make it into the final draft then its not my fault... The concensus reached was basically: 1: RDATEs inherit the exact time from the DTSTART. If DTSTART has VALUE=DATE then the implied 00:00:00 is inherited. 2: EXDATEs do not inherit exact times if they are VALUE=DATE. By covering ANY AND ALL instances on that date they effectively achieve "excluding the date" w/o worrying about any RRULE instances that are generated (ie: FREQ=DAILY;BYHOUR=9,10,11;BYMIN=00,30,...). Excluding specific instances is done via VALUE=DATE-TIMEs. The gist of this decision was that if something repeats daily then excluding "all that day" works just as well as inheriting the time from the DTSTART. If it repeats 'sub daily' (see theatre example) then its much simpler to block an entire day by this means than using an EXRULE or several EXDATEs that may not catch any changes in the recurrence set (ie: rescheduling one showing to accomodate a private party). To exclude a particular instance on a 'sub daily' recurrence would invovle using DATE-TIMEs to be more precise. >The wildcard case can >be expressed with multiple EXDATEs with DATE-TIME values; the >default case can be expressed by specifying the EXDATE as a >DATE-TIME. So permitting DATE values for EXDATE does not add >functionality, and does add ambiguity. The ambiguity seems to stem from this text not being in the final draft we passed. A scan of the archives will show that we seemed to have neglected the recurrence grammar and engine part the most given the issues that have been arising over the past few months. Thats to be expected IMHO given how much contention there was about putting that into the initial draft. Now is the time for us to clean up the oversights and fix the problems folks are having. As for the the description of DATE-TIME vs DATE you give, Im confused by how its easier than the text I gave above. Which is simpler: Blocking the entire day no matter what instances occur then (so reschedules DO NOT require some CUA realizing that EXDATE values need to be shifted, added, etc) or having a CUA creating and maintaining lists of EXDATEs w/expressed times when the goal is to filter out the entire day?? I day 1 VALUE=DATE is MUCH MUCH easier and simpler to manage than > 1 VALUE=DATE-TIME. Perhaps the text above will have helped clear up the ambiguity folks are having... If not, what is still unclear? >I suggest that we mandate that all the various date[-time] values >in a given recurrence rule be the same type: either they're all >DATEs (for all-day events), or they're all DATE-TIMEs. I disagree for the reasons above. Perhaps its because I was involved w/the original fleshing out of the 2 rules above but Im not confused. Are others still confused?? 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 0059CE4085256999_= Content-Type: text/html; charset="us-ascii"
John replied:
>> John asked:
>> >Does anybody remember the motivation for permitting DATE
>> values in the first place?
>>
>> Sure, for all day events like Bastille Day (Hi Franks
>> favorite), New Years Day, etc.
>
>OK, in this case, *all* the values involved will be DATEs; there
>will be no DATE-TIMEs at all.

Correct.  The times are implied to be 00:00:00 relative to the recipient.  You asked for cases where VALUE=DATE were used and I gave 'em to you.  Did I miss something?

>> Also, dont forget that we declared (somewhere, honest!) that
>> times are inherited from the DTSTART/DTEND (or DURATION) if
>> none are specfied on the RDATE, EXDATE (and probably implied on
>> the UNTIL too but Im not sure).
>
>These two statements are inconsistent.  An EXDATE with no time
>can't *both* default to the same time as DTSTART *and* be a
>wildcard.

Ok, I tried to find the text but gave up after a few min trying to find it.  I recall we discussed and had some final agreement that VALUE=DATE on exceptions would not act the same as for recurrences.  That way the cited example of blocking multiple instances on a single date could be done quickly.  If just a instance were to be blocked then a VALUE=DATE-TIME would have to be used.  If this text did not make it into the final draft then its not my fault...

The concensus reached was basically:

1: RDATEs inherit the exact time from the DTSTART.  If DTSTART has VALUE=DATE then the implied 00:00:00 is inherited.
2: EXDATEs do not inherit exact times if they are VALUE=DATE.  By covering ANY AND ALL instances on that date they effectively achieve "excluding the date" w/o worrying about any RRULE instances that are generated (ie: FREQ=DAILY;BYHOUR=9,10,11;BYMIN=00,30,...).  Excluding specific instances is done via VALUE=DATE-TIMEs.

The gist of this decision was that if something repeats daily then excluding "all that day" works just as well as inheriting the time from the DTSTART.  If it repeats 'sub daily' (see theatre example) then its much simpler to block an entire day by this means than using an EXRULE or several EXDATEs that may not catch any changes in the recurrence set (ie: rescheduling one showing to accomodate a private party).  To exclude a particular instance on a 'sub daily' recurrence would invovle using DATE-TIMEs to be more precise.

>The wildcard case can
>be expressed with multiple EXDATEs with DATE-TIME values; the
>default case can be expressed by specifying the EXDATE as a
>DATE-TIME.  So permitting DATE values for EXDATE does not add
>functionality, and does add ambiguity.

The ambiguity seems to stem from this text not being in the final draft we passed.  A scan of the archives will show that we seemed to have neglected the recurrence grammar and engine part the most given the issues that have been arising over the past few months.  Thats to be expected IMHO given how much contention there was about putting that into the initial draft.  Now is the time for us to clean up the oversights and fix the problems folks are having.

As for the the description of DATE-TIME vs DATE you give, Im confused by how its easier than the text I gave above.  Which is simpler: Blocking the entire day no matter what instances occur then (so reschedules DO NOT require some CUA realizing that EXDATE values need to be shifted, added, etc) or having a CUA creating and maintaining lists of EXDATEs w/expressed times when the goal is to filter out the entire day??  I day 1 VALUE=DATE is MUCH MUCH easier and simpler to manage than > 1 VALUE=DATE-TIME.  Perhaps the text above will have helped clear up the ambiguity folks are having...  If not, what is still unclear?

>I suggest that we mandate that all the various date[-time] values
>in a given recurrence rule be the same type: either they're all
>DATEs (for all-day events), or they're all DATE-TIMEs.

I disagree for the reasons above.  Perhaps its because I was involved w/the original fleshing out of the 2 rules above but Im not confused.  Are others still confused??

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 0059CE4085256999_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 16 13:11:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12169 for ; Thu, 16 Nov 2000 13:11:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA22115 for ietf-calendar-bks; Thu, 16 Nov 2000 09:29:12 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22102 for ; Thu, 16 Nov 2000 09:29:10 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eAGHeSE05564 for ; Thu, 16 Nov 2000 12:40:28 -0500 Message-ID: <3A141C0B.1CC0ACC7@ecal.com> Date: Thu, 16 Nov 2000 12:40:27 -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: Recurrence UNTIL/RDATE/EXDATE properties with DATE values 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: > >OK, in this case, *all* the values involved will be DATEs; > there > >will be no DATE-TIMEs at all. > > Correct. The times are implied to be 00:00:00 relative to the > recipient. You asked for cases where VALUE=DATE were used and > I gave 'em to you. Did I miss something? I think the previous complication arose when DATEs were combined with DATE-TIMEs. Never mind, though; see below. > The concensus reached was basically: > > 1: RDATEs inherit the exact time from the DTSTART. If DTSTART > has VALUE=DATE then the implied 00:00:00 is inherited. > 2: EXDATEs do not inherit exact times if they are VALUE=DATE. This is the part I didn't catch before: that RDATE & EXDATE were treated differently. I can go along with that. Do we have consensus for changing the RFC, then? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"Time is money, and price is information." | |francis@ecal.com|--Russ Nelson | \==============================================================/ From owner-ietf-calendar@mail.imc.org Fri Nov 17 00:05:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18200 for ; Fri, 17 Nov 2000 00:05:45 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA22716 for ietf-calendar-bks; Thu, 16 Nov 2000 20:30:55 -0800 (PST) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22706 for ; Thu, 16 Nov 2000 20:30:52 -0800 (PST) From: pregen@egenconsulting.com To: John Stracke Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: Recurrence UNTIL/RDATE/EXDATE properties with DATE values X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 17 Nov 2000 04:38:28 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/16/2000 11:38:31 PM, Serialize complete at 11/16/2000 11:38:31 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0081F7E080256999_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0081F7E080256999_= Content-Type: text/plain; charset="us-ascii" John, since you and Bruce are the only ones commenting on the topic, I'm not sure we have concensus. If no one replies in a week, let's assume there is concensus. That ought to shake the trees a bit. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 John Stracke Sent by: owner-ietf-calendar@mail.imc.org 11/16/00 05:40 PM To: "ietf-calendar@imc.org" cc: Subject: Re: Recurrence UNTIL/RDATE/EXDATE properties with DATE values Bruce_Kahn@iris.com wrote: > >OK, in this case, *all* the values involved will be DATEs; > there > >will be no DATE-TIMEs at all. > > Correct. The times are implied to be 00:00:00 relative to the > recipient. You asked for cases where VALUE=DATE were used and > I gave 'em to you. Did I miss something? I think the previous complication arose when DATEs were combined with DATE-TIMEs. Never mind, though; see below. > The concensus reached was basically: > > 1: RDATEs inherit the exact time from the DTSTART. If DTSTART > has VALUE=DATE then the implied 00:00:00 is inherited. > 2: EXDATEs do not inherit exact times if they are VALUE=DATE. This is the part I didn't catch before: that RDATE & EXDATE were treated differently. I can go along with that. Do we have consensus for changing the RFC, then? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"Time is money, and price is information." | |francis@ecal.com|--Russ Nelson | \==============================================================/ --=_alternative 0081F7E080256999_= Content-Type: text/html; charset="us-ascii"
John, since you and Bruce are the only ones commenting on the topic, I'm not sure we have concensus.  If no one replies in a week, let's assume there is concensus.  That ought to shake the trees a bit.  
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


John Stracke <francis@ecal.com>
Sent by: owner-ietf-calendar@mail.imc.org

11/16/00 05:40 PM

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: Recurrence UNTIL/RDATE/EXDATE properties with DATE values



Bruce_Kahn@iris.com wrote:

> >OK, in this case, *all* the values involved will be DATEs;
> there
> >will be no DATE-TIMEs at all.
>
> Correct.  The times are implied to be 00:00:00 relative to the
> recipient.  You asked for cases where VALUE=DATE were used and
> I gave 'em to you.  Did I miss something?

I think the previous complication arose when DATEs were combined
with DATE-TIMEs.  Never mind, though; see below.

> The concensus reached was basically:
>
> 1: RDATEs inherit the exact time from the DTSTART.  If DTSTART
> has VALUE=DATE then the implied 00:00:00 is inherited.
> 2: EXDATEs do not inherit exact times if they are VALUE=DATE.

This is the part I didn't catch before: that RDATE & EXDATE were
treated differently.  I can go along with that.  Do we have
consensus for changing the RFC, then?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Time is money, and price is information."   |
|francis@ecal.com|--Russ Nelson                                |
\==============================================================/

--=_alternative 0081F7E080256999_=-- From owner-ietf-calendar@mail.imc.org Fri Nov 17 17:13:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12482 for ; Fri, 17 Nov 2000 17:13:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14311 for ietf-calendar-bks; Fri, 17 Nov 2000 13:37:28 -0800 (PST) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14299 for ; Fri, 17 Nov 2000 13:37:26 -0800 (PST) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: CAP requirements draft resubmitted X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 17 Nov 2000 21:45:10 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/17/2000 04:45:08 PM, Serialize complete at 11/17/2000 04:45:08 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005C21448025699A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C21448025699A_= Content-Type: text/plain; charset="us-ascii" I resubmitted the CAP requirements draft today. It expired and I submitted it for reinstatement since we are still working on CAP. We may need to make more adjustments, but I wanted the draft there so we can make more modifications. In particular, the requirements state several items about synchronizing calendars. However, as CAP stands today (in the draft) we don't have this included. So, the question is - do we keep it in the requirements? If so, do we add it into CAP? Thoughts from the list. Also, there have been several items on the list regarding restriction tables. Unless we hear otherwise from people on the list, we will assume they look ok. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 005C21448025699A_= Content-Type: text/html; charset="us-ascii"
I resubmitted the CAP requirements draft today.  It expired and I submitted it for reinstatement since we are still working on CAP.  We may need to make more adjustments, but I wanted the draft there so we can make more modifications.  In particular, the requirements state several items about synchronizing calendars. However, as CAP stands today (in the draft) we don't have this included.  So, the question is - do we keep it in the requirements? If so, do we add it into CAP? Thoughts from the list.

Also, there have been several items on the list regarding restriction tables.  Unless we hear otherwise from people on the list, we will assume they look ok.    
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 005C21448025699A_=-- From owner-ietf-calendar@mail.imc.org Sat Nov 18 17:42:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13046 for ; Sat, 18 Nov 2000 17:42:06 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04773 for ietf-calendar-bks; Sat, 18 Nov 2000 14:17:25 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04767 for ; Sat, 18 Nov 2000 14:17:24 -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 eAIMGxD08309 for ; Sat, 18 Nov 2000 14:16:59 -0800 (PST) Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G48RL500.AU2 for ; Sat, 18 Nov 2000 14:24:41 -0800 Message-ID: <3A170321.9E311119@netscape.com> Date: Sat, 18 Nov 2000 14:30:57 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: iTIP question for all... Content-Type: multipart/mixed; boundary="------------8CF9DC3F7B886336EE961C89" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8CF9DC3F7B886336EE961C89 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm reviewing the updates to iTIP. I'd like your feedback on an issue involving the new CONFIRM method. What does it mean when you receive a CONFIRM method in an ITIP message and you look for the UID / Recurrence-id of the event (or todo) in your calendar and it's not there? Since the intent of this command is to (a) reply to a REFRESH and (b) notify participants of any changes to the ATTENDEEs or the ORGANIZER, it's not clear what should happen. Any thoughts on this? -Steve --------------8CF9DC3F7B886336EE961C89 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;work:408-276-4268 x-mozilla-html:FALSE org:;Netscape adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------8CF9DC3F7B886336EE961C89-- From owner-ietf-calendar@mail.imc.org Sun Nov 19 03:22:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02579 for ; Sun, 19 Nov 2000 03:22:43 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA02791 for ietf-calendar-bks; Sat, 18 Nov 2000 23:59:39 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02779 for ; Sat, 18 Nov 2000 23:59:36 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA27319 for ietf-calendar@imc.org; Sun, 19 Nov 2000 00:00:03 -0800 (PST) Date: Sun, 19 Nov 2000 00:00:03 -0800 (PST) From: Doug Royer Message-Id: <200011190800.AAA27319@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 Nov 19 23:16:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16955 for ; Sun, 19 Nov 2000 23:16:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA13691 for ietf-calendar-bks; Sun, 19 Nov 2000 19:56:48 -0800 (PST) Received: from bcryachts.atsat.com (IDENT:root@bcryachts.atsat.com [195.10.32.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13687 for ; Sun, 19 Nov 2000 19:56:45 -0800 (PST) Received: from localhost (morten@localhost) by bcryachts.atsat.com (8.9.3/8.9.3) with ESMTP id VAA22915 for ; Sun, 19 Nov 2000 21:58:17 -0600 Date: Mon, 20 Nov 2000 04:58:17 +0100 (CET) From: "Morten W. Petersen" X-Sender: morten@bcryachts.atsat.com To: ietf-calendar@imc.org Subject: Calendar modules in Python 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: A Pehr Anderson was so kind as to reply to a posting I made on usenet, where I was asking if anyone knew about modules / programs written in Python that covered any of the RFCs 2445, 2446, 2447, 2425 and 2426. He said it could be a good idea to post to this list; so here I am.. It's for a project I'm working on now, a 'groupware' package for Zope, located at http://www.zope.org/Members/morphex/ZopeGUM, and as you can see there, it's released under the GPL, so the code must be available under a GPL-friendly license. Thank you for your time. -Morten From owner-ietf-calendar@mail.imc.org Mon Nov 20 08:18:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08547 for ; Mon, 20 Nov 2000 08:18:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA04546 for ietf-calendar-bks; Mon, 20 Nov 2000 05:01:37 -0800 (PST) Received: from jupiter.wwweiss.de (jupiter.wwweiss.de [194.25.217.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04542 for ; Mon, 20 Nov 2000 05:01:36 -0800 (PST) Received: from ra.ibn.de [62.227.160.230] by wwweiss.de [194.25.217.98] with SMTP (MDaemon.v3.0.3.R) for ; Mon, 20 Nov 2000 14:02:05 +0100 Received: from ibn.de (root@ra.ibn.de [192.168.5.100]) by ra.ibn.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA11057 for ; Mon, 20 Nov 2000 14:55:38 +0100 Message-ID: <3A192D5A.760F217E@ibn.de> Date: Mon, 20 Nov 2000 13:55:38 +0000 From: Martin Neimeier X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: IETF-Calendar-Mailinglist Subject: Recurrence-Rule-Question Content-Type: multipart/mixed; boundary="------------9951826B9522427E65E5620C" X-MDaemon-Deliver-To: ietf-calendar@imc.org X-Return-Path: nei@ibn.de X-MDRcpt-To: ietf-calendar@imc.org X-MDRemoteIP: 62.227.160.230 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9951826B9522427E65E5620C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, while defining Timezones, i found the following rule: Chile: - Zone:America/Santiago, GMT-Offset:-4:00, Starting-Date: 1932, September - Daylight-Saving-Time starts in October at the first Sunday which is greater or equal than the 9.th on 0:00 with a saving of 1 hours. (Observance begins in the year 1999). Name is CLST - Standard-Time starts in March at the first Sunday which is greater or equal than the 9.th on 0:00 with a saving of 0 hours. (Observance begins in the year 2000). Name is CLST What will be the correct timzone-definition. Respectively the DTSTART, TZOFFSETFROM/TO and RRULE-Properties for the DAYLIGHT and STANDARD-subcomponents. cu Martin -- UNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things. (Doug Gwyn) -- Martin Neimeier / Ingenieur-Buero Neimeier / Schwarzach / Germany mailto:nei@ibn.de / http://www.ibn.de (under heavy reconstruction) / Tel:+49(6262)912344 / Fax:+49(6262)912347 --------------9951826B9522427E65E5620C Content-Type: text/x-vcard; charset=us-ascii; name="nei.vcf" Content-Description: Card for Martin Neimeier Content-Disposition: attachment; filename="nei.vcf" X-MIME-Autoconverted: from 8bit to quoted-printable by ra.ibn.de id OAA11057 Content-Transfer-Encoding: quoted-printable begin:vcard=20 n:Neimeier;Martin tel;cell:+49 (172) 7445912 tel;fax:+49 (6262) 912347 tel;work:+49 (6262) 912344 x-mozilla-html:FALSE org:Ingenieur-B=FCro Neimeier adr:;;Vogelsang 3;Schwarzach;BW;74869;Germany version:2.1 email;internet:nei@ibn.de x-mozilla-cpt:;0 fn:Martin Neimeier end:vcard --------------9951826B9522427E65E5620C-- From owner-ietf-calendar@mail.imc.org Mon Nov 20 08:36:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09112 for ; Mon, 20 Nov 2000 08:36:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA05000 for ietf-calendar-bks; Mon, 20 Nov 2000 05:18:29 -0800 (PST) Received: from jupiter.wwweiss.de (jupiter.wwweiss.de [194.25.217.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04995 for ; Mon, 20 Nov 2000 05:18:27 -0800 (PST) Received: from ra.ibn.de [62.227.160.225] by wwweiss.de [194.25.217.98] with SMTP (MDaemon.v3.0.3.R) for ; Mon, 20 Nov 2000 14:19:07 +0100 Received: from ibn.de (root@ra.ibn.de [192.168.5.100]) by ra.ibn.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA11175 for ; Mon, 20 Nov 2000 15:13:29 +0100 Message-ID: <3A193187.C71F02CA@ibn.de> Date: Mon, 20 Nov 2000 14:13:27 +0000 From: Martin Neimeier X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: IETF-Calendar-Mailinglist Subject: RRULE-Question Content-Type: multipart/mixed; boundary="------------F0A9AD85BE008AA0715BE386" X-MDaemon-Deliver-To: ietf-calendar@imc.org X-Return-Path: nei@ibn.de X-MDRcpt-To: ietf-calendar@imc.org X-MDRemoteIP: 62.227.160.225 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F0A9AD85BE008AA0715BE386 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, the correct question is: How can I describe the Rule "the (first) sunday which is greater or equal than the 9.th of october" cu Martin -- UNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things. (Doug Gwyn) -- Martin Neimeier / Ingenieur-Buero Neimeier / Schwarzach / Germany mailto:nei@ibn.de / http://www.ibn.de (under heavy reconstruction) / Tel:+49(6262)912344 / Fax:+49(6262)912347 --------------F0A9AD85BE008AA0715BE386 Content-Type: text/x-vcard; charset=us-ascii; name="nei.vcf" Content-Description: Card for Martin Neimeier Content-Disposition: attachment; filename="nei.vcf" X-MIME-Autoconverted: from 8bit to quoted-printable by ra.ibn.de id PAA11175 Content-Transfer-Encoding: quoted-printable begin:vcard=20 n:Neimeier;Martin tel;cell:+49 (172) 7445912 tel;fax:+49 (6262) 912347 tel;work:+49 (6262) 912344 x-mozilla-html:FALSE org:Ingenieur-B=FCro Neimeier adr:;;Vogelsang 3;Schwarzach;BW;74869;Germany version:2.1 email;internet:nei@ibn.de x-mozilla-cpt:;0 fn:Martin Neimeier end:vcard --------------F0A9AD85BE008AA0715BE386-- From owner-ietf-calendar@mail.imc.org Mon Nov 20 10:13:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12348 for ; Mon, 20 Nov 2000 10:13:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA10090 for ietf-calendar-bks; Mon, 20 Nov 2000 06:58:51 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10085 for ; Mon, 20 Nov 2000 06:58:50 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eAKF3OA08677 for ; Mon, 20 Nov 2000 10:03:24 -0500 Message-ID: <3A193D3C.358180FE@ecal.com> Date: Mon, 20 Nov 2000 10:03:24 -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 Subject: Re: SV: SKiCal & Roles 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: > Ill go back to the KISS mantra and vote for a reuse. And, if it can't be reused, then it probably shouldn't be called a role at all; too confusing. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"HTTP is what happens in the absence of good | |francis@ecal.com|design." -- Keith Moore | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 20 10:16:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12390 for ; Mon, 20 Nov 2000 10:16:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10386 for ietf-calendar-bks; Mon, 20 Nov 2000 07:00:55 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10381 for ; Mon, 20 Nov 2000 07:00:54 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eAKF5RA08681 for ; Mon, 20 Nov 2000 10:05:28 -0500 Message-ID: <3A193DB7.1BDE8430@ecal.com> Date: Mon, 20 Nov 2000 10:05:27 -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: CalSched IETF Subject: Re: iTIP question for all... References: <3A170321.9E311119@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: > What does it mean when you receive a CONFIRM method in an ITIP message > and you look for the UID / Recurrence-id of the event (or todo) in your > calendar and it's not there? To mean it means either (a) the user asked for a REFRESH and then decided to delete the event, or (b) some attacker is sending an unsolicited CONFIRM in the hopes of feeding an event into the user's calendar. Either way, I should ignore the CONFIRM. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |It's not an optical illusion, it just looks like| |francis@ecal.com|one. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 20 10:58:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13822 for ; Mon, 20 Nov 2000 10:58:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17660 for ietf-calendar-bks; Mon, 20 Nov 2000 07:40:56 -0800 (PST) Received: from jupiter.wwweiss.de (jupiter.wwweiss.de [194.25.217.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17652 for ; Mon, 20 Nov 2000 07:40:54 -0800 (PST) Received: from ra.ibn.de [193.159.5.215] by wwweiss.de [194.25.217.98] with SMTP (MDaemon.v3.0.3.R) for ; Mon, 20 Nov 2000 16:41:35 +0100 Received: from ibn.de (root@ra.ibn.de [192.168.5.100]) by ra.ibn.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA17434; Mon, 20 Nov 2000 17:37:21 +0100 Message-ID: <3A195341.7331355C@ibn.de> Date: Mon, 20 Nov 2000 16:37:21 +0000 From: Martin Neimeier X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: mikec@meetingmaker.com, IETF-Calendar-Mailinglist Subject: Re: Recurrence-Rule-Question References: <8525699D.005069EF.00@lnsmtp.on.com> Content-Type: multipart/mixed; boundary="------------12F0206FFD421F7B5993A7A9" X-MDaemon-Deliver-To: ietf-calendar@imc.org X-Return-Path: nei@ibn.de X-MDRcpt-To: mikec@meetingmaker.com X-MDRemoteIP: 193.159.5.215 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------12F0206FFD421F7B5993A7A9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit mikec@meetingmaker.com wrote: > > This is how I defined Chile, I agree with what you have. > > tzid: CHL Chile, Santiago > Standard: > valid : 1 > dtstart : 1/1/1904 T 0:0:0 > interval_start : MONTH=3, Order=1, DOW=0, BMD=9, HH=0, MM=0 > offset_from_UTC: -3 > offset_to_UTC : -4 > name : Chile, Santiago > Daylight: > valid : 1 > dtstart : 1/1/1904 T 0:0:0 > interval_start : MONTH=10, Order=1, DOW=0, BMD=9, HH=0, MM=0 > offset_from_UTC: -4 > offset_to_UTC : -3 > name : Chile, Santiago,DST Hello, If im correct, you use (for DAYLIGHT): RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=SU;BYMONTHDAY=9 but I think it must be: RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=SU;BYMONTHDAY=9,10,11,12,13,14,15 Thats the reason for my question. Describing "Sun>=9" as "BYMONTHDAY=9,10,11,12,13,14,15;BYDAY=SU" is no nice solution. I think there should be a better way, to do this like: BYMONTHDAY=GEQ(9);BYDAY=SU" (GEQ means greater or equal) This is only an Idea. cu Martin -- UNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things. (Doug Gwyn) -- Martin Neimeier / Ingenieur-Buero Neimeier / Schwarzach / Germany mailto:nei@ibn.de / http://www.ibn.de (under heavy reconstruction) / Tel:+49(6262)912344 / Fax:+49(6262)912347 --------------12F0206FFD421F7B5993A7A9 Content-Type: text/x-vcard; charset=us-ascii; name="nei.vcf" Content-Description: Card for Martin Neimeier Content-Disposition: attachment; filename="nei.vcf" X-MIME-Autoconverted: from 8bit to quoted-printable by ra.ibn.de id RAA17434 Content-Transfer-Encoding: quoted-printable begin:vcard=20 n:Neimeier;Martin tel;cell:+49 (172) 7445912 tel;fax:+49 (6262) 912347 tel;work:+49 (6262) 912344 x-mozilla-html:FALSE org:Ingenieur-B=FCro Neimeier adr:;;Vogelsang 3;Schwarzach;BW;74869;Germany version:2.1 email;internet:nei@ibn.de x-mozilla-cpt:;0 fn:Martin Neimeier end:vcard --------------12F0206FFD421F7B5993A7A9-- From owner-ietf-calendar@mail.imc.org Mon Nov 20 11:33:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18716 for ; Mon, 20 Nov 2000 11:33:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22791 for ietf-calendar-bks; Mon, 20 Nov 2000 08:12:34 -0800 (PST) Received: from jupiter.wwweiss.de (jupiter.wwweiss.de [194.25.217.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22786 for ; Mon, 20 Nov 2000 08:12:31 -0800 (PST) Received: from ra.ibn.de [62.227.162.236] by wwweiss.de [194.25.217.98] with SMTP (MDaemon.v3.0.3.R) for ; Mon, 20 Nov 2000 17:13:10 +0100 Received: from ibn.de (root@ra.ibn.de [192.168.5.100]) by ra.ibn.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA18219; Mon, 20 Nov 2000 18:10:45 +0100 Message-ID: <3A195B15.5553E2FD@ibn.de> Date: Mon, 20 Nov 2000 17:10:45 +0000 From: Martin Neimeier X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: mikec@meetingmaker.com, IETF-Calendar-Mailinglist Subject: Re: Recurrence-Rule-Question References: <8525699D.0056EF87.00@lnsmtp.on.com> Content-Type: multipart/mixed; boundary="------------1D26C552C7D714E281A43664" X-MDaemon-Deliver-To: ietf-calendar@imc.org X-Return-Path: nei@ibn.de X-MDRcpt-To: mikec@meetingmaker.com X-MDRemoteIP: 62.227.162.236 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1D26C552C7D714E281A43664 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit mikec@meetingmaker.com wrote: > > Sure, what I sent you was from my logging dump file which kinda spells it > out... in english for debugging purposes... > > I don't care about DTSTART so that time is zero for my purposes.... > > BEGIN:VTIMEZONE > TZID:Chile, Santiago (CHL) > BEGIN:STANDARD > DTSTART: > RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=3;BYMONTHDAY=9;BYHOUR=0;BYMINUTE=0 > TZOFFSETFROM:-0300 > TZOFFSETTO:-0400 > TZNAME:Chile, Santiago > END:STANDARD > BEGIN:DAYLIGHT > DTSTART: > RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=10;BYMONTHDAY=9;BYHOUR=0;BYMINUTE=0 > TZOFFSETFROM:-0400 > TZOFFSETTO:-0300 > TZNAME:Chile, Santiago,DST > END:DAYLIGHT > END:VTIMEZONE Some corrections: 1. DTSTART is a MUST for STANDARD and DAYLIGHT and cannot be empty (it MUST be a local DATE-TIME) 2. RRULE should be RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=3;BYMONTHDAY=9,10,11,12,13,14,15 3. The correct TZID should be "America/Santiago" 4. The DAYLIGHT-TZNAME should be "CLST" 5. The STANDARD-TZNAME should be "CLT" My version: BEGIN:VTIMEZONE TZID:America/Santiago TZURL:ftp://elsie.nci.nih.gov/pub/ BEGIN:STANDARD DTSTART:20000312T000000 RRULE:FREQ=YEARLY;BYDAY=SU;BYMONTH=3;BYMONTHDAY=9,10,11,12,13,14,15 TZOFFSETFROM:-0300 TZOFFSETTO:-0400 TZNAME:CLT END:STANDARD BEGIN:DAYLIGHT DTSTART:19991010T000000 RRULE:FREQ=YEARLY;BYDAY=SU;BYMONTH=10;BYMONTHDAY=9,10,11,12,13,14,15 TZOFFSETFROM:-0400 TZOFFSETTO:-0300 TZNAME:CLST END:DAYLIGHT END:VTIMEZONE Is this now correct ? cu Martin -- UNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things. (Doug Gwyn) -- Martin Neimeier / Ingenieur-Buero Neimeier / Schwarzach / Germany mailto:nei@ibn.de / http://www.ibn.de (under heavy reconstruction) / Tel:+49(6262)912344 / Fax:+49(6262)912347 --------------1D26C552C7D714E281A43664 Content-Type: text/x-vcard; charset=us-ascii; name="nei.vcf" Content-Description: Card for Martin Neimeier Content-Disposition: attachment; filename="nei.vcf" X-MIME-Autoconverted: from 8bit to quoted-printable by ra.ibn.de id SAA18219 Content-Transfer-Encoding: quoted-printable begin:vcard=20 n:Neimeier;Martin tel;cell:+49 (172) 7445912 tel;fax:+49 (6262) 912347 tel;work:+49 (6262) 912344 x-mozilla-html:FALSE org:Ingenieur-B=FCro Neimeier adr:;;Vogelsang 3;Schwarzach;BW;74869;Germany version:2.1 email;internet:nei@ibn.de x-mozilla-cpt:;0 fn:Martin Neimeier end:vcard --------------1D26C552C7D714E281A43664-- From owner-ietf-calendar@mail.imc.org Mon Nov 20 12:02:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25154 for ; Mon, 20 Nov 2000 12:02:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24897 for ietf-calendar-bks; Mon, 20 Nov 2000 08:47:48 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24891 for ; Mon, 20 Nov 2000 08:47: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 LAA00435 for ; Mon, 20 Nov 2000 11:48:01 -0500 Received: from pc152 (pc-152.CST.CA [193.77.49.137]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XCXJXHK7; Mon, 20 Nov 2000 11:49:12 -0500 Message-ID: <031401c05311$a03f5b30$89314dc1@cst.ca> From: "Graham Gilmore" To: References: <8525699D.0056EF87.00@lnsmtp.on.com> <3A195B15.5553E2FD@ibn.de> Subject: Re: Recurrence-Rule-Question Date: Mon, 20 Nov 2000 11:47:53 -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.2314.1300 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: Content-Transfer-Encoding: 7bit On 20 November, 2000 12:10, Martin Neimeier wrote: > Some corrections: > 3. The correct TZID should be "America/Santiago" According to 4.8.3.1 of rfc2445, the TZID property is pretty much an arbitrary string : "Note: this document does not define a naming convention for zone identifiers." As long as your date-time TZID parameter values refer to your own VTIMEZONE objects by the correct TZID, I think you're safe. Has this changed? Graham Gilmore From owner-ietf-calendar@mail.imc.org Mon Nov 20 13:17:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15532 for ; Mon, 20 Nov 2000 13:17:38 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA00557 for ietf-calendar-bks; Mon, 20 Nov 2000 09:51:41 -0800 (PST) Received: from jupiter.wwweiss.de (jupiter.wwweiss.de [194.25.217.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00534 for ; Mon, 20 Nov 2000 09:51:38 -0800 (PST) Received: from ra.ibn.de [62.227.164.243] by wwweiss.de [194.25.217.98] with SMTP (MDaemon.v3.0.3.R) for ; Mon, 20 Nov 2000 18:52:20 +0100 Received: from ibn.de (root@ra.ibn.de [192.168.5.100]) by ra.ibn.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA19686; Mon, 20 Nov 2000 19:49:59 +0100 Message-ID: <3A197256.57B8748@ibn.de> Date: Mon, 20 Nov 2000 18:49:58 +0000 From: Martin Neimeier X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Martin Neimeier , IETF-Calendar-Mailinglist Subject: Re: Recurrence-Rule-Question References: <8525699D.0056EF87.00@lnsmtp.on.com> <3A195B15.5553E2FD@ibn.de> Content-Type: multipart/mixed; boundary="------------C6D0614547E8DEC048E91EE7" X-MDaemon-Deliver-To: ietf-calendar@imc.org X-Return-Path: nei@ibn.de X-MDRcpt-To: ietf-calendar@imc.org X-MDRemoteIP: 62.227.164.243 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C6D0614547E8DEC048E91EE7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martin Neimeier wrote: > > mikec@meetingmaker.com wrote: > > > > Sure, what I sent you was from my logging dump file which kinda spells it > > out... in english for debugging purposes... > > > > I don't care about DTSTART so that time is zero for my purposes.... > > > > BEGIN:VTIMEZONE > > TZID:Chile, Santiago (CHL) > > BEGIN:STANDARD > > DTSTART: > > RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=3;BYMONTHDAY=9;BYHOUR=0;BYMINUTE=0 > > TZOFFSETFROM:-0300 > > TZOFFSETTO:-0400 > > TZNAME:Chile, Santiago > > END:STANDARD > > BEGIN:DAYLIGHT > > DTSTART: > > RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=10;BYMONTHDAY=9;BYHOUR=0;BYMINUTE=0 > > TZOFFSETFROM:-0400 > > TZOFFSETTO:-0300 > > TZNAME:Chile, Santiago,DST > > END:DAYLIGHT > > END:VTIMEZONE > > Some corrections: > > 1. DTSTART is a MUST for STANDARD and DAYLIGHT and cannot be empty (it MUST be a local DATE-TIME) > 2. RRULE should be RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=3;BYMONTHDAY=9,10,11,12,13,14,15 > 3. The correct TZID should be "America/Santiago" > 4. The DAYLIGHT-TZNAME should be "CLST" > 5. The STANDARD-TZNAME should be "CLT" > > My version: > > BEGIN:VTIMEZONE > TZID:America/Santiago > TZURL:ftp://elsie.nci.nih.gov/pub/ > BEGIN:STANDARD > DTSTART:20000312T000000 > RRULE:FREQ=YEARLY;BYDAY=SU;BYMONTH=3;BYMONTHDAY=9,10,11,12,13,14,15 > TZOFFSETFROM:-0300 > TZOFFSETTO:-0400 > TZNAME:CLT > END:STANDARD > BEGIN:DAYLIGHT > DTSTART:19991010T000000 > RRULE:FREQ=YEARLY;BYDAY=SU;BYMONTH=10;BYMONTHDAY=9,10,11,12,13,14,15 > TZOFFSETFROM:-0400 > TZOFFSETTO:-0300 > TZNAME:CLST > END:DAYLIGHT > END:VTIMEZONE > > Is this now correct ? > > cu > Martin > -- > UNIX was never designed to keep people from doing stupid things, because > that policy would also keep them from doing clever things. (Doug Gwyn) > -- > Martin Neimeier / Ingenieur-Buero Neimeier / Schwarzach / Germany > mailto:nei@ibn.de / http://www.ibn.de (under heavy reconstruction) / Tel:+49(6262)912344 / > Fax:+49(6262)912347 Okay, ignore the points 3 to 5. This is only my opinion and no specified RULE in RFC2445. But whats with the rest ? cu Martin -- UNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things. (Doug Gwyn) -- Martin Neimeier / Ingenieur-Buero Neimeier / Schwarzach / Germany mailto:nei@ibn.de / http://www.ibn.de (under heavy reconstruction) / Tel:+49(6262)912344 / Fax:+49(6262)912347 --------------C6D0614547E8DEC048E91EE7 Content-Type: text/x-vcard; charset=us-ascii; name="nei.vcf" Content-Description: Card for Martin Neimeier Content-Disposition: attachment; filename="nei.vcf" X-MIME-Autoconverted: from 8bit to quoted-printable by ra.ibn.de id TAA19686 Content-Transfer-Encoding: quoted-printable begin:vcard=20 n:Neimeier;Martin tel;cell:+49 (172) 7445912 tel;fax:+49 (6262) 912347 tel;work:+49 (6262) 912344 x-mozilla-html:FALSE org:Ingenieur-B=FCro Neimeier adr:;;Vogelsang 3;Schwarzach;BW;74869;Germany version:2.1 email;internet:nei@ibn.de x-mozilla-cpt:;0 fn:Martin Neimeier end:vcard --------------C6D0614547E8DEC048E91EE7-- From owner-ietf-calendar@mail.imc.org Tue Nov 21 02:53:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09668 for ; Tue, 21 Nov 2000 02:53:38 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA02448 for ietf-calendar-bks; Mon, 20 Nov 2000 23:37:02 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02436 for ; Mon, 20 Nov 2000 23:37:00 -0800 (PST) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id ECD9AB34FA; Tue, 21 Nov 2000 08:37:42 +0100 (CET) From: "Greg FitzPatrick" To: "John Stracke" , "Ietf" Subject: SV: SV: SKiCal & Roles Date: Tue, 21 Nov 2000 08:37:54 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <3A193D3C.358180FE@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit john wrote : And, if it can't be reused, then it probably shouldn't be called a role at all; too confusing. Any suggestions:-? "Function" comes to mind. Greg From owner-ietf-calendar@mail.imc.org Tue Nov 21 08:22:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25229 for ; Tue, 21 Nov 2000 08:22:46 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA08742 for ietf-calendar-bks; Tue, 21 Nov 2000 05:04:41 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08735 for ; Tue, 21 Nov 2000 05:04:39 -0800 (PST) From: andrec@steltor.com 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 IAA12584; Tue, 21 Nov 2000 08:04:59 -0500 Received: by apollo.CST.CA with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 08:06:12 -0500 Message-ID: To: ietf-calendar@imc.org Cc: pregen@egenconsulting.com Subject: RE: CAP requirements draft resubmitted Date: Tue, 21 Nov 2000 08:06:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C053BB.D261FA00" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C053BB.D261FA00 Content-Type: text/plain; charset="iso-8859-1" Pat, Renewing CAP requirements is good thing. It will help to keep us on track. Regarding syncronization, in this age of mobile users with multiple handheld devices, we need to ensure that calendar stores can be performed efficiently with the basic commands of the protocol. I am of the opinion that syncronization capabilities are fundamental to ensure acceptance of CAP as a protocol. I think that we have all the basic contructs in the protocol to do it. My vote is "YES" lets keep it in and lets make sure we have all the pieces to allow for instance a SyncML client to be properly layed on top of CAP. It should not take too much time. Comments? Andre Courtemanche CEO, Steltor. Formerly known as CS&T/Lexacom. -----Original Message----- From: pregen@egenconsulting.com [mailto:pregen@egenconsulting.com] Sent: Friday, November 17, 2000 4:45 PM To: ietf-calendar@imc.org Subject: CAP requirements draft resubmitted I resubmitted the CAP requirements draft today. It expired and I submitted it for reinstatement since we are still working on CAP. We may need to make more adjustments, but I wanted the draft there so we can make more modifications. In particular, the requirements state several items about synchronizing calendars. However, as CAP stands today (in the draft) we don't have this included. So, the question is - do we keep it in the requirements? If so, do we add it into CAP? Thoughts from the list. Also, there have been several items on the list regarding restriction tables. Unless we hear otherwise from people on the list, we will assume they look ok. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 ------_=_NextPart_001_01C053BB.D261FA00 Content-Type: text/html; charset="iso-8859-1"
Pat,
 
Renewing CAP requirements is good thing. It will help to keep us on track.
 
Regarding syncronization, in this age of mobile users with multiple handheld devices, we need to
ensure that calendar stores can be performed efficiently with the basic commands of the protocol.
I am of the opinion that syncronization capabilities are fundamental to ensure acceptance of
CAP as a protocol. I think that we have all the basic contructs in the protocol to do it.
 
My vote is "YES" lets keep it in and lets make sure we have all the pieces to allow for instance
a SyncML client to be properly layed on top of CAP. It should not take too much time.
 
Comments?
 
Andre Courtemanche
CEO, Steltor.
Formerly known as CS&T/Lexacom.

 -----Original Message-----
From: pregen@egenconsulting.com [mailto:pregen@egenconsulting.com]
Sent: Friday, November 17, 2000 4:45 PM
To: ietf-calendar@imc.org
Subject: CAP requirements draft resubmitted


I resubmitted the CAP requirements draft today.  It expired and I submitted it for reinstatement since we are still working on CAP.  We may need to make more adjustments, but I wanted the draft there so we can make more modifications.  In particular, the requirements state several items about synchronizing calendars. However, as CAP stands today (in the draft) we don't have this included.  So, the question is - do we keep it in the requirements? If so, do we add it into CAP? Thoughts from the list.

Also, there have been several items on the list regarding restriction tables.  Unless we hear otherwise from people on the list, we will assume they look ok.    
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
------_=_NextPart_001_01C053BB.D261FA00-- From owner-ietf-calendar@mail.imc.org Tue Nov 21 11:42:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07907 for ; Tue, 21 Nov 2000 11:42:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25162 for ietf-calendar-bks; Tue, 21 Nov 2000 08:24:05 -0800 (PST) Received: from lnsmtp.on.com (lnsmtp.on.com [207.18.216.12]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA25158 for ; Tue, 21 Nov 2000 08:24:03 -0800 (PST) From: svangasse@meetingmaker.com Received: by lnsmtp.on.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 8525699E.005A84A1 ; Tue, 21 Nov 2000 11:28:41 -0500 X-Lotus-FromDomain: ON TECHNOLOGY To: ietf-calendar@imc.org Message-ID: <8525699E.005A8448.00@lnsmtp.on.com> Date: Tue, 21 Nov 2000 11:15:15 -0500 Subject: DTSTART property in VTIMEZONE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Has anyone annotated the DTSTART times for each timezone from the Olsen database? From owner-ietf-calendar@mail.imc.org Tue Nov 21 13:00:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23692 for ; Tue, 21 Nov 2000 13:00:02 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA29997 for ietf-calendar-bks; Tue, 21 Nov 2000 09:33:56 -0800 (PST) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29984 for ; Tue, 21 Nov 2000 09:33:52 -0800 (PST) From: pregen@egenconsulting.com To: "Greg FitzPatrick" Cc: "John Stracke" , "Ietf" , owner-ietf-calendar@mail.imc.org Subject: Re: SV: SV: SKiCal & Roles X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 21 Nov 2000 17:34:43 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/21/2000 12:34:44 PM, Serialize complete at 11/21/2000 12:34:44 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00453CA28025699E_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00453CA28025699E_= Content-Type: text/plain; charset="us-ascii" Greg, there could potentially be multiple drafts that occur that work in conjunction with RFC 2445. An example that comes to mind is RFC822. Many drafts reference it, but do not change what RFC 822 stated. Nor was RFC 822 changed to work with the other drafts. I don't think it is appropriate in this case to change RFC 2445. What you requested is not a change to something "broken". If a draft does have a flaw or is wrong, then it is appropriate to change it. I don't see where your requested change is a "fix." Therefore, you need to follow a path of referencing RFC2445 and state where your draft "enhances" or "extends" or some sort of language, the RFC 2445 draft. It would be impossible to keep up a RFC if we had to go and change it every time a new draft comes into play that uses or references it.. Hope this helps with your thinking a bit. "Greg FitzPatrick" Sent by: owner-ietf-calendar@mail.imc.org 11/21/00 07:37 AM To: "John Stracke" , "Ietf" cc: Subject: SV: SV: SKiCal & Roles john wrote : And, if it can't be reused, then it probably shouldn't be called a role at all; too confusing. Any suggestions:-? "Function" comes to mind. Greg --=_alternative 00453CA28025699E_= Content-Type: text/html; charset="us-ascii"
Greg,  there could potentially be multiple drafts that occur that work in conjunction with RFC 2445.  An example that comes to mind is RFC822.  Many drafts reference it, but do not change what RFC 822 stated.  Nor was RFC 822 changed to work with the other drafts.

I don't think it is appropriate in this case to change RFC 2445.  What you requested is not a change to something "broken".  If a draft does have a flaw or is wrong, then it is appropriate to change it.  I don't see where your requested change is a "fix."

Therefore, you need to follow a path of referencing  RFC2445 and state where your draft "enhances" or "extends" or some sort of language, the RFC 2445 draft.  It would be impossible to keep up a RFC if we had to go and change it every time a new draft comes into play that uses or references it..  Hope this helps with your thinking a bit.



"Greg FitzPatrick" <greg.fitzpatrick@metamatrix.se>
Sent by: owner-ietf-calendar@mail.imc.org

11/21/00 07:37 AM

       
        To:        "John Stracke" <francis@ecal.com>, "Ietf" <ietf-calendar@imc.org>
        cc:        
        Subject:        SV: SV: SKiCal & Roles





john wrote :
And, if it can't be reused, then it probably shouldn't be called
a role at all; too confusing.

Any suggestions:-?

"Function" comes to mind.

Greg

--=_alternative 00453CA28025699E_=-- From owner-ietf-calendar@mail.imc.org Wed Nov 22 05:28:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15494 for ; Wed, 22 Nov 2000 05:28:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA14892 for ietf-calendar-bks; Wed, 22 Nov 2000 01:57:26 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA14888 for ; Wed, 22 Nov 2000 01:57:23 -0800 (PST) Received: from metamatrix.se (dublin.metamatrix.se [193.14.119.156]) by ljudo.shortlist.se (Postfix) with ESMTP id 8092DB34FA; Wed, 22 Nov 2000 10:58:16 +0100 (CET) Message-ID: <3A1B98B7.54B416D1@metamatrix.se> Date: Wed, 22 Nov 2000 10:58:15 +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: pregen@egenconsulting.com Cc: Greg FitzPatrick , Ietf Subject: Re: SV: SV: SKiCal & Roles 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 ns.secondary.com id BAA14892 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA15494 pregen@egenconsulting.com wrote: > Greg, there could potentially be multiple drafts that occur that work > in conjunction with RFC 2445. An example that comes to mind is > RFC822. Many drafts reference it, but do not change what RFC 822 > stated. Nor was RFC 822 changed to work with the other drafts. > > I don't think it is appropriate in this case to change RFC 2445. I believe that Greg did not propose a change to 2445, but asked for advice on what parameter to use in the SKICal specification, which is a draft "that work in conjunction with RFC 2445". Just as you suggest above. Greg wrote in his original posting "We were in agreement that the only reason for adding three additional property parameters was to avoid conflict with 2445." The question is: Should the SKICal specification reuse ROLE, as defined in RFC2445, just as it reuses most of 2445, or should it define a new parameter DIPROLE which is a bit wider in value domain than ROLE? The question arises since the purpose of ROLE is "To specify the participation role for the calendar user specified by the property" (with typical values CHAIR, REQ-PARTICIPANT) while the need in a SKICal context is "To specify the participation role for a _person_ specified by the property" (with typical values "CONDUCTOR", "SOLOIST", "PRODUCER"...). regards, Pär > What > you requested is not a change to something "broken". If a draft does > have a flaw or is wrong, then it is appropriate to change it. I don't > see where your requested change is a "fix." > > Therefore, you need to follow a path of referencing RFC2445 and state > where your draft "enhances" or "extends" or some sort of language, the > RFC 2445 draft. It would be impossible to keep up a RFC if we had to > go and change it every time a new draft comes into play that uses or > references it.. Hope this helps with your thinking a bit. -- Pär Lannerö, Infostructure developer, Metamatrix AB, Stockholm Mail: Cellphone: +46 739 44 20 43 Work web: www.metamatrix.se Personal web: www.lannero.com/p/ From owner-ietf-calendar@mail.imc.org Fri Nov 24 19:43:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07353 for ; Fri, 24 Nov 2000 19:43:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA21154 for ietf-calendar-bks; Fri, 24 Nov 2000 16:26:50 -0800 (PST) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21147 for ; Fri, 24 Nov 2000 16:26:43 -0800 (PST) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: New drafts submitted X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Sat, 25 Nov 2000 00:27:38 +0000 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 11/24/2000 07:27:55 PM, Serialize complete at 11/24/2000 07:27:55 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006B0032802569A1_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B0032802569A1_= Content-Type: text/plain; charset="us-ascii" There have been new drafts submitted for CAP, iTIP, iMIP and the Implementors guide. If you want to view the drafts prior to their release by the Internet-Drafts list, use this url. http://www.egenconsulting.com/ietf/ietfdocs It has pointers to the text files as well as other documents of interest to CALSCH. --=_alternative 006B0032802569A1_= Content-Type: text/html; charset="us-ascii"
There have been new drafts submitted for CAP, iTIP, iMIP and the Implementors guide.  If you want to view the drafts prior to their release by the Internet-Drafts list, use this url. http://www.egenconsulting.com/ietf/ietfdocs
It has pointers to the text files as well as other documents of interest to CALSCH. --=_alternative 006B0032802569A1_=-- From owner-ietf-calendar@mail.imc.org Sun Nov 26 03:29:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05988 for ; Sun, 26 Nov 2000 03:29:37 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA10245 for ietf-calendar-bks; Sat, 25 Nov 2000 23:59:03 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA10234 for ; Sat, 25 Nov 2000 23:59:00 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA04026 for ietf-calendar@imc.org; Sun, 26 Nov 2000 00:00:03 -0800 (PST) Date: Sun, 26 Nov 2000 00:00:03 -0800 (PST) From: Doug Royer Message-Id: <200011260800.AAA04026@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 Nov 26 18:23:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22832 for ; Sun, 26 Nov 2000 18:23:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01352 for ietf-calendar-bks; Sun, 26 Nov 2000 15:00:56 -0800 (PST) Received: from mail4.svr.pol.co.uk (mail4.svr.pol.co.uk [195.92.193.211]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01348 for ; Sun, 26 Nov 2000 15:00:55 -0800 (PST) Received: from modem-108.coral-beauty.dialup.pol.co.uk ([62.136.252.108] helo=helixcode.com) by mail4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 140Anu-0001NC-00 for ietf-calendar@imc.org; Sun, 26 Nov 2000 23:02:07 +0000 Message-ID: <3A1EA4DE.4CCD09BF@helixcode.com> Date: Fri, 24 Nov 2000 17:26:54 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Another recurrence ambiguity 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 If you have a weekly RRULE what do you do if it has BYDAY=2TU ? Do you: a) Assume it is an invalid RRULE and skip the entire RRULE. b) forget the 2 since it isn't relevant and just assume 'Every Tuesday'. Damon From owner-ietf-calendar@mail.imc.org Mon Nov 27 11:57:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10481 for ; Mon, 27 Nov 2000 11:57:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13125 for ietf-calendar-bks; Mon, 27 Nov 2000 08:35:23 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13118 for ; Mon, 27 Nov 2000 08:35:21 -0800 (PST) From: Bruce_Kahn@iris.com To: svangasse@meetingmaker.com Cc: ietf-calendar@imc.org Subject: Re: DTSTART property in VTIMEZONE X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Mon, 27 Nov 2000 11:36:34 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/27/2000 11:36:44 AM, Serialize complete at 11/27/2000 11:36:44 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005B788F852569A4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B788F852569A4_= Content-Type: text/plain; charset="us-ascii" Doug Royer had started a side project to do this. Im not sure how far the effort has gone though. 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 005B788F852569A4_= Content-Type: text/html; charset="us-ascii"
Doug Royer had started a side project to do this.  Im not sure how far the effort has gone though.

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 005B788F852569A4_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 27 11:59:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11014 for ; Mon, 27 Nov 2000 11:59:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13327 for ietf-calendar-bks; Mon, 27 Nov 2000 08:40:07 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13323 for ; Mon, 27 Nov 2000 08:40:05 -0800 (PST) From: Bruce_Kahn@iris.com To: Martin Neimeier Cc: IETF-Calendar-Mailinglist Subject: Re: RRULE-Question X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Mon, 27 Nov 2000 11:41:18 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/27/2000 11:41:28 AM, Serialize complete at 11/27/2000 11:41:28 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005BE7EE852569A4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005BE7EE852569A4_= Content-Type: text/plain; charset="us-ascii" Martin asked: >How can I describe the Rule "the (first) sunday which is greater or equal >than the 9.th of october" I'd start w/the RRULE for the US Presidential farce, err, election from the RFC: DTSTART;TZID=US-Eastern:19961105T090000 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, 5,6,7,8 and then modify the RRULE to what you want. A first pass attempt I did came up with: DTSTART;TZID=US-Eastern:20001015T090000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=SU;BYMONTHDAY=9,10,11, 12,13,14,15 I think this fits your request... 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 005BE7EE852569A4_= Content-Type: text/html; charset="us-ascii"
Martin asked:
>How can I describe the Rule "the (first) sunday which is greater or equal
>than the 9.th of october"

I'd start w/the RRULE for the US Presidential farce, err, election from the RFC:

     DTSTART;TZID=US-Eastern:19961105T090000
    RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
     5,6,7,8

and then modify the RRULE to what you want.  A first pass attempt I did came up with:

     DTSTART;TZID=US-Eastern:20001015T090000
    RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=SU;BYMONTHDAY=9,10,11,
     12,13,14,15

I think this fits your request...

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 005BE7EE852569A4_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 27 12:24:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18044 for ; Mon, 27 Nov 2000 12:24:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA16383 for ietf-calendar-bks; Mon, 27 Nov 2000 09:08:15 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16375 for ; Mon, 27 Nov 2000 09:08:13 -0800 (PST) From: Bruce_Kahn@iris.com To: Damon Chaplin Cc: "ietf-calendar@imc.org" Subject: Re: Another recurrence ambiguity X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Mon, 27 Nov 2000 12:09:27 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/27/2000 12:09:36 PM, Serialize complete at 11/27/2000 12:09:36 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005E7B53852569A4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E7B53852569A4_= Content-Type: text/plain; charset="us-ascii" Damon asked: >If you have a weekly RRULE what do you do if it has BYDAY=2TU ? This is yet another of those "ya cant get there from here" illogical RRULEs that some of us raised a while ago. Im not sure what change Eric has made in the recurrence text but I know there was a proposal on the list to have text added that said in some form: "A recurrence rule MUST NOT have components that generate 'disjoint' subsets of one another. For example: BYMONTH=1, BYYEARDAY=155." The intent is to restrict what BYxxx may be used given the FREQ and INTERVAL values (and prior BYxxx values). 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 005E7B53852569A4_= Content-Type: text/html; charset="us-ascii"
Damon asked:
>If you have a weekly RRULE what do you do if it has BYDAY=2TU ?

This is yet another of those "ya cant get there from here" illogical RRULEs that some of us raised a while ago.  Im not sure what change Eric has made in the recurrence text but I know there was a proposal on the list to have text added that said in some form: "A recurrence rule MUST NOT have components that generate 'disjoint' subsets of one another.  For example: BYMONTH=1, BYYEARDAY=155."  The intent is to restrict what BYxxx may be used given the FREQ and INTERVAL values (and prior BYxxx values).

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 005E7B53852569A4_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 27 12:33:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22626 for ; Mon, 27 Nov 2000 12:33:22 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA15582 for ietf-calendar-bks; Mon, 27 Nov 2000 09:02:51 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15572 for ; Mon, 27 Nov 2000 09:02:48 -0800 (PST) From: Bruce_Kahn@iris.com To: sman@netscape.com (Steve Mansour) Cc: CalSched IETF Subject: Re: iTIP updates X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Mon, 27 Nov 2000 12:04:03 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/27/2000 12:04:12 PM, Serialize complete at 11/27/2000 12:04:12 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005DFCF4852569A4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DFCF4852569A4_= Content-Type: text/plain; charset="us-ascii" In going over the proposals from Steve again (thanks to a long weekend to decompress a bit) Im not so sure I like this one as it is described: Problem: Currently, the REQUEST method is used for invite, reschedule, update, confirm, reply to refresh. A reschedule and/or update are semantically different than a confirm or a reply to REFRESH. Proposal: Add a new method: CONFIRM. It would be used to (a) reply to a REFRESH and (b) notify participants of any changes to ATTENDEE or ORGANIZER. All other "reschedule" or "update" changes MUST use REQUEST method. The rub for me is partly in the new method name (CONFIRM) and in its use. The word CONFIRM has a pretty clear definition; the sender is confirming something. As such I would NOT see it as the logical name to use on a "reply to a REFRESH" (case (a) from above) or to send out 'non-rescheduling updates' as in case (b). I would expect it to be used as a special kind of notification to indicate that the Organizer is "confirming the entry" (ie: Pat confirms that the WG is meeting on Wed in San Diego). I also do not see why "All other [snip] "update" changes MUST use REQUEST" when CONFIRM exists (under a different name please) for that kind of need. Perhaps what we need some kind of "non-rescheduling update" method that we can send out. Although this change would kind of special case REQUESTs as being only when rescheduling is necessary and that is what we defined SEQUENCE changes for... Argh! I do NOT want to revisit that entire discussion again... WRT the "reply to a REFRESH" case, I would view this as the case where the process needs to be resync'd and can be done so by sending a new REQUEST to the requesting ATTENDEE. I am not convinced that REQUEST->REFRESH->REQUEST is not functioning and needs some fix. Perhaps someone can enlighten me. (Back when we first started this METHOD definition process I had a list of about 18-20 distinct values to use and they all got boiled down into the handfull we have now with meaning 'inferred from the content'. The pendulum seems to be swinging back now.) 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 005DFCF4852569A4_= Content-Type: text/html; charset="us-ascii"
In going over the proposals from Steve again (thanks to a long weekend to decompress a bit) Im not so sure I like this one as it is described:

Problem: Currently, the REQUEST method is used for invite, reschedule, update, confirm, reply to refresh. A reschedule and/or update are semantically different than a confirm or a reply to REFRESH.

Proposal: Add a new method: CONFIRM. It would be used to (a) reply to a REFRESH and (b) notify participants of any changes to ATTENDEE or ORGANIZER. All other "reschedule" or "update" changes MUST use REQUEST method.

The rub for me is partly in the new method name (CONFIRM) and in its use.  The word CONFIRM has a pretty clear definition; the sender is confirming something.  As such I would NOT see it as the logical name to use on a "reply to a REFRESH" (case (a) from above) or to send out 'non-rescheduling updates' as in case (b).  I would expect it to be used as a special kind of notification to indicate that the Organizer is "confirming the entry" (ie: Pat confirms that the WG is meeting on Wed in San Diego).

I also do not see why "All other [snip] "update" changes MUST use REQUEST" when CONFIRM exists (under a different name please) for that kind of need.  Perhaps what we need some kind of "non-rescheduling update" method that we can send out.  Although this change would kind of special case REQUESTs as being only when rescheduling is necessary and that is what we defined SEQUENCE changes for... Argh!   I do NOT want to revisit that entire discussion again...  

WRT the "reply to a REFRESH" case, I would view this as the case where the process needs to be resync'd and can be done so by sending a new REQUEST to the requesting ATTENDEE.  I am not convinced that REQUEST->REFRESH->REQUEST is not functioning and needs some fix.  Perhaps someone can enlighten me.

 (Back when we first started this METHOD definition process I had a list of about 18-20 distinct values to use and they all got boiled down into the handfull we have now with meaning 'inferred from the content'.  The pendulum seems to be swinging back now.)

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 005DFCF4852569A4_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 27 12:50:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01141 for ; Mon, 27 Nov 2000 12:50:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA17424 for ietf-calendar-bks; Mon, 27 Nov 2000 09:26:10 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17418 for ; Mon, 27 Nov 2000 09:26:09 -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 eARHJ6D09586 for ; Mon, 27 Nov 2000 09:19:06 -0800 (PST) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with ESMTP id G4P1SU00.1R1; Mon, 27 Nov 2000 09:26:54 -0800 Message-ID: <3A229932.54E5B372@netscape.com> Date: Mon, 27 Nov 2000 09:26:10 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: CalSched IETF Subject: Re: iTIP updates References: Content-Type: multipart/mixed; boundary="------------52438DECBB87DCD821CEA869" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------52438DECBB87DCD821CEA869 Content-Type: multipart/alternative; boundary="------------2108DD010852D80E73A0A340" --------------2108DD010852D80E73A0A340 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > In going over the proposals from Steve again (thanks to a long weekend > to decompress a bit) Im not so sure I like this one as it is > described: > > Problem: Currently, the REQUEST method is used for invite, reschedule, > update, confirm, reply to refresh. A reschedule and/or update are > semantically different than a confirm or a reply to REFRESH. > > Proposal: Add a new method: CONFIRM. It would be used to (a) reply to > a REFRESH and (b) notify participants of any changes to ATTENDEE or > ORGANIZER. All other "reschedule" or "update" changes MUST use REQUEST > method. > > The rub for me is partly in the new method name (CONFIRM) and in its > use. The word CONFIRM has a pretty clear definition; the sender is > confirming something. so, how does that conflict with its mission? Is it bothering you that the attendees can change and we're calling it a CONFIRM? Or that we don't bump the sequence number. Not bumping the sequence number is bothering me. I was going to bring this up in San Diego. > As such I would NOT see it as the logical name to use on a "reply to a > REFRESH" (case (a) from above) or to send out 'non-rescheduling > updates' as in case hmmm... "confirm" seems fine to me in this case. You have a better verb? > (b). I would expect it to be used as a special kind of notification > to indicate that the Organizer is "confirming the entry" (ie: Pat > confirms that the WG is meeting on Wed in San Diego). > I also do not see why "All other [snip] "update" changes MUST use > REQUEST" when CONFIRM exists (under a different name please) for that > kind of need. Perhaps what we need some kind of "non-rescheduling > update" method that we can send out. I think people wanted some command to reflect "non-substantive" changes to an event and everyone wants to minimize the number of commands. > Although this change would kind of special case REQUESTs as being only > when rescheduling is necessary and that is what we defined SEQUENCE > changes for... Argh! I do NOT want to revisit that entire discussion > again... I think we're going to have to open it up again. I think there are too many ambiguities with not bumping the sequence number as we modify the attendee list. > WRT the "reply to a REFRESH" case, I would view this as the case where > the process needs to be resync'd and can be done so by sending a new > REQUEST to the requesting ATTENDEE. I am not convinced that > REQUEST->REFRESH->REQUEST is not functioning and needs some fix. > Perhaps someone can enlighten me. It works just fine. I think people just wanted more insight as to the nature of the message. With REQUEST it could be rescheduled to a different time, etc. It could easily be argued that even a "CONFIRM" can result in the same sort of rescheduling -- for example if the attendee is a few revisions behind when they send the REFRESH -- the event start date/time could easily have been changed in one of the revisions they missed. So, there are certainly circumstances where CONFIRM must be handled like REFRESH. > (Back when we first started this METHOD definition process I had a > list of about 18-20 distinct values to use and they all got boiled > down into the handfull we have now with meaning 'inferred from the > content'. The pendulum seems to be swinging back now.) yea. ugh! I like fewer methods. -Steve --------------2108DD010852D80E73A0A340 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:
In going over the proposals from Steve again (thanks to a long weekend to decompress a bit) Im not so sure I like this one as it is described:

Problem: Currently, the REQUEST method is used for invite, reschedule, update, confirm, reply to refresh. A reschedule and/or update are semantically different than a confirm or a reply to REFRESH.

Proposal: Add a new method: CONFIRM. It would be used to (a) reply to a REFRESH and (b) notify participants of any changes to ATTENDEE or ORGANIZER. All other "reschedule" or "update" changes MUST use REQUEST method.

The rub for me is partly in the new method name (CONFIRM) and in its use.  The word CONFIRM has a pretty clear definition; the sender is confirming something.

so, how does that conflict with its mission?  Is it bothering you that the attendees can change and we're calling it a CONFIRM?  Or that we don't bump the sequence number.

Not bumping the sequence number is bothering me. I was going to bring this up in San Diego.

As such I would NOT see it as the logical name to use on a "reply to a REFRESH" (case (a) from above) or to send out 'non-rescheduling updates' as in case
hmmm... "confirm" seems fine to me in this case.  You have a better verb?
(b).  I would expect it to be used as a special kind of notification to indicate that the Organizer is "confirming the entry" (ie: Pat confirms that the WG is meeting on Wed in San Diego).
I also do not see why "All other [snip] "update" changes MUST use REQUEST" when CONFIRM exists (under a different name please) for that kind of need.  Perhaps what we need some kind of "non-rescheduling update" method that we can send out.
I think people wanted some command to reflect "non-substantive" changes to an event and everyone wants to minimize the number of commands.
Although this change would kind of special case REQUESTs as being only when rescheduling is necessary and that is what we defined SEQUENCE changes for... Argh!   I do NOT want to revisit that entire discussion again...
I think we're going to have to open it up again. I think there are too many ambiguities with not bumping the sequence number as we modify the attendee list.
WRT the "reply to a REFRESH" case, I would view this as the case where the process needs to be resync'd and can be done so by sending a new REQUEST to the requesting ATTENDEE.  I am not convinced that REQUEST->REFRESH->REQUEST is not functioning and needs some fix.  Perhaps someone can enlighten me.
It works just fine.

I think people just wanted more insight as to the nature of the message. With REQUEST it could be rescheduled to a different time, etc.  It could easily be argued that even a "CONFIRM" can result in the same sort of rescheduling -- for example if the attendee is a few revisions behind when they send the REFRESH -- the event start date/time could easily have been changed in one of the revisions they missed. So, there are certainly circumstances where CONFIRM must be handled like REFRESH.

 (Back when we first started this METHOD definition process I had a list of about 18-20 distinct values to use and they all got boiled down into the handfull we have now with meaning 'inferred from the content'.  The pendulum seems to be swinging back now.)
yea.  ugh!  I like fewer methods.

-Steve --------------2108DD010852D80E73A0A340-- --------------52438DECBB87DCD821CEA869 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 --------------52438DECBB87DCD821CEA869-- From owner-ietf-calendar@mail.imc.org Mon Nov 27 13:14:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11106 for ; Mon, 27 Nov 2000 13:14:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18968 for ietf-calendar-bks; Mon, 27 Nov 2000 09:53:36 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18964 for ; Mon, 27 Nov 2000 09:53:35 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eARHwrC00708 for ; Mon, 27 Nov 2000 12:58:53 -0500 Message-ID: <3A22A0DC.ED694241@ecal.com> Date: Mon, 27 Nov 2000 12:58:52 -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: CalSched IETF Subject: Re: iTIP updates References: <3A229932.54E5B372@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: > Bruce_Kahn@iris.com wrote: > >> Although this change would kind of special case REQUESTs as >> being only when rescheduling is necessary and that is what we >> defined SEQUENCE changes for... Argh! I do NOT want to >> revisit that entire discussion again... > > I think we're going to have to open it up again. I think there > are too many ambiguities with not bumping the sequence number > as we modify the attendee list. [...] > yea. ugh! I like fewer methods. So maybe all we need to do is widen the cases where we increase the sequence number, but not add new methods? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Excuse me. I've been dead lately & my brain | |francis@ecal.com|isn't working too well. --Miles Vorkosigan | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 27 13:19:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13316 for ; Mon, 27 Nov 2000 13:19:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19159 for ietf-calendar-bks; Mon, 27 Nov 2000 09:57:14 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19152 for ; Mon, 27 Nov 2000 09:57:13 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eARI2XC00720 for ; Mon, 27 Nov 2000 13:02:33 -0500 Message-ID: <3A22A1B9.3A3D07A2@ecal.com> Date: Mon, 27 Nov 2000 13:02: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: Another recurrence ambiguity 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: > there was a proposal on the list to have text added that said > in some form: "A recurrence rule MUST NOT have components that > generate 'disjoint' subsets of one another. For example: > BYMONTH=1, BYYEARDAY=155." The intent is to restrict what > BYxxx may be used given the FREQ and INTERVAL values (and prior > BYxxx values). Of course, if you do get an event with an inconsistent RRULE, then the meaning is obvious: the set of recurrences is empty (it's the intersection of two disjoint sets), so the event never repeats. So the VCALENDAR is clear and unambiguous. It just happens to be useless. :-) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Excuse me. I've been dead lately & my brain | |francis@ecal.com|isn't working too well. --Miles Vorkosigan | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 27 13:53:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26701 for ; Mon, 27 Nov 2000 13:53:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20186 for ietf-calendar-bks; Mon, 27 Nov 2000 10:33:44 -0800 (PST) Received: from office.jigzaw.com ([63.144.102.109]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20181 for ; Mon, 27 Nov 2000 10:33:42 -0800 (PST) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA11765 for ; Mon, 27 Nov 2000 12:20:44 -0600 From: "Shannon J. Clark" To: Subject: Typos in CAP documents, a question about CAP example, and some general questions Date: Mon, 27 Nov 2000 12:34:03 -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 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 Hi, While reviewing the CAP documents from the website, admittedly the now expired ones, I found the following items. First some minor typos, hopefully have been fixed in the next version. One. p42, last paragraph. "The responce returns the calendar (CALID) and UID of the component so that the CUA can match up the REQUEST-STATUS from multiple objects created on multiple calendards (TARGETS)." shouldn't that be "response" and "calendars"? Two. 50, first paragraph of 7.2.2.1. has "invided" which I suspect should be "invited". In general it appears that a run through a spell checker might be in order. Also I have noticed some inconsistencies in clearly differentiating between "MUST" "SHOULD" and "MAY" in some sections, with "must" being used in some places, and some sentences using "may not" which is somewhat ambiguous. Also, has anyone had success in printing out RFC's in a manner that achieves the same pagination as they are numbered? Is there a particular font that is required to be used? Second, a request for clarification on one of the examples. On page 44, bottom of page (part of 7.2.1.4 MODIFY) the example states that "And in this example, all instances of "Building 6" are replaced by "New office lobby" in VEVENTs: Could someone explain to my how the syntax achieves this? From reading it appears to only achieve a change of the LOCATION field from "Building 6" to "New Office Lobby". From what I can tell if the string "Building 6" is elsewhere in the VEVENTs (say in the DESCRIPTION nothing in this syntax appears to change that string. Also, it appears to require that LOCATION is exactly eq to "Building 6", what is the correct behavior if this is not the case? (say Location is "building 6" which according to the specs should be considered differently since values are supposed to be case sensitive. Does additional non-printing characters effect this equality? (for ex. the CR vs. CR/LF issues of PC to Unix or PC to Mac) thanks, I am sure that as I continue to delve into these specs I will have additional questions for the group. Shannon Shannon J. Clark CEO - JigZaw, Inc shannon@jigzaw.com www.jigzaw.com From owner-ietf-calendar@mail.imc.org Mon Nov 27 13:54:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27012 for ; Mon, 27 Nov 2000 13:54:36 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA20202 for ietf-calendar-bks; Mon, 27 Nov 2000 10:34:24 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20198 for ; Mon, 27 Nov 2000 10:34:21 -0800 (PST) From: Bruce_Kahn@iris.com To: John Stracke Cc: "ietf-calendar@imc.org" Subject: Re: Another recurrence ambiguity X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Mon, 27 Nov 2000 13:34:57 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/27/2000 01:35:45 PM, Serialize complete at 11/27/2000 01:35:45 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00665F1F852569A4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00665F1F852569A4_= Content-Type: text/plain; charset="us-ascii" John replied with: >Of course, if you do get an event with an inconsistent RRULE, >then the meaning is obvious: the set of recurrences is empty >(it's the intersection of two disjoint sets) Well, the RFC never talks about intersecting anything and it never expressly precludes non-sensical rules like the one I gave (an oversight we will fix). We (Eric) were going to clarify the recurrence rule text so that it expressly describes evaluating the BYxxx parts (not JUST their order of evaluation) and put some text that precludes mixing and matching of values that can be 'disjoint'. Since you have a concept of intersecting data sets perhaps you can give Eric some text to include. I do agree that most CUAs will ignore the RRULE (and send the proper REQUEST-STATUS to indicate this I _hope_!!) but not all CUAs agree on when to do this. Some of the less robust engines may treat bogus rules the same as ones they 'dont quite handle' even though they are different causes. Im sure the various ideas will come to light at the next CalConnect but given the time till then and the traffic it will generate afterwards I think we can start codifying a more generally accepted understanding before then to progress the work along now. Dont you? 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 00665F1F852569A4_= Content-Type: text/html; charset="us-ascii"
John replied with:
>Of course, if you do get an event with an inconsistent RRULE,
>then the meaning is obvious: the set of recurrences is empty
>(it's the intersection of two disjoint sets)

Well, the RFC never talks about intersecting anything and it never expressly precludes non-sensical rules like the one I gave (an oversight we will fix).  We (Eric) were going to clarify the recurrence rule text so that it expressly describes evaluating the BYxxx parts (not JUST their order of evaluation) and put some text that precludes mixing and matching of values that can be 'disjoint'.  Since you have a concept of intersecting data sets perhaps you can give Eric some text to include.

I do agree that most CUAs will ignore the RRULE (and send the proper REQUEST-STATUS to indicate this I _hope_!!) but not all CUAs agree on when to do this.  Some of the less robust engines may treat bogus rules the same as ones they 'dont quite handle' even though they are different causes.

Im sure the various ideas will come to light at the next CalConnect but given the time till then and the traffic it will generate afterwards I think we can start codifying a more generally accepted understanding before then to progress the work along now.  Dont you?

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 00665F1F852569A4_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 27 14:23:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06812 for ; Mon, 27 Nov 2000 14:23:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA23403 for ietf-calendar-bks; Mon, 27 Nov 2000 11:03:56 -0800 (PST) Received: from guanabana.helixcode.com (IDENT:root@[132.248.10.187]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23395 for ; Mon, 27 Nov 2000 11:03:54 -0800 (PST) Received: (from federico@localhost) by guanabana.helixcode.com (8.9.3/8.9.3) id NAA12374; Mon, 27 Nov 2000 13:12:48 -0600 Date: Mon, 27 Nov 2000 13:12:48 -0600 Message-Id: <200011271912.NAA12374@guanabana.helixcode.com> X-Authentication-Warning: guanabana.helixcode.com: federico set sender to federico@helixcode.com using -f From: Federico Mena Quintero X-Homer: I thought there was chocolate inside ... Well, why was it wrapped in foil? To: ietf-calendar@imc.org Subject: Re: Another recurrence ambiguity References: <3A22A1B9.3A3D07A2@ecal.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Stracke writes: > Of course, if you do get an event with an inconsistent RRULE, > then the meaning is obvious: the set of recurrences is empty > (it's the intersection of two disjoint sets), so the event never > repeats. So the VCALENDAR is clear and unambiguous. It just > happens to be useless. :-) Which is another thing that begs the question: has anyone ever even considered how to make a good user interface to specify all of iCalendar's recurrence rules? In the Evolution calendar we support only very simple rules, similar to the ones in the Palm Pilot's calendar program. These seem to be what people use most of the time; we can load and display iCalendar exotica but not edit them. Federico From owner-ietf-calendar@mail.imc.org Mon Nov 27 14:23:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07109 for ; Mon, 27 Nov 2000 14:23:56 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA23446 for ietf-calendar-bks; Mon, 27 Nov 2000 11:04:45 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23442 for ; Mon, 27 Nov 2000 11: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 eARIvgD00896; Mon, 27 Nov 2000 10:57:42 -0800 (PST) Received: from netscape.com (h-192-18-125-198.red.iplanet.com [192.18.125.198]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id LAA3906064; Mon, 27 Nov 2000 11:12:08 -0800 (PST) Message-ID: <3A22B0C1.21ACC7B6@netscape.com> Date: Mon, 27 Nov 2000 11:06:41 -0800 From: Steve Mansour X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: CalSched IETF Subject: Re: iTIP updates References: <3A229932.54E5B372@netscape.com> <3A22A0DC.ED694241@ecal.com> Content-Type: multipart/mixed; boundary="------------28EC08C0EFD508100986203D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------28EC08C0EFD508100986203D Content-Type: multipart/alternative; boundary="------------273D8E9CB8278DE860224DAE" --------------273D8E9CB8278DE860224DAE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > Steve Mansour wrote: > > > Bruce_Kahn@iris.com wrote: > > > >> Although this change would kind of special case REQUESTs as > >> being only when rescheduling is necessary and that is what we > >> defined SEQUENCE changes for... Argh! I do NOT want to > >> revisit that entire discussion again... > > > > I think we're going to have to open it up again. I think there > > are too many ambiguities with not bumping the sequence number > > as we modify the attendee list. > > [...] > > > yea. ugh! I like fewer methods. > > So maybe all we need to do is widen the cases where we increase > the sequence number, but not add new methods? could those who pushed for the "CONFIRM" method please chime in here and help us understand the need better. Here is what I recall: * people felt the REQUEST method was inappropriate for an organizer sending out an updated version of an event with people's attendee status updated * people felt that REQUEST was not a good verb to use as a response to a REFRESH I'm probably not representing everything here. -Steve --------------273D8E9CB8278DE860224DAE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote:

Steve Mansour wrote:

> Bruce_Kahn@iris.com wrote:
>
>> Although this change would kind of special case REQUESTs as
>> being only when rescheduling is necessary and that is what we
>> defined SEQUENCE changes for... Argh!   I do NOT want to
>> revisit that entire discussion again...
>
> I think we're going to have to open it up again. I think there
> are too many ambiguities with not bumping the sequence number
> as we modify the attendee list.

[...]

> yea.  ugh!  I like fewer methods.

So maybe all we need to do is widen the cases where we increase
the sequence number, but not add new methods?

could those who pushed for the "CONFIRM" method please chime in here and help us understand the need better.  Here is what I recall:
  • people felt the REQUEST method was inappropriate for an organizer sending out an updated version of an event with people's attendee status updated
  • people felt that REQUEST was not a good verb to use as a response to a REFRESH
I'm probably not representing everything here.

-Steve --------------273D8E9CB8278DE860224DAE-- --------------28EC08C0EFD508100986203D 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;work:650-937-2378 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------28EC08C0EFD508100986203D-- From owner-ietf-calendar@mail.imc.org Mon Nov 27 15:19:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24336 for ; Mon, 27 Nov 2000 15:19:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA27290 for ietf-calendar-bks; Mon, 27 Nov 2000 11:47:04 -0800 (PST) Received: from agony.busboom.org (24-25-197-23.san.rr.com [24.25.197.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27284 for ; Mon, 27 Nov 2000 11:47:02 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id LAA06287; Mon, 27 Nov 2000 11:47:51 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 27 Nov 2000 11:47:51 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: Bruce_Kahn@iris.com cc: John Stracke , "ietf-calendar@imc.org" Subject: Re: Another recurrence ambiguity 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 Mon, 27 Nov 2000 Bruce_Kahn@iris.com wrote: > Well, the RFC never talks about intersecting anything and it never > expressly precludes non-sensical rules like the one I gave (an oversight > we will fix). We (Eric) were going to clarify the recurrence rule text so > that it expressly describes evaluating the BYxxx parts (not JUST their The text I proposed is at: http://www.imc.org/ietf-calendar/mail-archive/msg04779.html ( Comments Please! This is an outstanding issue that has not reached consensus. ) The proposed text would not cover this current issue, though. > I do agree that most CUAs will ignore the RRULE (and send the proper > REQUEST-STATUS to indicate this I _hope_!!) but not all CUAs agree on when > to do this. Some of the less robust engines may treat bogus rules the > same as ones they 'dont quite handle' even though they are different > causes. I think this is the primary problem with the current RRULE spec. There are no details for handling these invalid cases, so the only CUAs that will ignore the rule are those whose designers caught the discrepancy. This means that there is no hope of interoperability on these fringe cases. So, if we are going to fix this, you ( yes, you, Damon, John and Bruce ) need to review the proposed text referenced above or propose some text of your own. For the current issue, "FREQ=WEEKLY;BYDAY=2TU" can we declare it to be invalid? How about something like For FREQ=WEEKLY, BYDAY rule parts MUST have integer values of 1, or the interger value MUST be omitted. "FREQ=WEEKLY;BYDAY=TU" is valid, but "FREQ=WEEKLY;BYDAY=2TU" is not. eric. From owner-ietf-calendar@mail.imc.org Mon Nov 27 15:28:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26505 for ; Mon, 27 Nov 2000 15:28:09 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA28615 for ietf-calendar-bks; Mon, 27 Nov 2000 12:09:09 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28609 for ; Mon, 27 Nov 2000 12:09:08 -0800 (PST) From: Bruce_Kahn@iris.com To: John Stracke Cc: CalSched IETF Subject: Re: iTIP updates X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Mon, 27 Nov 2000 15:10:18 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/27/2000 03:10:32 PM, Serialize complete at 11/27/2000 03:10:32 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006F0AFB852569A4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F0AFB852569A4_= Content-Type: text/plain; charset="us-ascii" John suggested: >So maybe all we need to do is widen the cases where we increase >the sequence number, but not add new methods? It would greatly help this discussion if those that had issues/concerns/solutions could post them to the list so that everyone can mull them over. Preferably BEFORE San Diego since Im betting this is gonna take up some big chunk of time to cover. Sounds like John has some ideas... 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 006F0AFB852569A4_= Content-Type: text/html; charset="us-ascii"
John suggested:
>So maybe all we need to do is widen the cases where we increase
>the sequence number, but not add new methods?

It would greatly help this discussion if those that had issues/concerns/solutions could post them to the list so that everyone can mull them over.  Preferably BEFORE San Diego since Im betting this is gonna take up some big chunk of time to cover.

Sounds like John has some ideas...

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 006F0AFB852569A4_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 27 15:33:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27842 for ; Mon, 27 Nov 2000 15:33:58 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA28553 for ietf-calendar-bks; Mon, 27 Nov 2000 12:07:54 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28548 for ; Mon, 27 Nov 2000 12:07:49 -0800 (PST) From: Bruce_Kahn@iris.com To: sman@netscape.com (Steve Mansour) Cc: CalSched IETF Subject: Re: iTIP updates X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Mon, 27 Nov 2000 15:07:19 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/27/2000 03:09:14 PM, Serialize complete at 11/27/2000 03:09:14 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006EC4E4852569A4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006EC4E4852569A4_= Content-Type: text/plain; charset="us-ascii" I can see that this is gonna take some group bandwidth again... Im on a timeline before San Diego so Ill try to keep my points short and sweet (stop chuckling!!) Steve replied: >>The word CONFIRM has a pretty clear definition; the sender is confirming something. >so, how does that conflict with its mission? The act of confirming the entry is not the same as expressed in the original (a) and (b) cases. See my last msg on this. >Not bumping the sequence number is bothering me. I was going to bring this up in San Diego. ARRRRGH! Isnt this the 15th time we've gone over reving SEQUENCE??? Before going down that rat hole, can you please explain _why_ the Organizer _needs_ to rev SEQUENCE when they are simply indicating to invitees "Yes, we are going to meet tomorrow AM"?? Doing so would invalidate any REPLYs that come in after that when NOTHING has changed?? Now, if this is an internal architecture issue for your engine thats a different matter than a problem in the RFC. (Recall that MSFT was going to rev SEQUENCE on every notice sent out even typo changes in a SUMMARY and that IS OK, it just increases their message traffic.) >>As such I would NOT see it as the logical name to use on a "reply to >>a REFRESH" (case (a) from above) or to send out 'non-rescheduling >>updates' as in case >hmmm... "confirm" seems fine to me in this case. You have a better verb? Reread my original comments again please. If the Organzier is just fixing a typo in SUMMARY (ie: the (b) or "non-rescheduling update' case) then how is it a CONFIRMation in the sense that I confirm we are going to meet?? Its not the same. I said that my disagreement is partly w/the choice of words for the given objective. >I think people wanted some command to reflect "non-substantive" changes to an event and everyone wants to minimize the number of commands. Currently this is done by using the (UID, SEQUENCE, DTSTAMP) tuple and sending 'full snapshots' of the entry in question. If, for the given UID, the SEQUENCE is the same as the recipients but the DTSTAMP is 'newer' then its a non-rescheduling update. The _exact_ kind of update is not clear (ie: STATUS:TENTATIVE -> STATUS:CONFIRMED means the entry was "confirmed", new ATTENDEEs means new folks were added, etc.) and I think this is what you are trying to 'fix' with a new method. This is change in methodology and not a simple semantic change!! If, for the given UID, the SEQUENCE is smaller then the recipients then its a stale update/request and is to be ignored. If, for the given UID, the SEQUENCE is higher than the recipients then the message is a rescheduling update of some kind. That is NOT to preclude that the real difference between the recipients copy and the new one is simply a typo change for, say, SUMMARY but any REPLYs that the recipient sends to the Organizer w/the older SEQUENCE value will be ignored (and possibly trigger a new REQUEST to be sent out). >>Although this change would kind of special case REQUESTs as being only >>when rescheduling is necessary and that is what we defined SEQUENCE >>changes for... Argh! I do NOT want to revisit that entire discussion >>again... >I think we're going to have to open it up again. I think there are too many ambiguities with not bumping the sequence number as we modify the attendee list. Well Hoss, I think this should top our Agenda for San Diego then. This kind of change is definitely non-trivial and a non-backwards compat. change for reasons that have not been clearly given yet. In order for there to be some productive coverage of this I would strongly suggest you post to the list your motivation for such a change. >>WRT the "reply to a REFRESH" case, I would view this as the case where >>the process needs to be resync'd and can be done so by sending a new >>REQUEST to the requesting ATTENDEE. I am not convinced that >>REQUEST->REFRESH->REQUEST is not functioning and needs some fix. >>Perhaps someone can enlighten me. >It works just fine. Well that was the (a) case for having CONFIRM added. If the process works as it stands, case (a) is not a valid case for the change. >yea. ugh! I like fewer methods. At least I can end on a point of agreement. :^) 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 006EC4E4852569A4_= Content-Type: text/html; charset="us-ascii"
I can see that this is gonna take some group bandwidth again...  Im on a timeline before San Diego so Ill try to keep my points short and sweet (stop chuckling!!)

Steve replied:
>>The word CONFIRM has a pretty clear definition; the sender is confirming something.
>so, how does that conflict with its mission?

The act of confirming the entry is not the same as expressed in the original (a) and (b) cases.  See my last msg on this.

>Not bumping the sequence number is bothering me. I was going to bring this up in San Diego.

ARRRRGH!  Isnt this the 15th time we've gone over reving SEQUENCE???  Before going down that rat hole, can you please explain _why_ the Organizer _needs_ to rev SEQUENCE when they are simply indicating to invitees "Yes, we are going to meet tomorrow AM"??  Doing so would invalidate any REPLYs that come in after that when NOTHING has changed??  

Now, if this is an internal architecture issue for your engine thats a different matter than a problem in the RFC.  (Recall that MSFT was going to rev SEQUENCE on every notice sent out even typo changes in a SUMMARY and that IS OK, it just increases their message traffic.)

>>As such I would NOT see it as the logical name to use on a "reply to
>>a REFRESH" (case (a) from above) or to send out 'non-rescheduling
>>updates' as in case
>hmmm... "confirm" seems fine to me in this case.  You have a better verb?

Reread my original comments again please.  If the Organzier is just fixing a typo in SUMMARY (ie: the (b) or "non-rescheduling update' case) then how is it a CONFIRMation in the sense that I confirm we are going to meet??  Its not the same.  I said that my disagreement is partly w/the choice of words for the given objective.    

>I think people wanted some command to reflect "non-substantive" changes to an event and everyone wants to minimize the number of commands.

Currently this is done by using the  (UID, SEQUENCE, DTSTAMP) tuple and sending 'full snapshots' of the entry in question.  If, for the given UID, the SEQUENCE is the same as the recipients but the DTSTAMP is 'newer' then its a non-rescheduling update.  The _exact_ kind of update is not clear (ie: STATUS:TENTATIVE -> STATUS:CONFIRMED means the entry was "confirmed", new ATTENDEEs means new folks were added, etc.) and I think this is what you are trying to 'fix' with a new method.  This is change in methodology and not a simple semantic change!!

If, for the given UID, the SEQUENCE is smaller then the recipients then its a stale update/request and is to be ignored.  If, for the given UID, the SEQUENCE is higher than the recipients then the message is a rescheduling update of some kind.  That is NOT to preclude that the real difference between the recipients copy and the new one is simply a typo change for, say, SUMMARY but any REPLYs that the recipient sends to the Organizer w/the older SEQUENCE value will be ignored (and possibly trigger a new REQUEST to be sent out).

>>Although this change would kind of special case REQUESTs as being only
>>when rescheduling is necessary and that is what we defined SEQUENCE
>>changes for... Argh!   I do NOT want to revisit that entire discussion
>>again...
>I think we're going to have to open it up again. I think there are too many ambiguities with not bumping the sequence number as we modify the attendee list.

Well Hoss, I think this should top our Agenda for San Diego then.  This kind of change is definitely non-trivial and a non-backwards compat. change for reasons that have not been clearly given yet.  In order for there to be some productive coverage of this I would strongly suggest you post to the list your motivation for such a change.

>>WRT the "reply to a REFRESH" case, I would view this as the case where
>>the process needs to be resync'd and can be done so by sending a new
>>REQUEST to the requesting ATTENDEE.  I am not convinced that
>>REQUEST->REFRESH->REQUEST is not functioning and needs some fix.  
>>Perhaps someone can enlighten me.
>It works just fine.

Well that was the (a) case for having CONFIRM added.  If the process works as it stands, case (a) is not a valid case for the change.

>yea.  ugh!  I like fewer methods.

At least I can end on a point of agreement. :^)

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 006EC4E4852569A4_=-- From owner-ietf-calendar@mail.imc.org Mon Nov 27 16:00:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04040 for ; Mon, 27 Nov 2000 15:59:59 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00304 for ietf-calendar-bks; Mon, 27 Nov 2000 12:43:22 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00298 for ; Mon, 27 Nov 2000 12:43:16 -0800 (PST) From: robert_ransdell@iris.com Subject: Recur rules --- just to make things absolutely clear To: ietf-calendar@imc.org X-Mailer: Lotus Notes Build V60_09102000 September 10, 2000 Message-ID: Date: Mon, 27 Nov 2000 15:44:26 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/27/2000 03:44:41 PM 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: The general rule for recurrence set is "byrule parts for a period of time less than the frequency generally increase the number of occurrences". I believe it should be clearly stated below this paragraph the If you have both "BYYEARDAY and BYDAY" or "BYMONTHDAY and BYDAY" that they must be examined as a set ie BYMONTH=11;BYMONTHDAY=2,3,4,5,6,7,8;BYDAY=TU DOES NOT GENERATE all the Tuesdays in November plus days 2,3,4,5,6,7,8 but the Tuesday that falls on one of the days 2,3,4,5,6,7 From owner-ietf-calendar@mail.imc.org Mon Nov 27 16:48:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15861 for ; Mon, 27 Nov 2000 16:48:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02850 for ietf-calendar-bks; Mon, 27 Nov 2000 13:17:01 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02846 for ; Mon, 27 Nov 2000 13:16:59 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eARLMJC01400 for ; Mon, 27 Nov 2000 16:22:20 -0500 Message-ID: <3A22D08B.F828213D@ecal.com> Date: Mon, 27 Nov 2000 16:22:19 -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: CalSched IETF Subject: Re: iTIP updates 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: > John suggested: > >So maybe all we need to do is widen the cases where we > increase > >the sequence number, but not add new methods? > > It would greatly help this discussion if those that had > issues/concerns/solutions could post them to the list so that > everyone can mull them over. Preferably BEFORE San Diego since > Im betting this is gonna take up some big chunk of time to > cover. > > Sounds like John has some ideas... Not specifically; I was just trying to offer a middle path. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Never mind the GUIs--Unix won't be for the | |francis@ecal.com|masses until we fix backspace & delete. | \==============================================================/ From owner-ietf-calendar@mail.imc.org Mon Nov 27 18:09:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13302 for ; Mon, 27 Nov 2000 18:09:28 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA06300 for ietf-calendar-bks; Mon, 27 Nov 2000 14:46:34 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06296 for ; Mon, 27 Nov 2000 14:46:33 -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 eARMYds16744; Mon, 27 Nov 2000 14:34:40 -0800 (PST) Received: from netscape.com (h-192-18-125-198.red.iplanet.com [192.18.125.198]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id OAA3902518; Mon, 27 Nov 2000 14:53:58 -0800 (PST) Message-ID: <3A22E4BE.F4B15BF0@netscape.com> Date: Mon, 27 Nov 2000 14:48:30 -0800 From: Steve Mansour X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: CalSched IETF Subject: Re: iTIP updates References: Content-Type: multipart/mixed; boundary="------------9176526BF555325D5C0915D2" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9176526BF555325D5C0915D2 Content-Type: multipart/alternative; boundary="------------9C708ED8132DB5D5754609D1" --------------9C708ED8132DB5D5754609D1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > I can see that this is gonna take some group bandwidth again... Im on > a timeline before San Diego so Ill try to keep my points short and > sweet (stop chuckling!!) > > Steve replied: > >>The word CONFIRM has a pretty clear definition; the sender is > confirming something. > >so, how does that conflict with its mission? > > The act of confirming the entry is not the same as expressed in the > original (a) and (b) cases. See my last msg on this. > > >Not bumping the sequence number is bothering me. I was going to bring > this up in San Diego. > > ARRRRGH! Isnt this the 15th time we've gone over reving SEQUENCE??? > Before going down that rat hole, can you please explain _why_ the > Organizer _needs_ to rev SEQUENCE when they are simply indicating to > invitees "Yes, we are going to meet tomorrow AM"?? Doing so would > invalidate any REPLYs that come in after that when NOTHING has > changed?? > > Now, if this is an internal architecture issue for your engine thats a > different matter than a problem in the RFC. (Recall that MSFT was > going to rev SEQUENCE on every notice sent out even typo changes in a > SUMMARY and that IS OK, it just increases their message traffic.) No, I'm referring specifically to the change where we add people to or remove them from the recipient list. If we don't bump the sequence number, then you and I can have an event with the same UID and the same SEQUENCE but different attendee lists. That just seems wrong. > >>As such I would NOT see it as the logical name to use on a "reply to > > >>a REFRESH" (case (a) from above) or to send out 'non-rescheduling > >>updates' as in case > >hmmm... "confirm" seems fine to me in this case. You have a better > verb? > > Reread my original comments again please. If the Organzier is just > fixing a typo in SUMMARY (ie: the (b) or "non-rescheduling update' > case) then how is it a CONFIRMation in the sense that I confirm we are > going to meet?? Its not the same. I said that my disagreement is > partly w/the choice of words for the given objective. I'm not worried about the case where we're just fixing a typo in the SUMMARY. > >I think people wanted some command to reflect "non-substantive" > changes to an event and everyone wants to minimize the number of > commands. > > Currently this is done by using the (UID, SEQUENCE, DTSTAMP) tuple > and sending 'full snapshots' of the entry in question. If, for the > given UID, the SEQUENCE is the same as the recipients but the DTSTAMP > is 'newer' then its a non-rescheduling update. The _exact_ kind of > update is not clear (ie: STATUS:TENTATIVE -> STATUS:CONFIRMED means > the entry was "confirmed", new ATTENDEEs means new folks were added, > etc.) and I think this is what you are trying to 'fix' with a new > method. This is change in methodology and not a simple semantic > change!! For typos, I agree. When the attendee list changes it seems like a different deal. I don't think throwing in the DTSTAMP helps my concern in this case. Because that value is generated at the time a message is sent. Messages can be sent for a variety of reasons, including REFRESH. So, the DTSTAMP time can potentially different for everyone in the event. The UID and SEQUENCE number seem like the things to rely on for determining if we're all talking about the same meeting. Maybe the problem just comes from where we draw the line on what constitutes a substantive change. I agree with you on typos. I'm not so sure about a change to the attendee list. -Steve --------------9C708ED8132DB5D5754609D1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:

I can see that this is gonna take some group bandwidth again...  Im on a timeline before San Diego so Ill try to keep my points short and sweet (stop chuckling!!)

Steve replied:
>>The word CONFIRM has a pretty clear definition; the sender is confirming something.
>so, how does that conflict with its mission?

The act of confirming the entry is not the same as expressed in the original (a) and (b) cases.  See my last msg on this.

>Not bumping the sequence number is bothering me. I was going to bring this up in San Diego.

ARRRRGH!  Isnt this the 15th time we've gone over reving SEQUENCE???  Before going down that rat hole, can you please explain _why_ the Organizer _needs_ to rev SEQUENCE when they are simply indicating to invitees "Yes, we are going to meet tomorrow AM"??  Doing so would invalidate any REPLYs that come in after that when NOTHING has changed??

Now, if this is an internal architecture issue for your engine thats a different matter than a problem in the RFC.  (Recall that MSFT was going to rev SEQUENCE on every notice sent out even typo changes in a SUMMARY and that IS OK, it just increases their message traffic.)

No, I'm referring specifically to the change where we add people to or remove them from the recipient list. If we don't bump the sequence number, then you and I can have an event with the same UID and the same SEQUENCE but different attendee lists. That just seems wrong.
>>As such I would NOT see it as the logical name to use on a "reply to
>>a REFRESH" (case (a) from above) or to send out 'non-rescheduling
>>updates' as in case
>hmmm... "confirm" seems fine to me in this case.  You have a better verb?

Reread my original comments again please.  If the Organzier is just fixing a typo in SUMMARY (ie: the (b) or "non-rescheduling update' case) then how is it a CONFIRMation in the sense that I confirm we are going to meet??  Its not the same.  I said that my disagreement is partly w/the choice of words for the given objective.

I'm not worried about the case where we're just fixing a typo in the SUMMARY.
>I think people wanted some command to reflect "non-substantive" changes to an event and everyone wants to minimize the number of commands.

Currently this is done by using the  (UID, SEQUENCE, DTSTAMP) tuple and sending 'full snapshots' of the entry in question.  If, for the given UID, the SEQUENCE is the same as the recipients but the DTSTAMP is 'newer' then its a non-rescheduling update.  The _exact_ kind of update is not clear (ie: STATUS:TENTATIVE -> STATUS:CONFIRMED means the entry was "confirmed", new ATTENDEEs means new folks were added, etc.) and I think this is what you are trying to 'fix' with a new method.  This is change in methodology and not a simple semantic change!!

For typos, I agree. When the attendee list changes it seems like a different deal. I don't think throwing in the DTSTAMP helps my concern in this case. Because that value is generated at the time a message is sent. Messages can be sent for a variety of reasons, including REFRESH.  So, the DTSTAMP time can potentially different for everyone in the event. The UID and SEQUENCE number seem like the things to rely on for determining if we're all talking about the same meeting.

Maybe the problem just comes from where we draw the line on  what constitutes a substantive change. I agree with you on typos.  I'm not so sure about a change to the attendee list.

-Steve
  --------------9C708ED8132DB5D5754609D1-- --------------9176526BF555325D5C0915D2 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;work:650-937-2378 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------9176526BF555325D5C0915D2-- From owner-ietf-calendar@mail.imc.org Tue Nov 28 06:24:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15889 for ; Tue, 28 Nov 2000 06:24:26 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA13928 for ietf-calendar-bks; Tue, 28 Nov 2000 02:54:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA13920 for ; Tue, 28 Nov 2000 02:54:57 -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 FAA01939; Tue, 28 Nov 2000 05:56:20 -0500 (EST) Message-Id: <200011281056.FAA01939@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-capreq-04.txt Date: Tue, 28 Nov 2000 05:56:20 -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 : CAP Requirements Author(s) : A. Courtemanche, F. Dawson Jr., S. Mansour, P. O'Leary, D. Royer, T. Small Filename : draft-ietf-calsch-capreq-04.txt Pages : 23 Date : 27-Nov-00 The Calendar Access Protocol (CAP) is an Internet protocol for accessing an [ICAL] based calendar store (CS) from a calendar user agent (CUA). The purpose of this document is to set forth a list of requirements that CAP MUST address in order to meet the needs of the calendaring and scheduling community. This document is based on discussions within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. Distribution of this document is unlimited. Comments and suggestions for improvement should be sent to the authors. Copyright (C) The Internet Society 1998. All Rights Reserved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-capreq-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-capreq-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-capreq-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: <20001127132354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-capreq-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-capreq-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001127132354.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Tue Nov 28 12:33:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10619 for ; Tue, 28 Nov 2000 12:33:48 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA22185 for ietf-calendar-bks; Tue, 28 Nov 2000 09:10:03 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22178 for ; Tue, 28 Nov 2000 09:10:01 -0800 (PST) From: Bruce_Kahn@iris.com To: Steve Mansour Cc: CalSched IETF Subject: Re: iTIP updates X-Mailer: Lotus Notes Build V60_11132000 November 13, 2000 Message-ID: Date: Tue, 28 Nov 2000 12:11:11 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/28/2000 12:17:39 PM, Serialize complete at 11/28/2000 12:17:39 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005EA5A2852569A5_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005EA5A2852569A5_= Content-Type: text/plain; charset="us-ascii" Steve clarified with: >No, I'm referring specifically to the change where we add people to or remove them from >the recipient list. If we don't bump the sequence number, then you and I can have an event >with the same UID and the same SEQUENCE but different attendee lists. That just seems >wrong. I fail to see _why_ if I add a new ATTENDEE that I must rev SEQUENCE and thus invalidate the responses from _ALL_ other ATTENDEEs? If I have a standing weekly team meeting that I need to add a new ATTENDEE to, I have to invalidate everyone elses acceptances/declines?? Not because of any time or (possibly) LOCATION change but just for a new ATTENDEE. Thats not cool. Perhaps you can tell me why sending out a new REQUEST w/the SAME UID and SEQUENCE but a _newer_ DTSTAMP and the additional ATTENDEE is not sufficient. Im sorry but I just dont see why it is insufficient?? After all, the recipients see the same (UID, SEQUENCE) and a newer DTSTAMP so they compare their copy to the newer one and see 1 new ATTENDEE (and maybe a typo change too, maybe not...) so they just add the new ATTENDEE to their local copy WITHOUT invalidating their current response status. 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 005EA5A2852569A5_= Content-Type: text/html; charset="us-ascii"
Steve clarified with:
>No, I'm referring specifically to the change where we add people to or remove them from
>the recipient list. If we don't bump the sequence number, then you and I can have an event
>with the same UID and the same SEQUENCE but different attendee lists. That just seems
>wrong.

I fail to see _why_ if I add a new ATTENDEE that I must rev SEQUENCE and thus invalidate the responses from _ALL_ other ATTENDEEs?  If I have a standing weekly team meeting that I need to add a new ATTENDEE to, I have to invalidate everyone elses acceptances/declines??  Not because of any time or (possibly) LOCATION change but just for a new ATTENDEE.  Thats not cool.

Perhaps you can tell me why sending out a new REQUEST w/the SAME UID and SEQUENCE but a _newer_ DTSTAMP and the additional ATTENDEE is not sufficient.  Im sorry but I just dont see why it is insufficient??  After all, the recipients see the same (UID, SEQUENCE) and a newer DTSTAMP so they compare their copy to the newer one and see 1 new ATTENDEE (and maybe a typo change too, maybe not...) so they just add the new ATTENDEE to their local copy WITHOUT invalidating their current response status.

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 005EA5A2852569A5_=-- From owner-ietf-calendar@mail.imc.org Tue Nov 28 21:07:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12670 for ; Tue, 28 Nov 2000 21:07:35 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA20551 for ietf-calendar-bks; Tue, 28 Nov 2000 17:35:31 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20547 for ; Tue, 28 Nov 2000 17:35:29 -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 eAT1SQD26985; Tue, 28 Nov 2000 17:28:27 -0800 (PST) Received: from netscape.com (h-192-18-125-198.red.iplanet.com [192.18.125.198]) by seasnake.red.iplanet.com (8.8.5/8.8.5) with ESMTP id RAA4113627; Tue, 28 Nov 2000 17:42:23 -0800 (PST) Message-ID: <3A245DB9.C5A532B3@netscape.com> Date: Tue, 28 Nov 2000 17:36:57 -0800 From: Steve Mansour X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: CalSched IETF Subject: Re: iTIP updates References: Content-Type: multipart/mixed; boundary="------------6FA656369DB9A7B4D69D8195" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6FA656369DB9A7B4D69D8195 Content-Type: multipart/alternative; boundary="------------A7DABE7D8C3622F7FB4D4B85" --------------A7DABE7D8C3622F7FB4D4B85 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > Steve clarified with: > >No, I'm referring specifically to the change where we add people to > or remove them from > >the recipient list. If we don't bump the sequence number, then you > and I can have an event > >with the same UID and the same SEQUENCE but different attendee lists. > That just seems > >wrong. > > I fail to see _why_ if I add a new ATTENDEE that I must rev SEQUENCE > and thus invalidate the responses from _ALL_ other ATTENDEEs? If I > have a standing weekly team meeting that I need to add a new ATTENDEE > to, I have to invalidate everyone elses acceptances/declines?? Not > because of any time or (possibly) LOCATION change but just for a new > ATTENDEE. Thats not cool. It just seems wrong to me that you and I can have an event with the same UID / RID / SEQ and your version has one list of attendees and my list has a different list. > Perhaps you can tell me why sending out a new REQUEST w/the SAME UID > and SEQUENCE but a _newer_ DTSTAMP and the additional ATTENDEE is not > sufficient. Im sorry but I just dont see why it is insufficient?? > After all, the recipients see the same (UID, SEQUENCE) and a newer > DTSTAMP so they compare their copy to the newer one and see 1 new > ATTENDEE (and maybe a typo change too, maybe not...) so they just add > the new ATTENDEE to their local copy WITHOUT invalidating their > current response status. Yes, this works. That's why I did not insert my preference in the iTIP text :-) It just seems weird to have different attendee lists for events with the same UID / RID / SEQ. I may be the only person who finds it odd. If so, I won't reopen the sequence number issue. -Steve --------------A7DABE7D8C3622F7FB4D4B85 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:

Steve clarified with:
>No, I'm referring specifically to the change where we add people to or remove them from
>the recipient list. If we don't bump the sequence number, then you and I can have an event
>with the same UID and the same SEQUENCE but different attendee lists. That just seems
>wrong.

I fail to see _why_ if I add a new ATTENDEE that I must rev SEQUENCE and thus invalidate the responses from _ALL_ other ATTENDEEs?  If I have a standing weekly team meeting that I need to add a new ATTENDEE to, I have to invalidate everyone elses acceptances/declines??  Not because of any time or (possibly) LOCATION change but just for a new ATTENDEE.  Thats not cool.

It just seems wrong to me that you and I can have an event with the same UID / RID / SEQ  and your version has one list of attendees and my list has a different list.
Perhaps you can tell me why sending out a new REQUEST w/the SAME UID and SEQUENCE but a _newer_ DTSTAMP and the additional ATTENDEE is not sufficient.  Im sorry but I just dont see why it is insufficient?? After all, the recipients see the same (UID, SEQUENCE) and a newer DTSTAMP so they compare their copy to the newer one and see 1 new ATTENDEE (and maybe a typo change too, maybe not...) so they just add the new ATTENDEE to their local copy WITHOUT invalidating their current response status.
Yes, this works. That's why I did not insert my preference in the iTIP text :-)  It just seems weird to have different attendee lists for events with the same UID / RID / SEQ.

I may be the only person who finds it odd. If so, I won't reopen the sequence number issue.

-Steve --------------A7DABE7D8C3622F7FB4D4B85-- --------------6FA656369DB9A7B4D69D8195 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;work:650-937-2378 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner fn:Steve Mansour end:vcard --------------6FA656369DB9A7B4D69D8195-- From owner-ietf-calendar@mail.imc.org Wed Nov 29 09:52:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21494 for ; Wed, 29 Nov 2000 09:52:35 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA13986 for ietf-calendar-bks; Wed, 29 Nov 2000 06:19:24 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13982 for ; Wed, 29 Nov 2000 06:19: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 JAA11631; Wed, 29 Nov 2000 09:20:16 -0500 Received: from c-1401.cst.ca (C-1401 [192.168.1.48]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XTMSYQT9; Wed, 29 Nov 2000 09:21:49 -0500 Message-Id: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.cst.ca> X-Sender: markp@apollo.cst.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 29 Nov 2000 09:20:53 -0500 To: andrec@steltor.com, ietf-calendar@imc.org From: Mark Paterson Subject: RE: CAP requirements draft resubmitted Cc: pregen@egenconsulting.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe:
With respect to Synchronization the basic requirement that a sync engine would require from a CAP compliant server would be an easy way of requesting changes based on a sync context.

In your typical sync session the device provides all its changes (new events/tasks, changed events/tasks, and deleted events/tasks) since the last time it sync'd up and then all the changes from the server are gathered. They are compared, conflicts resolved, etc.. and then the sync engine instructs the server as to the changes it needs to make and instructs the device on the changes it should make. Along the way mapping information so that device IDs can be properly mapped to server IDs is updated as well.

It is important to note however that when changes are gathered from a server that the changes required are not necessarily the changes since the last time the user sync'd but rather since the last time the user sync'd with the device in question. A user could have a PDA with a fairly sophisticated calendar client on it as well as a smart phone with a simpler calendar on it both of which he or she syncs regularly. If a sync is first done with the PDA and then with the Phone it is important that the changes used when syncing the phone are the changes from the last time user sync'd the phone and not simple since the last time he sync'd. Thus the need for some sort of sync context when requesting changes.

If CAP could provide an easy way of gathering such changes a sync engine claiming proper calendar synchronization based on iCalendar could be implemented such that it would work with any CAP back end. Combine this with SyncML and it can be implemented to work with any SyncML compliant front end. Both ends covered, not bad :)

In other words, "YES". Requirements for sync should definitely be addressed in CAP.

At 08:06 AM 11/21/2000 -0500, andrec@steltor.com wrote:

Pat,
 
Renewing CAP requirements is good thing. It will help to keep us on track.
 
Regarding syncronization, in this age of mobile users with multiple handheld devices, we need to
ensure that calendar stores can be performed efficiently with the basic commands of the protocol.
I am of the opinion that syncronization capabilities are fundamental to ensure acceptance of
CAP as a protocol. I think that we have all the basic contructs in the protocol to do it.
 
My vote is "YES" lets keep it in and lets make sure we have all the pieces to allow for instance
a SyncML client to be properly layed on top of CAP. It should not take too much time.
 
Comments?
 
Andre Courtemanche
CEO, Steltor.
Formerly known as CS&T/Lexacom.

 -----Original Message-----
From: pregen@egenconsulting.com [mailto:pregen@egenconsulting.com]
Sent: Friday, November 17, 2000 4:45 PM
To: ietf-calendar@imc.org
Subject: CAP requirements draft resubmitted
I resubmitted the CAP requirements draft today.  It expired and I submitted it for reinstatement since we are still working on CAP.  We may need to make more adjustments, but I wanted the draft there so we can make more modifications.  In particular, the requirements state several items about synchronizing calendars. However, as CAP stands today (in the draft) we don't have this included.  So, the question is - do we keep it in the requirements? If so, do we add it into CAP? Thoughts from the list.

Also, there have been several items on the list regarding restriction tables.  Unless we hear otherwise from people on the list, we will assume they look ok.   
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

--
Mark Paterson (markp@steltor.com)
Director, Client Development, Steltor (formerly CS&T - Lexacom) From owner-ietf-calendar@mail.imc.org Wed Nov 29 12:23:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19226 for ; Wed, 29 Nov 2000 12:23:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25112 for ietf-calendar-bks; Wed, 29 Nov 2000 08:52:07 -0800 (PST) Received: from guanabana.helixcode.com (IDENT:root@[132.248.10.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25105 for ; Wed, 29 Nov 2000 08:52:05 -0800 (PST) Received: (from federico@localhost) by guanabana.helixcode.com (8.9.3/8.9.3) id LAA15559; Wed, 29 Nov 2000 11:00:37 -0600 Date: Wed, 29 Nov 2000 11:00:37 -0600 Message-Id: <200011291700.LAA15559@guanabana.helixcode.com> X-Authentication-Warning: guanabana.helixcode.com: federico set sender to federico@helixcode.com using -f From: Federico Mena Quintero X-termination: killing the window system To: Mark Paterson Cc: andrec@steltor.com, ietf-calendar@imc.org, pregen@egenconsulting.com CC: JP Rosevear Subject: Re: CAP requirements draft resubmitted References: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.cst.ca> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Paterson writes: > In your typical sync session the device provides all its changes (new > events/tasks, changed events/tasks, and deleted events/tasks) since the > last time it sync'd up and then all the changes from the server are > gathered. They are compared, conflicts resolved, etc.. and then the sync > engine instructs the server as to the changes it needs to make and > instructs the device on the changes it should make. Along the way mapping > information so that device IDs can be properly mapped to server IDs is > updated as well. > > It is important to note however that when changes are gathered from a > server that the changes required are not necessarily the changes since > the last time the user sync'd but rather since the last time the user > sync'd with the device in question. A user could have a PDA with a fairly > sophisticated calendar client on it as well as a smart phone with a > simpler calendar on it both of which he or she syncs regularly. If a sync > is first done with the PDA and then with the Phone it is important that > the changes used when syncing the phone are the changes from the last > time user sync'd the phone and not simple since the last time he sync'd. > Thus the need for some sort of sync context when requesting > changes. Evolution handles this by having its calendar backend store a log of modifications to a particular calendar. The log looks more or less like UID action timestamp foo updated bar removed baz removed qux updated When you access a calendar backend, you can ask it for the log's entries between two particular timestamps. Synchronization conduits (e.g. for the Palm Pilot or phones or whatever) can use this information to figure out what to do. Each conduit stores the last timestamp at which it did a sync operation; the next time it runs it just uses that to query the calendar backend. If you have the Evolution source tree, you can see the interfaces for this in evolution/calendar/idl/evolution-calendar.idl. Look for the Cal::getChangedUIDs() method. Federico From owner-ietf-calendar@mail.imc.org Wed Nov 29 13:06:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04459 for ; Wed, 29 Nov 2000 13:06:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24932 for ietf-calendar-bks; Wed, 29 Nov 2000 08:44:08 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24928 for ; Wed, 29 Nov 2000 08:44:06 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eATGncj02453 for ; Wed, 29 Nov 2000 11:49:39 -0500 Message-ID: <3A2533A2.3A5F8BFF@ecal.com> Date: Wed, 29 Nov 2000 11:49:38 -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: CAP requirements draft resubmitted References: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.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 Mark Paterson wrote: > If a sync is first done with the PDA and then with the Phone it > is important that the changes used when syncing the phone are > the changes from the last time user sync'd the phone and not > simple since the last time he sync'd. Thus the need for some > sort of sync context when requesting changes. I would turn it around: because there may be many devices trying to sync, there should be no server-side context; the awareness of when the sync was last done should live in the device. Also, consider this sequence: 1. I sync my Pilot with my CS. 2. I back up my Pilot to my desktop. 3. I sync my Pilot with my CS. 4. My Pilot's battery goes dead and it loses its data, because Palm is too cheap to use flash memory. (Sorry, this is a sore point for me. :-) 5. I restore my Pilot from backup. 6. I sync my Pilot with my CS. If the CS stores the knowledge that I last synched at #3, then it's not going to send me the changes that occurred between #1 and #3. If that knowledge is stored in the Pilot, then it gets backed up at #2 and restored at #6, and the sync at #7 will get the right data. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Vote for Ron, and nobody gets hurt! --actual | |francis@ecal.com|campaign poster from Chicago | \==============================================================/ From owner-ietf-calendar@mail.imc.org Wed Nov 29 13:36:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13692 for ; Wed, 29 Nov 2000 13:36:24 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA00509 for ietf-calendar-bks; Wed, 29 Nov 2000 10:15:19 -0800 (PST) Received: from c013.sfo.cp.net (c013-h003.c013.sfo.cp.net [209.228.12.56]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA00501 for ; Wed, 29 Nov 2000 10:15:18 -0800 (PST) Received: (cpmta 15617 invoked from network); 29 Nov 2000 10:16:19 -0800 Received: from dyn27-75.eng.cp.net (HELO criticalpath.net) (209.228.27.75) by smtp.criticalpath.net (209.228.12.56) with SMTP; 29 Nov 2000 10:16:19 -0800 X-Sent: 29 Nov 2000 18:16:19 GMT Message-ID: <3A25469C.EC7D158A@criticalpath.net> Date: Wed, 29 Nov 2000 10:10:36 -0800 From: Colin DuPlantis Organization: http://www.criticalpath.net X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Paterson CC: andrec@steltor.com, ietf-calendar@imc.org, pregen@egenconsulting.com Subject: Re: CAP requirements draft resubmitted References: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.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 Mark Paterson wrote: > It is important to note however that when changes are gathered from a > server that the changes required are not necessarily the changes since > the last time the user sync'd but rather since the last time the user > sync'd with the device in question. A user could have a PDA with a > fairly sophisticated calendar client on it as well as a smart phone > with a simpler calendar on it both of which he or she syncs regularly. > If a sync is first done with the PDA and then with the Phone it is > important that the changes used when syncing the phone are the changes > from the last time user sync'd the phone and not simple since the last > time he sync'd. Thus the need for some sort of sync context when > requesting changes. InSchedule (http://www.criticalpath.net/products/insch_cal_overview.html) handles synchronization by allowing the sync client to ask for events added or changed since a certain date. The sync client can also ask the server what time the server thinks it is, which the client can store for the next session. In other words, we require the sync client to keep track of the last time it sunk, and supply that time the next time a sync is requested, if a net change sync is desired. This prevents the server from having to know which sync client is attempting to sync, but it does require the sync client to keep the timestamp from the last sync. - C -- Colin DuPlantis Engineering Manager - Calendar Critical Path, Inc. http://www.criticalpath.net 320 First Street San Francisco, CA 94105 Direct: 415.808.8816 Main: 415.808.8800 Fax: 415.808.8778 From owner-ietf-calendar@mail.imc.org Wed Nov 29 15:37:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23878 for ; Wed, 29 Nov 2000 15:37:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08604 for ietf-calendar-bks; Wed, 29 Nov 2000 12:19:08 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08598 for ; Wed, 29 Nov 2000 12:19: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 PAA17960; Wed, 29 Nov 2000 15:20:07 -0500 Received: from c-1401.cst.ca (C-1401 [192.168.1.48]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XTMSYSSR; Wed, 29 Nov 2000 15:21:41 -0500 Message-Id: <5.0.0.25.0.20001129145406.02877008@apollo.cst.ca> X-Sender: markp@apollo.cst.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 29 Nov 2000 15:20:46 -0500 To: John Stracke , ietf-calendar@imc.org From: Mark Paterson Subject: Re: CAP requirements draft resubmitted In-Reply-To: <3A2533A2.3A5F8BFF@ecal.com> References: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.cst.ca> 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: Your're quite right but I wasn't trying to get into all the semantics involved with a sync but rather simply point out that knowing what has changed is crucial to a sync and CAP should not preclude the ability to gather such changes (nor am I implying that it does but just that in reviewing it considering things from a sync perspective will be important). In the case you describe most sync tools first establish at the beginning of the session whether the client and server are on the same page (i.e. Do they both think they are at the same point as the last time they talked?). This usually done with some form of reference that is stored on both sides so that it can be compared the next time. If they don't match (which would occur in your example) then the engine has the more daunting task of trying to figure out who's where and wouldn't request changes in this manner (sometimes called a "slow sync"). At 11:49 AM 11/29/2000 -0500, John Stracke wrote: >Mark Paterson wrote: > > > If a sync is first done with the PDA and then with the Phone it > > is important that the changes used when syncing the phone are > > the changes from the last time user sync'd the phone and not > > simple since the last time he sync'd. Thus the need for some > > sort of sync context when requesting changes. > >I would turn it around: because there may be many devices trying >to sync, there should be no server-side context; the awareness of >when the sync was last done should live in the device. > >Also, consider this sequence: > > 1. I sync my Pilot with my CS. > 2. I back up my Pilot to my desktop. > 3. I sync my Pilot with my CS. > 4. My Pilot's battery goes dead and it loses its data, because > Palm is too cheap to use flash memory. (Sorry, this is a > sore point for me. :-) > 5. I restore my Pilot from backup. > 6. I sync my Pilot with my CS. > >If the CS stores the knowledge that I last synched at #3, then >it's not going to send me the changes that occurred between #1 >and #3. If that knowledge is stored in the Pilot, then it gets >backed up at #2 and restored at #6, and the sync at #7 will get >the right data. > >-- >/==============================================================\ >|John Stracke | http://www.ecal.com |My opinions are my own.| >|Chief Scientist |=============================================| >|eCal Corp. |Vote for Ron, and nobody gets hurt! --actual | >|francis@ecal.com|campaign poster from Chicago | >\==============================================================/ -- Mark Paterson (markp@steltor.com) Director, Client Development, Steltor (formerly CS&T - Lexacom) From owner-ietf-calendar@mail.imc.org Wed Nov 29 16:07:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04811 for ; Wed, 29 Nov 2000 16:07:03 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA10834 for ietf-calendar-bks; Wed, 29 Nov 2000 12:47:10 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10829 for ; Wed, 29 Nov 2000 12:47:07 -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 PAA18467; Wed, 29 Nov 2000 15:48:02 -0500 Received: from c-1401.cst.ca (C-1401 [192.168.1.48]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XTMSYSX1; Wed, 29 Nov 2000 15:49:35 -0500 Message-Id: <5.0.0.25.0.20001129153104.02866e40@apollo.cst.ca> X-Sender: markp@apollo.cst.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 29 Nov 2000 15:48:40 -0500 To: Colin DuPlantis From: Mark Paterson Subject: Re: CAP requirements draft resubmitted Cc: ietf-calendar@imc.org In-Reply-To: <3A25469C.EC7D158A@criticalpath.net> References: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.cst.ca> 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: Hi Colin, What you describe would certainly take care of things. The timestamp is part of the context information required for the sync. And you are right the client does need to save this. I did not mean to imply that the server was required to save some new-fangled "sync context" but in reviewing the way I worded things perhaps that's how it came across. I meant only to point out that being able to gather changes is important and to further point out that it is not as easy as knowing what has changed since the last time. I was actually trying to avoid implying any form of implementation and to just provide enough information to justify why I would answer "YES" to Pat's question from her message (Cut and paste below) "In particular, the requirements state several items about synchronizing calendars. However, as CAP stands today (in the draft) we don't have this included. So, the question is - do we keep it in the requirements? If so, do we add it into CAP?" Mark Paterson At 10:10 AM 11/29/2000 -0800, Colin DuPlantis wrote: >Mark Paterson wrote: > > > It is important to note however that when changes are gathered from a > > server that the changes required are not necessarily the changes since > > the last time the user sync'd but rather since the last time the user > > sync'd with the device in question. A user could have a PDA with a > > fairly sophisticated calendar client on it as well as a smart phone > > with a simpler calendar on it both of which he or she syncs regularly. > > If a sync is first done with the PDA and then with the Phone it is > > important that the changes used when syncing the phone are the changes > > from the last time user sync'd the phone and not simple since the last > > time he sync'd. Thus the need for some sort of sync context when > > requesting changes. > > >InSchedule >(http://www.criticalpath.net/products/insch_cal_overview.html) handles >synchronization by allowing the sync client to ask for events added or >changed since a certain date. The sync client can also ask the server >what time the server thinks it is, which the client can store for the >next session. In other words, we require the sync client to keep track >of the last time it sunk, and supply that time the next time a sync is >requested, if a net change sync is desired. This prevents the server >from having to know which sync client is attempting to sync, but it does >require the sync client to keep the timestamp from the last sync. > >- C > >-- >Colin DuPlantis >Engineering Manager - Calendar >Critical Path, Inc. >http://www.criticalpath.net >320 First Street >San Francisco, CA 94105 >Direct: 415.808.8816 >Main: 415.808.8800 >Fax: 415.808.8778 -- Mark Paterson (markp@steltor.com) Director, Client Development, Steltor (formerly CS&T - Lexacom) From owner-ietf-calendar@mail.imc.org Wed Nov 29 19:41:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19629 for ; Wed, 29 Nov 2000 19:41:39 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA20314 for ietf-calendar-bks; Wed, 29 Nov 2000 16:20:59 -0800 (PST) Received: from bbs.ht.net.cn ([202.103.160.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20310 for ; Wed, 29 Nov 2000 16:20:57 -0800 (PST) From: V@tzw.de Received: from h809 (1Cust82.tnt1.mia5.da.uu.net [63.30.194.82]) by bbs.ht.net.cn (8.8.7/8.7.3) with SMTP id IAA12577; Thu, 30 Nov 2000 08:38:54 +0800 Date: Thu, 30 Nov 2000 08:38:54 +0800 Message-Id: <200011300038.IAA12577@bbs.ht.net.cn> To: V@tzw.de Subject: Lady V: The Pleasure Pill for Women! Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LADY V: The Pleasure Pill for Women! Men Have Their Viagra®! Finally, A Pill for Women! It's Here! The Revolutionary Woman's Sexual Sensation is Now Available. Researchers are calling Lady V the greatest breakthrough for women since the Birth Control Pill. And you don't even need a prescription to get it! Welcome to the New Sexual Revolution! It's no secret that men have been having the time of their lives since the wonder pill Viagra® was made available. But, women were left out in the cold with no pill... nothing! Well now thanks to an all-star team of medical researchers who have been working around the clock, those days are finally over. The perfect female "pleasure pill" has been created and you don't even need a prescription. You can now get it from Lion Sciences! Lady V is the world's first pleasure pill scientifically designed for women. Lady V is an all-natural proprietary herbal blend of prosexual nutrients from around the world synergistically blended to naturally stimulate neurotransmitter endorphin signals. This magical combination increases targeted blood flow, unleashes natural stimulator for maximum stimulation, triggering pleasure responses quickly. Lady V is safe, natural and doctor-recommended. Since its introduction Lady V has been taking the world by storm! From Malibu to Miami women are enjoying the most intense pleasure of their lives! • 100% Natural • Safe • The Highest Quality Pharmaceutical Pure Nutraceuticals • Guaranteed Potency • Certified Purity Lady V is Sweeping the Nation! Women are going crazy over Lady V. Suddenly couples are falling in love all over again. The passion and pleasure that women are reporting is off the charts! Lady V has an incredible 88% success rate. Best of all, while Viagra costs $10 a pill, Lady V costs less than $1 a pill! It's not just a man's world anymore! Just look at what a few women have to say: "I thought my love life was good before, but now it is out of this world! Lady V is remarkable." — Mary J., Interior Designer "I haven't smiled like this in a long time. My husband and I feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer "Imagine what it would feel like to have incredible passion and pleasure anytime you want." — Jennifer C., Film Editor "Suddenly my husband and I are spending more time in the bedroom instead of the TV room." — Angie R., Realtor Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid, Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract, Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana, and L-Taurine. Each bottle of Lady V contains 30 tablets. Take three capsules one hour before romantic activity as a dietary supplement. Risk Free: Double Your Money Back Guarantee If Lady V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked! Order Now: Safe, Fast, Secure, Private Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Lady V contains 30 tablets. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Lady V $24 ______ 2 Bottles of Lady V $44 ______ 3 Bottles of Lady V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $18 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 273 S. State Rd. 7, #193 Margate, FL 33068-5727 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Lady V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Lady V helps provide herbal and nutritional support for female sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-ietf-calendar@mail.imc.org Thu Nov 30 06:16:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08618 for ; Thu, 30 Nov 2000 06:16:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA27179 for ietf-calendar-bks; Thu, 30 Nov 2000 02:49:42 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27172 for ; Thu, 30 Nov 2000 02:49:40 -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 FAA25104; Thu, 30 Nov 2000 05:51:13 -0500 (EST) Message-Id: <200011301051.FAA25104@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-imp-guide-02.txt Date: Thu, 30 Nov 2000 05:51:13 -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 : Implementors' Guide to Internet Calendaring Author(s) : B. Mahoney, A. Taler, G. Babics Filename : draft-ietf-calsch-imp-guide-02.txt Pages : 14 Date : 29-Nov-00 This document describes the various internet calendaring and scheduling standards and drafts and the relationships between them. It's intention is to provide a context for these documents, assist in their understanding, and potentially help implementors in the design of their internet calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The draft addressed is 'Calendar Access Protocol' (CAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-imp-guide-02.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-imp-guide-02.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-imp-guide-02.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: <20001129113918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-imp-guide-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-imp-guide-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001129113918.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Thu Nov 30 10:52:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02147 for ; Thu, 30 Nov 2000 10:52:24 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20691 for ietf-calendar-bks; Thu, 30 Nov 2000 07:29:50 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20679 for ; Thu, 30 Nov 2000 07:29:49 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eAUFZS401431 for ; Thu, 30 Nov 2000 10:35:29 -0500 Message-ID: <3A2673BF.50FF4F1C@ecal.com> Date: Thu, 30 Nov 2000 10:35:27 -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: CAP requirements draft resubmitted References: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.cst.ca> <5.0.0.25.0.20001129153104.02866e40@apollo.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 Mark Paterson wrote: > I meant only to > point out that being able to gather changes is important and to further > point out that it is not as easy as knowing what has changed since the last > time. I still don't understand this part--to me, it seems that knowing what has changed should be enough. Could you explain, please? -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Q: What goes "Pieces of 7! Pieces of 7!"? A: A| |francis@ecal.com|parroty error. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 30 10:59:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05522 for ; Thu, 30 Nov 2000 10:59:46 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA21424 for ietf-calendar-bks; Thu, 30 Nov 2000 07:32:31 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21390 for ; Thu, 30 Nov 2000 07:32:23 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id eAUFbq401443 for ; Thu, 30 Nov 2000 10:37:52 -0500 Message-ID: <3A267450.EA932D32@ecal.com> Date: Thu, 30 Nov 2000 10:37:52 -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: CAP requirements draft resubmitted References: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.cst.ca> <5.0.0.25.0.20001129145406.02877008@apollo.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 Mark Paterson wrote: > In the case you describe most sync tools first establish at the beginning > of the session whether the client and server are on the same page (i.e. Do > they both think they are at the same point as the last time they talked?). > This usually done with some form of reference that is stored on both sides > so that it can be compared the next time. This isn't going to scale very well; you don't want any long-term per-client state stored on the server, and you don't want to have to confront the question of how to identify a particular client. Unless you can explain why the stateless approach won't work, I would be opposed to any such extension. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |Q: What goes "Pieces of 7! Pieces of 7!"? A: A| |francis@ecal.com|parroty error. | \===============================================================/ From owner-ietf-calendar@mail.imc.org Thu Nov 30 11:32:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22983 for ; Thu, 30 Nov 2000 11:32:47 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA26949 for ietf-calendar-bks; Thu, 30 Nov 2000 08:10:12 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26937 for ; Thu, 30 Nov 2000 08:10:08 -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 LAA28348; Thu, 30 Nov 2000 11:11:13 -0500 Received: from c-1401.cst.ca (C-1401 [192.168.1.48]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XTMSY4WZ; Thu, 30 Nov 2000 11:12:48 -0500 Message-Id: <5.0.0.25.0.20001130110312.0286bd60@apollo.cst.ca> X-Sender: markp@apollo.cst.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 30 Nov 2000 11:11:52 -0500 To: John Stracke , ietf-calendar@imc.org From: Mark Paterson Subject: Re: CAP requirements draft resubmitted In-Reply-To: <3A2673BF.50FF4F1C@ecal.com> References: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.cst.ca> <5.0.0.25.0.20001129153104.02866e40@apollo.cst.ca> 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 10:35 AM 11/30/2000 -0500, John Stracke wrote: >Mark Paterson wrote: > > > I meant only to > > point out that being able to gather changes is important and to further > > point out that it is not as easy as knowing what has changed since the last > > time. > >I still don't understand this part--to me, it seems that knowing what has >changed should be enough. Could you explain, please? Knowing what has changed since the last time the user sync'd his server with a particular device IS enough but simply knowing what has changed since the last time you asked for changes is not, hence the need for a mechanism such as Colin mentioned where by you can request changes based on a timestamp. >-- >/===============================================================\ >|John Stracke | http://www.ecal.com |My opinions are my own. | >|Chief Scientist |==============================================| >|eCal Corp. |Q: What goes "Pieces of 7! Pieces of 7!"? A: A| >|francis@ecal.com|parroty error. | >\===============================================================/ -- Mark Paterson (markp@steltor.com) Director, Client Development, Steltor (formerly CS&T - Lexacom) From owner-ietf-calendar@mail.imc.org Thu Nov 30 11:52:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02598 for ; Thu, 30 Nov 2000 11:52:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28268 for ietf-calendar-bks; Thu, 30 Nov 2000 08:28:03 -0800 (PST) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28262 for ; Thu, 30 Nov 2000 08:28:02 -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 LAA28659; Thu, 30 Nov 2000 11:29:07 -0500 Received: from c-1401.cst.ca (C-1401 [192.168.1.48]) by apollo.cst.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id XTMSY4Z5; Thu, 30 Nov 2000 11:30:43 -0500 Message-Id: <5.0.0.25.0.20001130111216.02881a30@apollo.cst.ca> X-Sender: markp@apollo.cst.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 30 Nov 2000 11:29:46 -0500 To: John Stracke , ietf-calendar@imc.org From: Mark Paterson Subject: Re: CAP requirements draft resubmitted In-Reply-To: <3A267450.EA932D32@ecal.com> References: <5.0.0.25.0.20001129085328.00a7b6c8@apollo.cst.ca> <5.0.0.25.0.20001129145406.02877008@apollo.cst.ca> 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 10:37 AM 11/30/2000 -0500, John Stracke wrote: >Mark Paterson wrote: > > > In the case you describe most sync tools first establish at the beginning > > of the session whether the client and server are on the same page (i.e. Do > > they both think they are at the same point as the last time they talked?). > > This usually done with some form of reference that is stored on both sides > > so that it can be compared the next time. > >This isn't going to scale very well; you don't want any long-term per-client >state stored on the server, and you don't want to have to confront the >question of how to identify a particular client. Unless you can explain why >the stateless approach won't work, I would be opposed to any such extension. Extension to what? I didn't ask for any extension. You proposed an example where by your Palm gets wiped and as a result isn't in the state it was when you actually last sync'ed. I simply tried to explain how most sync engines handle this. Keeping track of a sync reference (or anchor) is the responsibility of the sync client and the sync engine (or sync server). It has nothing to do with the calendar server nor any other back end data store containing some data type you may wish to sync (email, contacts, MP3s, etc). >-- >/===============================================================\ >|John Stracke | http://www.ecal.com |My opinions are my own. | >|Chief Scientist |==============================================| >|eCal Corp. |Q: What goes "Pieces of 7! Pieces of 7!"? A: A| >|francis@ecal.com|parroty error. | >\===============================================================/ -- Mark Paterson (markp@cst.ca) Director, Client Development, CS&T - Lexacom From owner-ietf-calendar@mail.imc.org Thu Nov 30 17:48:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03974 for ; Thu, 30 Nov 2000 17:48:44 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA21564 for ietf-calendar-bks; Thu, 30 Nov 2000 14:21:23 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA21557 for ; Thu, 30 Nov 2000 14:21:20 -0800 (PST) From: Bruce_Kahn@iris.com To: Steve Mansour Cc: CalSched IETF Subject: Re: iTIP updates MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_11272000 November 27, 2000 Message-ID: Date: Thu, 30 Nov 2000 17:21:52 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/30/2000 05:23:01 PM, Serialize complete at 11/30/2000 05:23:01 PM Content-Type: multipart/alternative; boundary="=_alternative 007B30EA852569A7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B30EA852569A7_= Content-Type: text/plain; charset="us-ascii" I got a BIG backlog of msgs from the past 2 days so if this is a rehash of others response then mea culpa... Steve kindly responded: >>I fail to see _why_ if I add a new ATTENDEE that I must rev SEQUENCE and thus invalidate the >>responses from _ALL_ other ATTENDEEs? If I have a standing weekly team meeting that I need >>to add a new ATTENDEE to, I have to invalidate everyone elses acceptances/declines?? Not >>because of any time or (possibly) LOCATION change but just for a new ATTENDEE. Thats not >>cool. >It just seems wrong to me that you and I can have an event with the same UID / RID / SEQ and >your version has one list of attendees and my list has a different list. Ok, besides the obvious "Its gonna happen because email is not 100%" kind of answer Ill reiterate my original response in a different way to be clearer. I (still) see no compelling reason to rev SEQUENCE for this (and restart the workflow process) when sending out a message with a newer DTSTAMP will achieve the desired results. Simply put, if Pat and I have an ongoing weekly meeting we both have accepted and I want to add Steve to it; why do I have to invalidate Pats current status and make her reACCEPT all the affected entries when I can simply send her a message w/the same UID / RID / SEQUENCE and a newer DTSTAMP (ie the date/time I added Steve)?? That way Pat gets told of the new ATTENDEE and we do not have to redo the entire workflow process... This is the exact same mechanism that we use for typo updates or 'non-rescheduling' updates. If it works in those cases, why wont it work in the "adding a new ATTENDEE" case?? Im REALLY against big changs like new methods that have new SEQUENCE reving rules (and as such are not 2.0 compatible!!) when I think what Steve wants can already be done today... 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 007B30EA852569A7_= Content-Type: text/html; charset="us-ascii"
I got a BIG backlog of msgs from the past 2 days so if this is a rehash of others response then mea culpa...

Steve kindly responded:
>>I fail to see _why_ if I add a new ATTENDEE that I must rev SEQUENCE and thus invalidate the
>>responses from _ALL_ other ATTENDEEs?  If I have a standing weekly team meeting that I need
>>to add a new ATTENDEE to, I have to invalidate everyone elses acceptances/declines??  Not
>>because of any time or (possibly) LOCATION change but just for a new ATTENDEE.  Thats not
>>cool.
>It just seems wrong to me that you and I can have an event with the same UID / RID / SEQ  and
>your version has one list of attendees and my list has a different list.

Ok, besides the obvious "Its gonna happen because email is not 100%" kind of answer Ill reiterate my original response in a different way to be clearer.  I (still) see no compelling reason to rev SEQUENCE for this (and restart the workflow process) when sending out a message with a newer DTSTAMP will achieve the desired results.  Simply put, if Pat and I have an ongoing weekly meeting we both have accepted and I want to add Steve to it; why do I have to invalidate Pats current status and make her reACCEPT all the affected entries when I can simply send her a message w/the same UID / RID / SEQUENCE and a newer DTSTAMP (ie the date/time I added Steve)??  That way Pat gets told of the new ATTENDEE and we do not have to redo the entire workflow process...  This is the exact same mechanism that we use for typo updates or 'non-rescheduling' updates.  If it works in those cases, why wont it work in the "adding! a new ATTENDEE" case??

Im REALLY against big changs like new methods that have new SEQUENCE reving rules (and as such are not 2.0 compatible!!) when I think what Steve wants can already be done today...

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 007B30EA852569A7_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 30 18:19:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21121 for ; Thu, 30 Nov 2000 18:19:15 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA23141 for ietf-calendar-bks; Thu, 30 Nov 2000 14:53:15 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23137 for ; Thu, 30 Nov 2000 14:53:13 -0800 (PST) From: Bruce_Kahn@iris.com To: Steve Mansour Cc: CalSched IETF Subject: Re: iTIP updates MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_11272000 November 27, 2000 Message-ID: Date: Thu, 30 Nov 2000 17:53:44 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 11/30/2000 05:54:52 PM, Serialize complete at 11/30/2000 05:54:52 PM Content-Type: multipart/alternative; boundary="=_alternative 007E1C20852569A7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007E1C20852569A7_= Content-Type: text/plain; charset="us-ascii" Appologies to those that may have gotten my last msg early. My client crashed and burned w/a Virtual Memory fault (Thanks NT!). Steve also replied: >Yes, this works. That's why I did not insert my preference in the iTIP text :-) It just seems weird to have different attendee lists for events with the same UID / RID / SEQ. Well, 'wierd' or not its gonna happen that different (UID, SEQUENCE, RECURRENCE-ID, DTSTAMP) sets will have different data in them. So Im back to asking about the general case for CONFIRM. Do we really need it? Yes, I think that having to derive the Organizers meaning from doing a 'diff' is painful (Im coding an engine so I share the pain!) and yes I would like some easier way to convey more 'logical' intent like "Im confirming that we will meet" or "Here is your concert ticket confirmation" but Im not convinced that CONFIRM does the job... Hmm, perhaps we could add a new property called INTENT and use it only when the SEQUENCE is NOT being rev'd on a REQUEST... 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 007E1C20852569A7_= Content-Type: text/html; charset="us-ascii"
Appologies to those that may have gotten my last msg early.  My client crashed and burned w/a Virtual Memory fault (Thanks NT!).

Steve also replied:
>Yes, this works. That's why I did not insert my preference in the iTIP text :-)  It just seems weird to have different attendee lists for events with the same UID / RID / SEQ.

Well, 'wierd' or not its gonna happen that different (UID, SEQUENCE, RECURRENCE-ID, DTSTAMP) sets will have different data in them.  So Im back to asking about the general case for CONFIRM.  Do we really need it?  Yes, I think that having to derive the Organizers meaning from doing a 'diff' is painful (Im coding an engine so I share the pain!) and yes I would like some easier way to convey more 'logical' intent like "Im confirming that we will meet" or "Here is your concert ticket confirmation" but Im not convinced that CONFIRM does the job...

Hmm, perhaps we could add a new property called INTENT and use it only when the SEQUENCE is NOT being rev'd on a REQUEST...

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 007E1C20852569A7_=-- From owner-ietf-calendar@mail.imc.org Thu Nov 30 19:08:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14221 for ; Thu, 30 Nov 2000 19:08:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA24867 for ietf-calendar-bks; Thu, 30 Nov 2000 15:53:16 -0800 (PST) Received: from agony.busboom.org (24-25-197-23.san.rr.com [24.25.197.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24857 for ; Thu, 30 Nov 2000 15:53:14 -0800 (PST) Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id PAA04657; Thu, 30 Nov 2000 15:54:22 -0800 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 30 Nov 2000 15:54:20 -0800 (PST) From: Eric Busboom X-Sender: eric@agony.busboom.org To: pregen@egenconsulting.com cc: ietf-calendar@imc.org Subject: Re: Agenda for CALSCH at IETF meeting - San Diego 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, 20 Oct 2000 pregen@egenconsulting.com wrote: > Here's the CALSCH agenda for the San Diego IETF meeting. Right now we are > possibly slated for a 2 hour session on Wednesday of the meeting week. > Patricia, Will we have any other (informal) meetings during the week? Two hours does not seem like much time. eric. From owner-ietf-calendar@mail.imc.org Thu Nov 30 19:44:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26979 for ; Thu, 30 Nov 2000 19:44:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA26532 for ietf-calendar-bks; Thu, 30 Nov 2000 16:16:27 -0800 (PST) Received: from mail2.svr.pol.co.uk (mail2.svr.pol.co.uk [195.92.193.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26528 for ; Thu, 30 Nov 2000 16:16:25 -0800 (PST) Received: from modem-49.oregon.dialup.pol.co.uk ([62.137.88.49] helo=helixcode.com) by mail2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 141dtk-0001QS-00; Fri, 01 Dec 2000 00:17:57 +0000 Message-ID: <3A26E283.489613E8@helixcode.com> Date: Thu, 30 Nov 2000 23:28:03 +0000 From: Damon Chaplin X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Eric Busboom CC: ietf-calendar@imc.org Subject: Re: Proposed Text for RFC2445 Issue #15: Recurrence Rules 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: > Not all date BYxxx rule parts can appear simultaneously in a single > recurrence rule. Date BYxxx rule part restrictions are: > > [a] If the BYYEARDAY part appears in a rule , no other date rule > part may appear. > > [b] BYWEEKNO and BYMONTH rule parts may not both appear. > [ except when week covers two months?] > > Furthermore, not all date rule parts may be used with all recurrence > intervals. > > [c] For MONTHLY recurrences (FREQ=MONTHLY) neither BYYEARDAY nor > BYWEEKNO may appear. > > [d] For WEEKLY recurrences (FREQ=WEEKLY) neither BYMONTHDAY nor > BYYEARDAY may appear. > > There are no restrictions regarding combinations of date rule parts and > time rule parts. There are no restrictions with using any combination of > time rule parts > > [ The BYYEARDAY part, for a given year, effectively specifies the month, > day of month, and week number, so restriction [a] eliminates ambiguity > between the day of year and other specifiers. > > Restrictions [b] is similar, since the week number specifies the month for > a given year. There may be a probably with this restriction when the week > overlaps two months, though. > > ] I'm happy with these restrictions. Though since I've seen some weird RRULEs used to calculate particular dates, I'm slightly worried that these could have been useful in that sort of situation. Also it still doesn't cover one ambiguity I mentioned a while back: o The BYDAY modifier is ambiguous. In a YEARLY frequency with BYMONTH or BYWEEKNO set, does the BYDAY modifier apply to the year day or the month/week day? I'd guess it applies to the month or week day. Maybe this was meant to be inferred from the order of application of the rule parts, so maybe the text just needs clarifying. Damon