From owner-ietf-calendar@mail.imc.org Fri Sep 1 00:14:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21324 for ; Fri, 1 Sep 2000 00:14:32 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA20549 for ietf-calendar-bks; Thu, 31 Aug 2000 20:56:19 -0700 (PDT) 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 UAA20543 for ; Thu, 31 Aug 2000 20:56:18 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e813ktV07099 for ; Thu, 31 Aug 2000 20:46:55 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G06WAU03.637; Thu, 31 Aug 2000 20:56:54 -0700 Message-ID: <39AF28F1.85FF473B@netscape.com> Date: Thu, 31 Aug 2000 20:56:33 -0700 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: CAP Restriction Table: CREATE References: Content-Type: multipart/mixed; boundary="------------490C08FFB35F15D25CE5EC22" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------490C08FFB35F15D25CE5EC22 Content-Type: multipart/alternative; boundary="------------02BAB309C4EC9D39236CAEF3" --------------02BAB309C4EC9D39236CAEF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > > Second quick observation: > > VALARM 0 > > RESPONSE-STATUS 0 if not creating a calendar > 1+ if creating a calendar > > Why is 1+ creating a calendar if it is in a VALARM? I think this is a > typo (or Im just not groking vAlarms anymore). The indentation is wrong and the order is reversed. What it's trying to say is that there are 0 VALARMs in the response. Then, disjoint and separate, there may be one or more RESPONSE-STATUS values if you create a calendar. This is better: Component/Property Presence Comment ------------------- -------- -------------------------------------- VCALENDAR 1+ TARGET 1 VERSION 1 MUST be 2.0 CMDID 0 or 1 MUST be returned if the request contained a CMDID RESPONSE-STATUS 0 if not creating a calendar 1+ if creating a calendar VALARM 0 VCAR 0+ RESPONSE-STATUS 1+ * 0 No other VCAR properties are present VCOMMAND 0 VEVENT 0+ RESPONSE-STATUS 1+ * 0 No other VEVENT properties are present etc. As I look at it, there's probably another mistake. Since VALARMs can be in VEVENTs and VTODOs, we should probably allow one or more RESPONSE-STATUS values to come back. So VEVENT should probably look like this: VEVENT 0+ RESPONSE-STATUS 1+ * 0 No other VEVENT properties are present VALARM 0+ RESPONSE-STATUS 1+ * 0 No other VEVENT properties are present Man, we really need something to show the indent levels. It's getting pretty hard to follow. -Steve --------------02BAB309C4EC9D39236CAEF3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:
 
Second quick observation:

VALARM               0

   RESPONSE-STATUS  0       if not creating a calendar
                    1+      if creating a calendar

Why is 1+ creating a calendar if it is in a VALARM?  I think this is a typo (or Im just not groking vAlarms anymore).

The indentation is wrong and the order is reversed. What it's trying to say is that there are 0 VALARMs in the response.  Then, disjoint and separate, there may be one or more RESPONSE-STATUS values if you create a calendar.

This is better:

Component/Property  Presence Comment
------------------- -------- --------------------------------------

VCALENDAR            1+
TARGET               1

VERSION              1       MUST be 2.0

CMDID                0 or 1  MUST be returned if the request contained
                             a CMDID

RESPONSE-STATUS      0       if not creating a calendar
                     1+      if creating a calendar

VALARM               0

VCAR                 0+
  RESPONSE-STATUS    1+
  *                  0       No other VCAR properties are present

VCOMMAND             0

VEVENT               0+
  RESPONSE-STATUS    1+
  *                  0       No other VEVENT properties are present

etc.

As I look at it, there's probably another mistake. Since VALARMs can be in VEVENTs and VTODOs, we should probably allow one or more RESPONSE-STATUS values to come back.  So VEVENT should probably look like this:

VEVENT               0+
  RESPONSE-STATUS    1+
  *                  0       No other VEVENT properties are present
  VALARM             0+
    RESPONSE-STATUS  1+
    *                0       No other VEVENT properties are present
Man, we really need something to show the indent levels. It's getting pretty hard to follow.

-Steve
  --------------02BAB309C4EC9D39236CAEF3-- --------------490C08FFB35F15D25CE5EC22 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: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 --------------490C08FFB35F15D25CE5EC22-- From owner-ietf-calendar@mail.imc.org Fri Sep 1 14:32:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17888 for ; Fri, 1 Sep 2000 14:32:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20412 for ietf-calendar-bks; Fri, 1 Sep 2000 11:13:10 -0700 (PDT) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20406 for ; Fri, 1 Sep 2000 11:13:08 -0700 (PDT) From: pregen@egenconsulting.com To: sman@netscape.com (Steve Mansour) Cc: Bruce_Kahn@iris.com, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: CAP Restriction Table: CREATE X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: Date: Fri, 1 Sep 2000 14:14:18 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 09/01/2000 02:14:21 PM, Serialize complete at 09/01/2000 02:14:22 PM, Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 09/01/2000 02:14:22 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00643F988525694D_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00643F988525694D_= Content-Type: text/plain; charset="us-ascii" Steve said: >> Man, we really need something to show the indent levels. It's getting pretty hard to follow Can we number the tables so that indents then can show up as subsets. I.e. 1.0 Vcommand 1.1 Vquery 1.1.1 etc. etc..... ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 00643F988525694D_= Content-Type: text/html; charset="us-ascii"
Steve said:

>> Man, we really need something to show the indent levels. It's getting pretty hard to follow

Can we number the tables so that indents then can show up as subsets.

I.e.        1.0  Vcommand
              1.1 Vquery
                1.1.1

etc. etc.....
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 00643F988525694D_=-- From owner-ietf-calendar@mail.imc.org Sun Sep 3 03:19:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01753 for ; Sun, 3 Sep 2000 03:19:29 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA14408 for ietf-calendar-bks; Sat, 2 Sep 2000 23:58:57 -0700 (PDT) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA14398 for ; Sat, 2 Sep 2000 23:58:54 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA25701 for ietf-calendar@imc.org; Sun, 3 Sep 2000 00:00:03 -0700 (PDT) Date: Sun, 3 Sep 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200009030700.AAA25701@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 Tue Sep 5 10:39:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03658 for ; Tue, 5 Sep 2000 10:39:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15825 for ietf-calendar-bks; Tue, 5 Sep 2000 07:16:10 -0700 (PDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15821 for ; Tue, 5 Sep 2000 07:16:07 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep04-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000905141708.SXTA4261.fep04-svc.swip.net@metaacer>; Tue, 5 Sep 2000 16:17:08 +0200 From: "Greg FitzPatrick" To: , =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= Cc: Subject: Last call on SKiCal Date: Tue, 5 Sep 2000 16:17:46 +0200 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Folks I would like to ask for a last call on a final review of the SKiCal draft. The I-D is located here and it has been updated since receiving comments from this list. http://www.imc.org/draft-many-ical-ski Greg From owner-ietf-calendar@mail.imc.org Tue Sep 5 17:12:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13928 for ; Tue, 5 Sep 2000 17:12:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA10333 for ietf-calendar-bks; Tue, 5 Sep 2000 13:46:40 -0700 (PDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10329 for ; Tue, 5 Sep 2000 13:46:38 -0700 (PDT) Received: from [192.168.1.11] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id NAA26535; Tue, 5 Sep 2000 13:47:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 5 Sep 2000 22:36:46 +0200 To: "Greg FitzPatrick" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Last call on SKiCal Cc: 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 16.17 +0200 00-09-05, Greg FitzPatrick wrote: >I would like to ask for a last call on a final review of the SKiCal draft. >The I-D is located here and it has been updated since receiving comments >from this list. > >http://www.imc.org/draft-many-ical-ski What is the name of the Internet-Draft? You should _only_ review things which exists in the Internet-Draft archive, and this so people know exactly what version of the document they are commenting on. Patrik From owner-ietf-calendar@mail.imc.org Wed Sep 6 06:18:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06545 for ; Wed, 6 Sep 2000 06:18:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA16457 for ietf-calendar-bks; Wed, 6 Sep 2000 03:01:30 -0700 (PDT) Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16448 for ; Wed, 6 Sep 2000 03:01:28 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep02-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000906100233.VZGI4854.fep02-svc.swip.net@metaacer>; Wed, 6 Sep 2000 12:02:33 +0200 From: "Greg FitzPatrick" To: =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= , Cc: Subject: SV: Last call on SKiCal Date: Wed, 6 Sep 2000 12:03:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The name of the draft is: draft-many-ical-ski-02.txt and it is found here http://www.ietf.org/internet-drafts/draft-many-ical-ski-02.txt -----Ursprungligt meddelande----- Från: Patrik Fältström [mailto:paf@cisco.com] Skickat: den 5 september 2000 22:37 Till: Greg FitzPatrick; pregen@egenconsulting.com Kopia: ietf-calendar@imc.org Ämne: Re: Last call on SKiCal At 16.17 +0200 00-09-05, Greg FitzPatrick wrote: >I would like to ask for a last call on a final review of the SKiCal draft. >The I-D is located here and it has been updated since receiving comments >from this list. > >http://www.imc.org/draft-many-ical-ski What is the name of the Internet-Draft? You should _only_ review things which exists in the Internet-Draft archive, and this so people know exactly what version of the document they are commenting on. Patrik From owner-ietf-calendar@mail.imc.org Wed Sep 6 08:51:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10725 for ; Wed, 6 Sep 2000 08:51:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA28228 for ietf-calendar-bks; Wed, 6 Sep 2000 05:34:51 -0700 (PDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA28218 for ; Wed, 6 Sep 2000 05:34:50 -0700 (PDT) Received: from [192.168.1.11] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA29304; Wed, 6 Sep 2000 05:35:42 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 6 Sep 2000 14:32:26 +0200 To: "Greg FitzPatrick" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: SV: Last call on SKiCal Cc: 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 12.03 +0200 00-09-06, Greg FitzPatrick wrote: >The name of the draft is: > >draft-many-ical-ski-02.txt > >and it is found here > >http://www.ietf.org/internet-drafts/draft-many-ical-ski-02.txt Thanks Greg! paf From owner-ietf-calendar@mail.imc.org Wed Sep 6 14:46:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20579 for ; Wed, 6 Sep 2000 14:46:41 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA19716 for ietf-calendar-bks; Wed, 6 Sep 2000 11:25:24 -0700 (PDT) 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 LAA19711 for ; Wed, 6 Sep 2000 11:25:21 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: iTIP Common Component Restriction Tables X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 14:10:40 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 02:31:25 PM, Serialize complete at 09/06/2000 02:31:26 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 02:31:26 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0063F8F985256952_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063F8F985256952_= Content-Type: text/plain; charset="us-ascii" In doing some more technical diving on the RFCs I ran across an apparent oversight (gasp!). In particular, in 3.1 Common Component Restriction Tables I found: Component/Property Presence ------------------- ---------------------------------------------- CALSCALE 0 or 1 PRODID 1 VERSION 1 Value MUST be "2.0" X-PROPERTY 0+ Of the 4 'root level' properties defined in RFC 2445, 3 are listed along with X-PROPERTY. It seems we forgot to include METHOD. Im not sure if this is an oversight or if there were technical reasons for it (I dont recall any) so I would like to add a new line to the table in the update that we are compiling: METHOD 0 or 1 Any disagreement? 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 0063F8F985256952_= Content-Type: text/html; charset="us-ascii"
In doing some more technical diving on the RFCs I ran across an apparent oversight (gasp!).  In particular, in 3.1 Common Component Restriction Tables I found:

   Component/Property  Presence
  ------------------- ----------------------------------------------
  CALSCALE            0 or 1
  PRODID              1
  VERSION             1       Value MUST be "2.0"
  X-PROPERTY          0+
Of the 4 'root level' properties defined in RFC 2445, 3 are listed along with X-PROPERTY.  It seems we forgot to include METHOD.  Im not sure if this is an oversight or if there were technical reasons for it (I dont recall any) so I would like to add a new line to the table in the update that we are compiling:

   METHOD              0 or 1
Any disagreement?

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 0063F8F985256952_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 6 14:47:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20593 for ; Wed, 6 Sep 2000 14:47:28 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA19720 for ietf-calendar-bks; Wed, 6 Sep 2000 11:25:25 -0700 (PDT) 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 LAA19715 for ; Wed, 6 Sep 2000 11:25:23 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: iTIP Common Component Restriction Tables (vAlarms) X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 14:25:08 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 02:31:27 PM, Serialize complete at 09/06/2000 02:31:28 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 02:31:28 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00654C0885256952_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00654C0885256952_= Content-Type: text/plain; charset="us-ascii" Ok, perhaps I should queue these into a longer posting but Im not going to. In diving deeper into 3.1 Common Component Restriction Tables I found that the vAlarm table is incomplete WRT RFC 2445 ABNF. In particular the RFC 2446 restriction table is: Component/Property Presence ------------------- ---------------------------------------------- VALARM 0+ ACTION 1 ATTACH 0+ DESCRIPTION 0 or 1 DURATION 0 or 1 if present REPEAT MUST be present REPEAT 0 or 1 if present DURATION MUST be present SUMMARY 0 or 1 TRIGGER 1 X-PROPERTY 0+ The oversight is that for Email alarms, not all properties are in the table above. From 2445: emailprop = 5*( [Snip] ; the following is REQUIRED, ; and MAY occur more than once attendee / The restriction table in RFC 2446 needs to be amended to include: ATTENDEE 0+ Any disagreement? (It is 0+ instead of 1+ since only EMail alarms have them...) 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 00654C0885256952_= Content-Type: text/html; charset="us-ascii"
Ok, perhaps I should queue these into a longer posting but Im not going to.  In diving deeper into 3.1 Common Component Restriction Tables I found that the vAlarm table is incomplete WRT RFC 2445 ABNF.  In particular the RFC 2446 restriction table is:

   Component/Property  Presence
  ------------------- ----------------------------------------------
  VALARM              0+
      ACTION          1
      ATTACH          0+
      DESCRIPTION     0 or 1
      DURATION        0 or 1  if present REPEAT MUST be present
      REPEAT          0 or 1  if present DURATION MUST be present
      SUMMARY         0 or 1
      TRIGGER         1
      X-PROPERTY      0+

The oversight is that for Email alarms, not all properties are in the table above.  From 2445:

     emailprop  = 5*(
[Snip]
               ; the following is REQUIRED,
               ; and MAY occur more than once

               attendee /
The restriction table in RFC 2446 needs to be amended to include:

       ATTENDEE        0+
Any disagreement? (It is 0+ instead of 1+ since only EMail alarms have them...)

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 00654C0885256952_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 6 22:33:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28039 for ; Wed, 6 Sep 2000 22:33:09 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA20006 for ietf-calendar-bks; Wed, 6 Sep 2000 19:10:44 -0700 (PDT) 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 TAA20002 for ; Wed, 6 Sep 2000 19:10:43 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: iTIP & Repeat/DUE/Duration restrictions X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 22:16:03 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 10:16:47 PM, Serialize complete at 09/06/2000 10:16:47 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000C2FF485256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000C2FF485256953_= Content-Type: text/plain; charset="us-ascii" I hope these posting are not being lost in the overwhelming slience on the list the past couple of days. :^) Actually, while getting down and dirty with some vEvent or vToDo restriction tables I found what could be an oversight in our restriction tables. In 3.2.2 REQUEST (and other 3.2.x and 3.4.x subsections) the restriction tables in part read: DTEND 0 or 1 if present DURATION MUST NOT be present DURATION 0 or 1 if present DTEND MUST NOT be present and RDATE 0+ and RRULE 0+ Now if you are the cautious type you may see what could be restriction table oddity: it is possible to have a vEvent / vToDo that has NO DTEND/DUE or DURATION value but does have an RDATE / RRULE. If the first entry enver ends (at least for vEvents) then how can it repeat since the initial instance cannot complete? One can assume that 'overlapping' entries are allowed depending on how you view repeating entries but I dont know of any C&S system that allows open ended entries that can potentially repeat infinitely (ie: RRULE w/no COUNT or UNTIL). Since we are looking at cleaning up iTIP (and in the interest of KISS) I would like to suggest that we ammend the tables to preclude an entry from repeating if it does NOT have a finite length or end/due date & time. Any disagreement? 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 000C2FF485256953_= Content-Type: text/html; charset="us-ascii"
I hope these posting are not being lost in the overwhelming slience on the list the past couple of days. :^)

  Actually, while getting down and dirty with some vEvent or vToDo restriction tables I found what could be an oversight in our restriction tables.  In 3.2.2 REQUEST (and other 3.2.x and 3.4.x subsections) the restriction tables in part read:

    DTEND           0 or 1  if present DURATION MUST NOT be present
   DURATION        0 or 1  if present DTEND MUST NOT be present
and
    RDATE             0+
and
   RRULE             0+
  Now if you are the cautious type you may see what could be restriction table oddity: it is possible to have a vEvent / vToDo that has NO DTEND/DUE or DURATION value but does have an RDATE / RRULE.  If the first entry enver ends (at least for vEvents) then how can it repeat since the initial instance cannot complete?  One can assume that 'overlapping' entries are allowed depending on how you view repeating entries but I dont know of any C&S system that allows open ended entries that can potentially repeat infinitely (ie: RRULE w/no COUNT or UNTIL).

  Since we are looking at cleaning up iTIP (and in the interest of KISS) I would like to suggest that we ammend the tables to preclude an entry from repeating if it does NOT have a finite length or end/due date & time.   Any disagreement?

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 000C2FF485256953_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 6 22:44:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28114 for ; Wed, 6 Sep 2000 22:44:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA20161 for ietf-calendar-bks; Wed, 6 Sep 2000 19:20:55 -0700 (PDT) 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 TAA20157 for ; Wed, 6 Sep 2000 19:20:54 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: SKiCal & Roles X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 22:26:16 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 10:26:58 PM, Serialize complete at 09/06/2000 10:26:58 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000D1F6E85256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000D1F6E85256953_= Content-Type: text/plain; charset="us-ascii" Ok, I revisited SKiCal draft for another pass or two. One quick thing that poped out was the addition of "DIPROLE", "DITROLE" and "DITHROLE" to the current "ROLE" property parameter. Im 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). 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 000D1F6E85256953_= Content-Type: text/html; charset="us-ascii"
Ok, I revisited SKiCal draft for another pass or two.  One quick thing that poped out was the addition of "DIPROLE", "DITROLE" and "DITHROLE" to the current "ROLE" property parameter.  Im 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).

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 000D1F6E85256953_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 6 22:49:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28165 for ; Wed, 6 Sep 2000 22:49:57 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA20490 for ietf-calendar-bks; Wed, 6 Sep 2000 19:35:56 -0700 (PDT) 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 TAA20484 for ; Wed, 6 Sep 2000 19:35:54 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: SKiCal & QUALVALUE X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 22:41:15 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 10:41:58 PM, Serialize complete at 09/06/2000 10:41:59 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 10:41:59 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000E7E4E85256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000E7E4E85256953_= Content-Type: text/plain; charset="us-ascii" Section 2.5 Qualification value parameter shows an incorrect ABNF for the new property parameter. The ABNF is: qualvalparam = text but it really needs to be: qualvalparam = "QUALVALUE" = text or probably even: qualvalparam = "QUALVALUE" = ( x-name ; Experimental type / iana-token ) ; Other IANA registered ; type Also, are there any suggested value (like there were with QUALTYPE and QUALRULE)?? 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 000E7E4E85256953_= Content-Type: text/html; charset="us-ascii"
Section 2.5  Qualification value parameter shows an incorrect ABNF for the new property parameter.  The ABNF is:

    qualvalparam = text

but it really needs to be:

    qualvalparam = "QUALVALUE" = text

or probably even:

    qualvalparam = "QUALVALUE" =
                        ( x-name                ; Experimental type
                       / iana-token )          ; Other IANA registered
                                               ; type
Also, are there any suggested value (like there were with QUALTYPE and QUALRULE)??

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 000E7E4E85256953_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 6 22:51:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28187 for ; Wed, 6 Sep 2000 22:51:58 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA20373 for ietf-calendar-bks; Wed, 6 Sep 2000 19:31:00 -0700 (PDT) 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 TAA20369 for ; Wed, 6 Sep 2000 19:30:58 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: SKiCal ABNF Quirk X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 22:36:15 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 10:37:02 PM, Serialize complete at 09/06/2000 10:37:02 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000E096385256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000E096385256953_= Content-Type: text/plain; charset="us-ascii" Ok, Ill admit Im no ABNF guru but I think the ABNF in the draft needs to be changed to be 'proper'. The format does not quite seem normal based on my limited RFC 2445-2447 ABNF exposure but Ill see if I can put my finger on it. In the SKiCal draft the first example is: Personroleparam = "DIPROLE" "=" text ; It is RECOMMENDED that the text value be ; chosen from a list, as described in section 4 ; of this memo. One example of such a list is ; given here: "PERFORMER" ; Appearing at the event "CREATOR" ; Not necessarily present "COMPOSER" "CONDUCTOR" "ARTIST" "EDITOR" "PRODUCER" "GUIDE" "SPEAKER" "CHAIR" "PRESENT" ; At the event "REFERENCED" ; Not present at the event "INVITED" A comperable one from RFC 2445 is: cutypeparam = "CUTYPE" "=" ("INDIVIDUAL" ; An individual / "GROUP" ; A group of individuals / "RESOURCE" ; A physical resource / "ROOM" ; A room resource / "UNKNOWN" ; Otherwise not known / x-name ; Experimental type / iana-token) ; Other IANA registered ; type ; Default is INDIVIDUAL The SKiCal examples' first line defines the value as 'text' but then it goes on to explain more and give some explicit values. The iCalendar example lists the codified values and then "leaves it open" by allowing "x-name" and "iana-token" values which are previously defined as essentially "text". So, either SKiCal is using a slightly different but allowable ABNF format or the ABNF needs to be slightly changed to style shown above. Can some ABNF Guru please comment on this?? 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 000E096385256953_= Content-Type: text/html; charset="us-ascii"
Ok, Ill admit Im no ABNF guru but I think the ABNF in the draft needs to be changed to be 'proper'.  The format does not quite seem normal based on my limited RFC 2445-2447 ABNF exposure but Ill see if I can put my finger on it.  In the SKiCal draft the first example is:

     Personroleparam  = "DIPROLE" "=" text
                      ; It is RECOMMENDED that the text value be  
                      ; chosen from a list, as described in section 4
                      ; of this memo. One example of such a list is  
                      ; given here:

                       "PERFORMER"  ; Appearing at the event  
                       "CREATOR"    ; Not necessarily present  
                       "COMPOSER"
                       "CONDUCTOR"
                       "ARTIST"
                       "EDITOR"
                       "PRODUCER"
                       "GUIDE"
                       "SPEAKER"
                       "CHAIR"  
                       "PRESENT"    ; At the event
                       "REFERENCED" ; Not present at the event
                       "INVITED"

A comperable one from RFC 2445 is:

     cutypeparam        = "CUTYPE" "="
                        ("INDIVIDUAL"          ; An individual
                       / "GROUP"               ; A group of individuals
                       / "RESOURCE"            ; A physical resource
                       / "ROOM"                ; A room resource
                       / "UNKNOWN"             ; Otherwise not known
                       / x-name                ; Experimental type
                       / iana-token)           ; Other IANA registered
                                               ; type
    ; Default is INDIVIDUAL
The SKiCal examples' first line defines the value as 'text' but then it goes on to explain more and give some explicit values.  The iCalendar example lists the codified values and then "leaves it open" by allowing "x-name" and "iana-token" values which are previously defined as essentially "text".  So, either SKiCal is using a slightly different but allowable ABNF format or the ABNF needs to be slightly changed to style shown above.

Can some ABNF Guru please comment on this??

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 000E096385256953_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 6 22:55:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28214 for ; Wed, 6 Sep 2000 22:55:57 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA20625 for ietf-calendar-bks; Wed, 6 Sep 2000 19:41:18 -0700 (PDT) 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 TAA20621 for ; Wed, 6 Sep 2000 19:41:16 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: SKiCal extensibility X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 22:46:38 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 10:47:20 PM, Serialize complete at 09/06/2000 10:47:20 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000EFC9185256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000EFC9185256953_= Content-Type: text/plain; charset="us-ascii" Making sure that we learn a good lesson from iCalendar, I noticed that some of the new property parameters (and possibly the properties) have very very restrictive ABNFs in that they do not allow for future expandability. This is not good. For example, section 2.6 Qualification status parameter has: qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" / "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / "NOTPROHIBITED") (Please fold values to separate lines...) While this may appear OK at first pass, it precludes any new values that are not expressly put in the ABNF. The lesson from iCalendar would make the ABNF: qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" / "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / "NOTPROHIBITED" / x-name / iana-token ) so that new values (or experimantal ones) can be added w/o breaking some stricter interpretations!! 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 000EFC9185256953_= Content-Type: text/html; charset="us-ascii"
Making sure that we learn a good lesson from iCalendar, I noticed that some of the new property parameters (and possibly the properties) have very very restrictive ABNFs  in that they do not allow for future expandability.  This is not good.

For example, section 2.6  Qualification status parameter has:

     qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" /  
                    "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" /  
                    "NOTPROHIBITED")

(Please fold values to separate lines...) While this may appear OK at first pass, it precludes any new values that are not expressly put in the ABNF.  The lesson from iCalendar would make the ABNF:

     qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" /  
                    "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" /  
                    "NOTPROHIBITED" / x-name / iana-token )

so that new values (or experimantal ones) can be added w/o breaking some stricter interpretations!!

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 000EFC9185256953_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 6 23:13:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28455 for ; Wed, 6 Sep 2000 23:13:46 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA21019 for ietf-calendar-bks; Wed, 6 Sep 2000 19:58:54 -0700 (PDT) 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 TAA21014 for ; Wed, 6 Sep 2000 19:58:51 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: SKiCal: 2.7 Value status X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 23:04:08 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 11:04:55 PM, Serialize complete at 09/06/2000 11:04:55 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 001096C685256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 001096C685256953_= Content-Type: text/plain; charset="us-ascii" Ok, after chewing on the concept in 2.7 Value status I thought that may be some cases that were not listed. For example, instead of: TICKETS-AT;QUALTYPE=PRE-BOOKING;QUALRULE=REQUIRED;DTSTA RT=19991104;VALUESTATUS=AVAILABLE:At the ticket booth outside of the concert hall what about the case where the status is Unknown (ie: The Concierge does not know if there are tickets available or not for the evening concert): TICKETS-AT;QUALTYPE=PRE-BOOKING;QUALRULE=REQUIRED;DTSTA RT=19991104;VALUESTATUS=UNKNOWN:At the ticket booth outside of the concert hall Also, the description of the VALUESTATUS parameter is not quite the same way that it is shown in usage. The text says: Purpose: To specify the status of a WHOW property value. but that implies that the property value for TICKETS-AT is available, irregardless of what it is. However the usage is one where the VALUESTATUS is really an indicator of the properties physical presence. In other words, "At the ticket booth outside the concert hall" is the TICKETS-AT value and it is there but the meaning is really TICKETs are AVAILABLE. The VALUESTATUS is more accurately an indicator of the WHOW properties physical presence (at least for the AVAILABLE case, not quite the same for, say, ENFORCED). The description of this new property parameter needs to be tightened up to avoid any confusion as to its proper use/meaning. Bruce Note to SKiCal draft authors: Please put complimentary values on the same line by themselves or on separate ones entirely. This: valstatparam = "VALUESTATUS" "=" *1("REQUIRED" / "NOTREQUIRED" / "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / "NOTPROHIBITED" / "ENFORCED" / "NOTENFORCED" / "AVAILABLE" / "NOTAVAILABLE" / "ACCEPTED" / "NOTACCEPTED" / "CONFIRMED" / "NOTCONFIRMED" / "ALLOWED" / "NOTALLOWED") is harder to notice pairs than: valstatparam = "VALUESTATUS" "=" *1("REQUIRED" / "NOTREQUIRED" / "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / "NOTPROHIBITED" / "ENFORCED" / "NOTENFORCED" / "AVAILABLE" / "NOTAVAILABLE" / "ACCEPTED" / "NOTACCEPTED" / "CONFIRMED" / "NOTCONFIRMED" / "ALLOWED" / "NOTALLOWED") =========================================================================== 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 001096C685256953_= Content-Type: text/html; charset="us-ascii"
Ok, after chewing on the concept in 2.7  Value status I thought that may be some cases that were not listed. For example, instead of:

     TICKETS-AT;QUALTYPE=PRE-BOOKING;QUALRULE=REQUIRED;DTSTA
     RT=19991104;VALUESTATUS=AVAILABLE:At the ticket booth outside of  
     the concert hall

what about the case where the status is Unknown (ie: The Concierge does not know if there are tickets available or not for the evening concert):

     TICKETS-AT;QUALTYPE=PRE-BOOKING;QUALRULE=REQUIRED;DTSTA
     RT=19991104;VALUESTATUS=UNKNOWN:At the ticket booth outside of  
     the concert hall

Also, the description of the VALUESTATUS parameter is not quite the same way that it is shown in usage.  The text says:

   Purpose: To specify the status of a WHOW property value.

but that implies that the property value for TICKETS-AT is available, irregardless of what it is.  However the usage is one where the VALUESTATUS is really an indicator of the properties physical presence.  In other words, "At the ticket booth outside the concert hall" is the TICKETS-AT value and it is there but the meaning is really TICKETs are AVAILABLE.   The VALUESTATUS is more accurately an indicator of the WHOW properties physical presence (at least for the AVAILABLE case, not quite the same for, say, ENFORCED).

The description of this new property parameter needs to be tightened up to avoid any confusion as to its proper use/meaning.

Bruce

Note to SKiCal draft authors: Please put complimentary values on the same line by themselves or on separate ones entirely.  This:

   valstatparam = "VALUESTATUS" "=" *1("REQUIRED" / "NOTREQUIRED" /
           "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" /
           "NOTPROHIBITED" / "ENFORCED" / "NOTENFORCED" /
           "AVAILABLE" / "NOTAVAILABLE" / "ACCEPTED" /
           "NOTACCEPTED" / "CONFIRMED" / "NOTCONFIRMED" /
           "ALLOWED" / "NOTALLOWED")

is harder to notice pairs than:

   valstatparam = "VALUESTATUS" "="
            *1("REQUIRED"    / "NOTREQUIRED" /
              "RECOMMENDED" / "NOTRECOMMENDED" /
               "PROHIBITED"  / "NOTPROHIBITED" /
               "ENFORCED"    / "NOTENFORCED" /
              "AVAILABLE"   / "NOTAVAILABLE" /
               "ACCEPTED"    / "NOTACCEPTED" /
               "CONFIRMED"   / "NOTCONFIRMED" /
              "ALLOWED"     / "NOTALLOWED")
===========================================================================
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 001096C685256953_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 6 23:18:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28571 for ; Wed, 6 Sep 2000 23:18:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA21160 for ietf-calendar-bks; Wed, 6 Sep 2000 20:03:41 -0700 (PDT) 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 UAA21155 for ; Wed, 6 Sep 2000 20:03:40 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: SKiCal: SKiCal specific component properties X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 23:09:00 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 11:09:44 PM, Serialize complete at 09/06/2000 11:09:44 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 001108CF85256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 001108CF85256953_= Content-Type: text/plain; charset="us-ascii" In section 3. SKiCal specific component properties there is text that says: In addition, the following component properties are defined in this memo. eventprop = *( ... However, SKiCal is not defining vEvent but rather extending it with new properties. This could cause some confusion if the readers interpret the ABNF as shown to be an entirely new eventprop than defined in RFC 2445 instead of the ABNF being extensions to RFC 2445. 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 001108CF85256953_= Content-Type: text/html; charset="us-ascii"
In section 3. SKiCal specific component properties  there is text that says:

                                                                                                                               In
  addition, the following component properties are defined in this
  memo.

   eventprop  = *(
...

However, SKiCal is not defining vEvent but rather extending it with new properties.  This could cause some confusion if the readers interpret the ABNF as shown to be an entirely new eventprop than defined in RFC 2445 instead of the ABNF being extensions to RFC 2445.

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 001108CF85256953_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 6 23:35:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29136 for ; Wed, 6 Sep 2000 23:35:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA21321 for ietf-calendar-bks; Wed, 6 Sep 2000 20:11:27 -0700 (PDT) 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 UAA21317 for ; Wed, 6 Sep 2000 20:11:24 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: SKiCal: SKiCal specific component properties (Part 2) X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 6 Sep 2000 23:16:41 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/06/2000 11:17:28 PM, Serialize complete at 09/06/2000 11:17:28 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0011BCE285256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0011BCE285256953_= Content-Type: text/plain; charset="us-ascii" Argh, a bit too tired and clicked on the send button instead of my SKiCal window tab (just above the button)... I did see the text in 3. SKiCal specific component properties that mentioned that SKiCal was extending the RFC 2445 ABNF: Therefore any component property, which MAY appear in a VEVENT iCalendar component, is also allowed in a SKiCal object. but the ABNF that followed it could be misread. That was my point in my runt posting... I also am curious about the phrase found at the bottom of this section, a "term": It is RECOMMENDED that publishers chose the terms used as TEXT type property values from authoritative lists of terms. Those publishers who consequently use terms found in such lists will facilitate extensive automatic treatment of their information. There is no clear definition of what 'term' is but Im guessing its "values". Can the SKiCal authors please define this term better before using it?? Also the talk of ""MANAGEMENT" header (Calendar object management)" is also a bit confusing since these are not RFC terms. Can someone please rephrase the contents of the last paragraph in that section a bit so it is clearer?? 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 0011BCE285256953_= Content-Type: text/html; charset="us-ascii"
Argh, a bit too tired and clicked on the send button instead of my SKiCal window tab (just above the button)...

I did see the text in 3. SKiCal specific component properties that mentioned that SKiCal was extending the RFC 2445 ABNF:

         Therefore any component property, which MAY appear in a
  VEVENT iCalendar component, is also allowed in a SKiCal object.

but the ABNF that followed it could be misread.  That was my point in my runt posting...

I also am curious about the phrase found at the bottom of this section, a "term":

   It is RECOMMENDED that publishers chose the terms used as TEXT type
  property values from authoritative lists of terms. Those publishers
  who consequently use terms found in such lists will facilitate
  extensive automatic treatment of their information.

There is no clear definition of what 'term' is but Im guessing its "values".  Can the SKiCal authors please define this term better before using it??

Also the talk of ""MANAGEMENT" header (Calendar object management)" is also a bit confusing since these are not RFC terms.  Can someone please rephrase the contents of the last paragraph in that section a bit so it is clearer??

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 0011BCE285256953_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 00:29:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29590 for ; Thu, 7 Sep 2000 00:29:49 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA28576 for ietf-calendar-bks; Wed, 6 Sep 2000 21:09:29 -0700 (PDT) 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 VAA28572 for ; Wed, 6 Sep 2000 21:09:27 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e8740QV05279 for ; Wed, 6 Sep 2000 21:00:26 -0700 (PDT) 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 G0I0XO00.7ZL; Wed, 6 Sep 2000 21:10:36 -0700 Message-ID: <39B7163C.3F6DB395@netscape.com> Date: Wed, 06 Sep 2000 21:14:52 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org Subject: Re: iTIP Common Component Restriction Tables References: Content-Type: multipart/mixed; boundary="------------758DC2DAAE7E41467690AF4F" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------758DC2DAAE7E41467690AF4F Content-Type: multipart/alternative; boundary="------------3EDB8973C1D6A4852DC99B47" --------------3EDB8973C1D6A4852DC99B47 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yipes! Well it turns out that METHOD is actually called out explicitly in each of the restriction tables for the methods. But I see no problem in adding the line stating that there can be 0 or 1 method. Hey wait. Isn't METHOD always present? Can anyone think of a situation in iTIP where it's not? -Steve Bruce_Kahn@iris.com wrote: > > In doing some more technical diving on the RFCs I ran across an > apparent oversight (gasp!). In particular, in 3.1 Common Component > Restriction Tables I found: > > Component/Property Presence > ------------------- ---------------------------------------------- > CALSCALE 0 or 1 > PRODID 1 > VERSION 1 Value MUST be "2.0" > X-PROPERTY 0+ > > Of the 4 'root level' properties defined in RFC 2445, 3 are listed > along with X-PROPERTY. It seems we forgot to include METHOD. Im not > sure if this is an oversight or if there were technical reasons for it > (I dont recall any) so I would like to add a new line to the table in > the update that we are compiling: > > METHOD 0 or 1 > > Any disagreement? > > 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... --------------3EDB8973C1D6A4852DC99B47 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Yipes!

Well it turns out that METHOD is actually called out explicitly in each of the restriction tables for the methods. But I see no problem in adding the line stating that there can be 0 or 1 method.

Hey wait. Isn't METHOD always present?  Can anyone think of a situation in iTIP where it's not?

-Steve

Bruce_Kahn@iris.com wrote:

 
In doing some more technical diving on the RFCs I ran across an apparent oversight (gasp!).  In particular, in 3.1 Common Component Restriction Tables I found:

   Component/Property  Presence
  ------------------- ----------------------------------------------
  CALSCALE            0 or 1
  PRODID              1
  VERSION             1       Value MUST be "2.0"
  X-PROPERTY          0+

Of the 4 'root level' properties defined in RFC 2445, 3 are listed along with X-PROPERTY.  It seems we forgot to include METHOD.  Im not sure if this is an oversight or if there were technical reasons for it (I dont recall any) so I would like to add a new line to the table in the update that we are compiling:

   METHOD              0 or 1

Any disagreement?

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...

--------------3EDB8973C1D6A4852DC99B47-- --------------758DC2DAAE7E41467690AF4F 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: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 --------------758DC2DAAE7E41467690AF4F-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 01:38:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03991 for ; Thu, 7 Sep 2000 01:38:55 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA29611 for ietf-calendar-bks; Wed, 6 Sep 2000 22:21:11 -0700 (PDT) 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 WAA29607 for ; Wed, 6 Sep 2000 22:21:10 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e875C8V09244 for ; Wed, 6 Sep 2000 22:12:08 -0700 (PDT) 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 G0I49600.0ZM; Wed, 6 Sep 2000 22:22:18 -0700 Message-ID: <39B7270A.555177A4@netscape.com> Date: Wed, 06 Sep 2000 22:26:34 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org Subject: Re: iTIP & Repeat/DUE/Duration restrictions References: Content-Type: multipart/mixed; boundary="------------841E1E48EC09E73CAF75CC0C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------841E1E48EC09E73CAF75CC0C Content-Type: multipart/alternative; boundary="------------E2057322D11994F2C15A05C9" --------------E2057322D11994F2C15A05C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > I hope these posting are not being lost in the overwhelming slience on > the list the past couple of days. :^) hey! I'm reading it. > Actually, while getting down and dirty with some vEvent or vToDo > restriction tables I found what could be an oversight in our > restriction tables. In 3.2.2 REQUEST (and other 3.2.x and 3.4.x > subsections) the restriction tables in part read: > > DTEND 0 or 1 if present DURATION MUST NOT be present > DURATION 0 or 1 if present DTEND MUST NOT be present > and > RDATE 0+ > and > RRULE 0+ > > Now if you are the cautious type you may see what could be > restriction table oddity: it is possible to have a vEvent / vToDo that > has NO DTEND/DUE or DURATION value but does have an RDATE / RRULE. If > the first entry enver ends (at least for vEvents) then how can it > repeat since the initial instance cannot complete? One can assume > that 'overlapping' entries are allowed depending on how you view > repeating entries but I dont know of any C&S system that allows open > ended entries that can potentially repeat infinitely (ie: RRULE w/no > COUNT or UNTIL). > > Since we are looking at cleaning up iTIP (and in the interest of > KISS) I would like to suggest that we ammend the tables to preclude an > entry from repeating if it does NOT have a finite length or end/due > date & time. Any disagreement? Jeez, how do you dream this stuff up ? :-) Sounds reasonable though. In fact, totally independent of iTIP, this sounds like a sanity check on the makeup of a repeating component. Is this something that should go in iCalendar? -Steve --------------E2057322D11994F2C15A05C9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:
I hope these posting are not being lost in the overwhelming slience on the list the past couple of days. :^)
hey!  I'm reading it.
  Actually, while getting down and dirty with some vEvent or vToDo restriction tables I found what could be an oversight in our restriction tables.  In 3.2.2 REQUEST (and other 3.2.x and 3.4.x subsections) the restriction tables in part read:

    DTEND           0 or 1  if present DURATION MUST NOT be present
   DURATION        0 or 1  if present DTEND MUST NOT be present
and
    RDATE             0+
and
   RRULE             0+

  Now if you are the cautious type you may see what could be restriction table oddity: it is possible to have a vEvent / vToDo that has NO DTEND/DUE or DURATION value but does have an RDATE / RRULE.  If the first entry enver ends (at least for vEvents) then how can it repeat since the initial instance cannot complete?  One can assume that 'overlapping' entries are allowed depending on how you view repeating entries but I dont know of any C&S system that allows open ended entries that can potentially repeat infinitely (ie: RRULE w/no COUNT or UNTIL).

  Since we are looking at cleaning up iTIP (and in the interest of KISS) I would like to suggest that we ammend the tables to preclude an entry from repeating if it does NOT have a finite length or end/due date & time.   Any disagreement?

Jeez, how do you dream this stuff up ?  :-)   Sounds reasonable though. In fact, totally independent of iTIP, this sounds like a sanity check on the makeup of a repeating component.  Is this something that should go in iCalendar?

-Steve
  --------------E2057322D11994F2C15A05C9-- --------------841E1E48EC09E73CAF75CC0C 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: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 --------------841E1E48EC09E73CAF75CC0C-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 01:40:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04162 for ; Thu, 7 Sep 2000 01:40:19 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA29516 for ietf-calendar-bks; Wed, 6 Sep 2000 22:17:29 -0700 (PDT) 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 WAA29512 for ; Wed, 6 Sep 2000 22:17:28 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e8758QV08991 for ; Wed, 6 Sep 2000 22:08:26 -0700 (PDT) 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 G0I43100.N26; Wed, 6 Sep 2000 22:18:37 -0700 Message-ID: <39B7262C.30B7F8BF@netscape.com> Date: Wed, 06 Sep 2000 22:22:52 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org Subject: Re: iTIP Common Component Restriction Tables (vAlarms) References: Content-Type: multipart/mixed; boundary="------------CC3576CB8011BA3031128A4B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CC3576CB8011BA3031128A4B Content-Type: multipart/alternative; boundary="------------53A5F905A401F91D88FD0341" --------------53A5F905A401F91D88FD0341 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > ... > The restriction table in RFC 2446 needs to be amended to include: > > ATTENDEE 0+ > > Any disagreement? (It is 0+ instead of 1+ since only EMail alarms have > them...) OK, we can update the valarm table in 3.1 to include: ATTENDEE 0+ Can only be present when the ACTION property has the value EMAIL -Steve --------------53A5F905A401F91D88FD0341 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote:

...
The restriction table in RFC 2446 needs to be amended to include:

       ATTENDEE        0+

Any disagreement? (It is 0+ instead of 1+ since only EMail alarms have them...)

OK, we can update the valarm table in 3.1 to include:

    ATTENDEE       0+      Can only be present when the ACTION
                           property has the value EMAIL

-Steve
  --------------53A5F905A401F91D88FD0341-- --------------CC3576CB8011BA3031128A4B 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: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 --------------CC3576CB8011BA3031128A4B-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 08:50:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15579 for ; Thu, 7 Sep 2000 08:50:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA13364 for ietf-calendar-bks; Thu, 7 Sep 2000 05:32:17 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13357; Thu, 7 Sep 2000 05:32:14 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA07694; Thu, 7 Sep 2000 08:35:37 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA23491; Thu, 7 Sep 2000 08:33:21 -0400 (EDT) To: sman@netscape.com (Steve Mansour) Cc: Bruce_Kahn@iris.com, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP & Repeat/DUE/Duration restrictions X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Thu, 7 Sep 2000 08:32:55 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08312000 |August 31, 2000) at 09/07/2000 08:32:58 AM, Serialize complete at 09/07/2000 08:32:58 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00405D04C1256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00405D04C1256953_= Content-Type: text/plain; charset="us-ascii" Wait...Not so fast! I can have an event that has no DTEND, DUE or DURATION yet repeats. One case is the following: ... DTSTART;VALUE=DATE:20000714 RRULE:FREQ=YEARLY SUMMARY:Bastille Day Fete ... -- Frank --=_alternative 00405D04C1256953_= Content-Type: text/html; charset="us-ascii"
Wait...Not so fast!

I can have an event that has no DTEND, DUE or DURATION yet repeats. One case is the following:

...
DTSTART;VALUE=DATE:20000714
RRULE:FREQ=YEARLY
SUMMARY:Bastille Day Fete
...

-- Frank --=_alternative 00405D04C1256953_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 08:50:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15590 for ; Thu, 7 Sep 2000 08:50:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA13365 for ietf-calendar-bks; Thu, 7 Sep 2000 05:32:17 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13356; Thu, 7 Sep 2000 05:32:14 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA07691; Thu, 7 Sep 2000 08:35:36 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA23482; Thu, 7 Sep 2000 08:33:20 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: iTIP & Repeat/DUE/Duration restrictions X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Thu, 7 Sep 2000 08:32:55 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08312000 |August 31, 2000) at 09/07/2000 08:32:57 AM, Serialize complete at 09/07/2000 08:32:57 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 003FDA30C1256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 003FDA30C1256953_= Content-Type: text/plain; charset="us-ascii" Bruce: Looks like an oversight to me. Steve and Doug? -- Frank --=_alternative 003FDA30C1256953_= Content-Type: text/html; charset="us-ascii"
Bruce:

Looks like an oversight to me. Steve and Doug?

-- Frank --=_alternative 003FDA30C1256953_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 08:52:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15605 for ; Thu, 7 Sep 2000 08:52:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA13370 for ietf-calendar-bks; Thu, 7 Sep 2000 05:32:18 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13366; Thu, 7 Sep 2000 05:32:17 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA07710; Thu, 7 Sep 2000 08:35:38 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA23501; Thu, 7 Sep 2000 08:33:23 -0400 (EDT) To: sman@netscape.com (Steve Mansour) Cc: Bruce_Kahn@iris.com, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP Common Component Restriction Tables X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Thu, 7 Sep 2000 08:32:58 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08312000 |August 31, 2000) at 09/07/2000 08:32:59 AM, Serialize complete at 09/07/2000 08:33:00 AM, Serialize by Router on ISMail/CAM/M/Lotus(Build V505_08312000 |August 31, 2000) at 09/07/2000 08:33:00 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00419F0EC1256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00419F0EC1256953_= Content-Type: text/plain; charset="us-ascii" Effectively, in iTIP METHOD is always present. If absent, it is assumed to be PUBLISH. Right? --=_alternative 00419F0EC1256953_= Content-Type: text/html; charset="us-ascii"
Effectively, in iTIP METHOD is always present. If absent, it is assumed to be PUBLISH. Right? --=_alternative 00419F0EC1256953_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 10:45:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17363 for ; Thu, 7 Sep 2000 10:45:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15508 for ietf-calendar-bks; Thu, 7 Sep 2000 07:24:31 -0700 (PDT) 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 HAA15503 for ; Thu, 7 Sep 2000 07:24:30 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e87EJcu28563 for ; Thu, 7 Sep 2000 07:19:38 -0700 (PDT) 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 G0ITES00.UF1; Thu, 7 Sep 2000 07:25:40 -0700 Message-ID: <39B7A664.1A2B6F8A@netscape.com> Date: Thu, 07 Sep 2000 07:29:57 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP & Repeat/DUE/Duration restrictions References: Content-Type: multipart/mixed; boundary="------------9F5C5F7F67E9F668CF7C8FFC" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9F5C5F7F67E9F668CF7C8FFC Content-Type: multipart/alternative; boundary="------------16E56702D8A17C0946F3710E" --------------16E56702D8A17C0946F3710E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > Wait...Not so fast! > > I can have an event that has no DTEND, DUE or DURATION yet repeats. > One case is the following: > > ... > DTSTART;VALUE=DATE:20000714 > RRULE:FREQ=YEARLY > SUMMARY:Bastille Day Fete > ... This one does have a duration, sort of. It's associated with a day. I think the gist is that a repeating event cannot have a duration that exceeds the interval between recurrences. -Steve --------------16E56702D8A17C0946F3710E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote:

Wait...Not so fast!

I can have an event that has no DTEND, DUE or DURATION yet repeats. One case is the following:

...
DTSTART;VALUE=DATE:20000714
RRULE:FREQ=YEARLY
SUMMARY:Bastille Day Fete
...

This one does have a duration, sort of. It's associated with a day.

I think the gist is that a repeating event cannot have a duration that exceeds the interval between recurrences.

-Steve --------------16E56702D8A17C0946F3710E-- --------------9F5C5F7F67E9F668CF7C8FFC 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: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 --------------9F5C5F7F67E9F668CF7C8FFC-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 10:48:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17427 for ; Thu, 7 Sep 2000 10:48:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15596 for ietf-calendar-bks; Thu, 7 Sep 2000 07:29:59 -0700 (PDT) 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 HAA15592 for ; Thu, 7 Sep 2000 07:29:58 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e87EKvV26729 for ; Thu, 7 Sep 2000 07:20:57 -0700 (PDT) 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 G0ITNW00.MFO; Thu, 7 Sep 2000 07:31:08 -0700 Message-ID: <39B7A7AC.E8B80B07@netscape.com> Date: Thu, 07 Sep 2000 07:35:24 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP Common Component Restriction Tables References: Content-Type: multipart/mixed; boundary="------------3A3A30F410E4C9738334DA5B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3A3A30F410E4C9738334DA5B Content-Type: multipart/alternative; boundary="------------53809B4B452BB38C64B02B40" --------------53809B4B452BB38C64B02B40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I took a quick scan through iTIP. I could have missed it, but I didn't catch anything that said we should assume PUBLISH if METHOD is not present. I think we're safer in making METHOD a MUST. The whole idea behind iTIP is to send an an iCalendar object to someone and give it an associated action. METHOD defines the action. Seems like it needs to be present. -Steve Frank_Dawson@lotus.com wrote: > > Effectively, in iTIP METHOD is always present. If absent, it is > assumed to be PUBLISH. Right? --------------53809B4B452BB38C64B02B40 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I took a quick scan through iTIP. I could have missed it, but I didn't catch anything that said we should assume PUBLISH if METHOD is not present. I think we're safer in making METHOD a MUST. The whole idea behind iTIP is to send an an iCalendar object to someone and give it an associated action.  METHOD defines the action. Seems like it needs to be present.

-Steve

Frank_Dawson@lotus.com wrote:

 
Effectively, in iTIP METHOD is always present. If absent, it is assumed to be PUBLISH. Right?
--------------53809B4B452BB38C64B02B40-- --------------3A3A30F410E4C9738334DA5B 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: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 --------------3A3A30F410E4C9738334DA5B-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 11:11:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18122 for ; Thu, 7 Sep 2000 11:11:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15970 for ietf-calendar-bks; Thu, 7 Sep 2000 07:53:53 -0700 (PDT) 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 HAA15962 for ; Thu, 7 Sep 2000 07:53:52 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e87EipV00495 for ; Thu, 7 Sep 2000 07:44:51 -0700 (PDT) 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 G0IURQ00.EF3; Thu, 7 Sep 2000 07:55:02 -0700 Message-ID: <39B7AD46.1C45B335@netscape.com> Date: Thu, 07 Sep 2000 07:59:18 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: iTIP & Repeat/DUE/Duration restrictions References: Content-Type: multipart/mixed; boundary="------------B235D4190A8EEE5333A9DD8B" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B235D4190A8EEE5333A9DD8B Content-Type: multipart/alternative; boundary="------------E84A8950C055C7332D2AA1F8" --------------E84A8950C055C7332D2AA1F8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > Bruce: > > Looks like an oversight to me. Steve and Doug? > > -- Frank Here's what I currently have on my iTIP updates list for the VALARM restriction table in section 3.1: ATTENDEE 0+ MUST be present when the ACTION has a value of EMAIL. MUST NOT be present otherwise Does that sound right? -Steve --------------E84A8950C055C7332D2AA1F8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote:
Bruce:

Looks like an oversight to me. Steve and Doug?

-- Frank

Here's what I currently have on my iTIP updates list for the VALARM restriction table in section 3.1:

    ATTENDEE       0+      MUST be present when the ACTION has a
                           value of EMAIL. MUST NOT be present otherwise
 

Does that sound right?

-Steve --------------E84A8950C055C7332D2AA1F8-- --------------B235D4190A8EEE5333A9DD8B 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: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 --------------B235D4190A8EEE5333A9DD8B-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 16:03: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 QAA25767 for ; Thu, 7 Sep 2000 16:03:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA24315 for ietf-calendar-bks; Thu, 7 Sep 2000 11:54:31 -0700 (PDT) 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 LAA24308 for ; Thu, 7 Sep 2000 11:54:29 -0700 (PDT) From: Bruce_Kahn@iris.com To: sman@netscape.com (Steve Mansour) Cc: Frank_Dawson@lotus.com, ietf-calendar@imc.org Subject: Re: iTIP & Repeat/DUE/Duration restrictions X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Thu, 7 Sep 2000 14:56:00 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/07/2000 03:00:00 PM, Serialize complete at 09/07/2000 03:00:01 PM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/07/2000 03:00:01 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0068165885256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068165885256953_= Content-Type: text/plain; charset="us-ascii" That change sounds accurate to me. Make it so Mr Editor... 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 0068165885256953_= Content-Type: text/html; charset="us-ascii"
That change sounds accurate to me.  Make it so Mr Editor...

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 0068165885256953_=-- From owner-ietf-calendar@mail.imc.org Thu Sep 7 16:04: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 QAA25862 for ; Thu, 7 Sep 2000 16:04:50 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA24284 for ietf-calendar-bks; Thu, 7 Sep 2000 11:52:45 -0700 (PDT) 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 LAA24280 for ; Thu, 7 Sep 2000 11:52:43 -0700 (PDT) From: Bruce_Kahn@iris.com X-Priority: 1 (High) To: Frank_Dawson@lotus.com Cc: ietf-calendar@imc.org, sman@netscape.com (Steve Mansour) Subject: Re: iTIP & Repeat/DUE/Duration restrictions X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Thu, 7 Sep 2000 14:54:03 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/07/2000 02:58:14 PM, Serialize complete at 09/07/2000 02:58:14 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0067E89985256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067E89985256953_= Content-Type: text/plain; charset="us-ascii" Frank backtracked with: >I can have an event that has no DTEND, DUE or DURATION yet repeats. One case is the following: >... >DTSTART;VALUE=DATE:20000714 >RRULE:FREQ=YEARLY >SUMMARY:Bastille Day Fete Whoa Hoss! Are you claiming that Bastille Day lasts 365 days a year starting on 14-Jul-2000?? I doubt it!! So, you are making an implicit assumption about the DUE / DURATION / DTEND. There are 2 possible assumptions you are making: 1: A DTSTART;VALUE=DATE with no DTEND/DUE/DURATION has an implicit DUE/DTEND (or derived DURATION) of the same DATE or 2: If there is no DUE / DTEND / DURATION, no matter the DTSTART data type then there is an implied value of that same DATE (or DATE-TIME) Which are you assuming?? Option #1 is the most likely but either one is bad as it is not clear to the rest of the world how Frank would answer every case. :^b FWIW: _DO NOT ASSUME_ when trying to make a standard that is to used to interoperate!! It only leads to big problems or dis-interoperability later on! We should avoid either assumption you are making and fix the oversight. So, unless Frank or someone can give me an real example of an entry that starts but never ends and has no duration BUT can repeat, I suggest we add this to our change list for the next update. Also, in double checking against RFC 2445 I see that your original Bastille Day example was non-repeating AND it had a DTEND: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T170000Z DTEND:19970715T035959Z SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR 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 0067E89985256953_= Content-Type: text/html; charset="us-ascii"
Frank backtracked with:

>I can have an event that has no DTEND, DUE or DURATION yet repeats. One case is the following:
>...
>DTSTART;VALUE=DATE:20000714
>RRULE:FREQ=YEARLY
>SUMMARY:Bastille Day Fete

Whoa Hoss!  Are you claiming that Bastille Day lasts 365 days a year starting on 14-Jul-2000??  I doubt it!!  So, you are making an implicit assumption about the DUE / DURATION / DTEND.  There are 2 possible assumptions you are making:

1: A DTSTART;VALUE=DATE with no DTEND/DUE/DURATION has an implicit DUE/DTEND (or derived DURATION) of the same DATE or
2: If there is no DUE / DTEND / DURATION, no matter the DTSTART data type then there is an implied value of that same DATE (or DATE-TIME)

Which are you assuming??  Option #1 is the most likely but either one is bad as it is not clear to the rest of the world how Frank would answer every case. :^b

FWIW: _DO NOT ASSUME_ when trying to make a standard that is to used to interoperate!!  It only leads to big problems or dis-interoperability later on!  We should avoid either assumption you are making and fix the oversight.  So, unless Frank or someone can give me an real example of an entry that starts but never ends and has no duration BUT can repeat, I suggest we add this to our change list for the next update.

Also, in double checking against RFC 2445 I see that your original Bastille Day example was non-repeating AND it had a DTEND:

     BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:-//hacksw/handcal//NONSGML v1.0//EN
    BEGIN:VEVENT
    DTSTART:19970714T170000Z
    DTEND:19970715T035959Z
    SUMMARY:Bastille Day Party
    END:VEVENT
    END:VCALENDAR

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 0067E89985256953_=-- From owner-ietf-calendar@mail.imc.org Fri Sep 8 08:42: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 IAA21463 for ; Fri, 8 Sep 2000 08:42:03 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA16184 for ietf-calendar-bks; Fri, 8 Sep 2000 05:26:27 -0700 (PDT) Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16179 for ; Fri, 8 Sep 2000 05:26:25 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep03-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000908122740.CDCU15523.fep03-svc.swip.net@metaacer>; Fri, 8 Sep 2000 14:27:40 +0200 From: "Greg FitzPatrick" To: , Subject: SV: SKiCal ABNF Quirk Date: Fri, 8 Sep 2000 14:28:23 +0200 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.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce I am no ABNF guru either. I think we did the correct thing, but I would look forward to further comment here. Since we are on this subject, I would like to say a few things in relationship to this, which though not having bearing on the SKiCal RFC status, I believe might be of general interest. When I have suggested the feasibility of having Namespaces in mime directories (perhaps even an I-D to that effect), the reply is often that we already have that taken care of - courtesy of iana-tokens. What we are looking for in the long run is the use of multiple schemas designated by namespaces in event objects. These schemas could exist at the property level, the property parameter level, and the property and property parameter value level. Offhand I could envision how a mime-directory object and an XML object could reference the same schemas and typing constraints, though our friend Graham Klyne might have to develop a schema-content-negotiation protocol to make this work:-). Since iCal addresses a considerably narrower scope of terminologies than SKiCal, we have the luxury with iCal of being more "severe" in our codifications and restraints. SKiCal has to be more permissive At the same time any discovery process on SKiCal objects to be effective will be dependent on "naming markets", where event publishers can choose amongst taxonomies and specific terms which are in-tune with the market. These naming markets will have to be dynamic and timely. In our draft we have tried to show that it is not feasible for us to be "severe" with the possible ROLE values for PERSONS, THINGS and THINKS and indicated our belief that mechanisms will evolve in the near future comparable to the namespaces-schemas-types within the XML sphere. Greg PS if any one believes that the iana process suffices as it is, then I would suggest that somebody build an XML schema bridge for it. Bruce: Ok, Ill admit Im no ABNF guru but I think the ABNF in the draft needs to be changed to be 'proper'. The format does not quite seem normal based on my limited RFC 2445-2447 ABNF exposure but Ill see if I can put my finger on it. In the SKiCal draft the first example is: Personroleparam = "DIPROLE" "=" text ; It is RECOMMENDED that the text value be ; chosen from a list, as described in section 4 ; of this memo. One example of such a list is ; given here: "PERFORMER" ; Appearing at the event "CREATOR" ; Not necessarily present "COMPOSER" "CONDUCTOR" "ARTIST" "EDITOR" "PRODUCER" "GUIDE" "SPEAKER" "CHAIR" "PRESENT" ; At the event "REFERENCED" ; Not present at the event "INVITED" A comperable one from RFC 2445 is: cutypeparam = "CUTYPE" "=" ("INDIVIDUAL" ; An individual / "GROUP" ; A group of individuals / "RESOURCE" ; A physical resource / "ROOM" ; A room resource / "UNKNOWN" ; Otherwise not known / x-name ; Experimental type / iana-token) ; Other IANA registered ; type ; Default is INDIVIDUAL The SKiCal examples' first line defines the value as 'text' but then it goes on to explain more and give some explicit values. The iCalendar example lists the codified values and then "leaves it open" by allowing "x-name" and "iana-token" values which are previously defined as essentially "text". So, either SKiCal is using a slightly different but allowable ABNF format or the ABNF needs to be slightly changed to style shown above. Can some ABNF Guru please comment on this?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Fri Sep 8 08:49: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 IAA21569 for ; Fri, 8 Sep 2000 08:49:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA16657 for ietf-calendar-bks; Fri, 8 Sep 2000 05:35:43 -0700 (PDT) Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16652 for ; Fri, 8 Sep 2000 05:35:40 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep03-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000908123656.CFCA15523.fep03-svc.swip.net@metaacer>; Fri, 8 Sep 2000 14:36:56 +0200 From: "Greg FitzPatrick" To: , Subject: SV: SKiCal: SKiCal specific component properties (Part 2) Date: Fri, 8 Sep 2000 14:37:39 +0200 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.2615.200 Importance: Normal In-Reply-To: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ok - terms are values. We will look at management. Greg Bruce: Argh, a bit too tired and clicked on the send button instead of my SKiCal window tab (just above the button)... I did see the text in 3. SKiCal specific component properties that mentioned that SKiCal was extending the RFC 2445 ABNF: Therefore any component property, which MAY appear in a VEVENT iCalendar component, is also allowed in a SKiCal object. but the ABNF that followed it could be misread. That was my point in my runt posting... I also am curious about the phrase found at the bottom of this section, a "term": It is RECOMMENDED that publishers chose the terms used as TEXT type property values from authoritative lists of terms. Those publishers who consequently use terms found in such lists will facilitate extensive automatic treatment of their information. There is no clear definition of what 'term' is but Im guessing its "values". Can the SKiCal authors please define this term better before using it?? Also the talk of ""MANAGEMENT" header (Calendar object management)" is also a bit confusing since these are not RFC terms. Can someone please rephrase the contents of the last paragraph in that section a bit so it is clearer?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Fri Sep 8 08:55: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 IAA21654 for ; Fri, 8 Sep 2000 08:55:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA16883 for ietf-calendar-bks; Fri, 8 Sep 2000 05:42:33 -0700 (PDT) Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16879 for ; Fri, 8 Sep 2000 05:42:32 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep03-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000908124348.CHIE15523.fep03-svc.swip.net@metaacer>; Fri, 8 Sep 2000 14:43:48 +0200 From: "Greg FitzPatrick" To: Cc: "Ietf" Subject: SV: SKiCal extensibility Date: Fri, 8 Sep 2000 14:44:32 +0200 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Good suggestion Greg Bruce: Making sure that we learn a good lesson from iCalendar, I noticed that some of the new property parameters (and possibly the properties) have very very restrictive ABNFs in that they do not allow for future expandability. This is not good. For example, section 2.6 Qualification status parameter has: qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" / "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / "NOTPROHIBITED") (Please fold values to separate lines...) While this may appear OK at first pass, it precludes any new values that are not expressly put in the ABNF. The lesson from iCalendar would make the ABNF: qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" / "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / "NOTPROHIBITED" / x-name / iana-token ) so that new values (or experimantal ones) can be added w/o breaking some stricter interpretations!! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Fri Sep 8 08:56: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 IAA21666 for ; Fri, 8 Sep 2000 08:56:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA16895 for ietf-calendar-bks; Fri, 8 Sep 2000 05:42:38 -0700 (PDT) Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16890 for ; Fri, 8 Sep 2000 05:42:37 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep03-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000908124353.CHIK15523.fep03-svc.swip.net@metaacer>; Fri, 8 Sep 2000 14:43:53 +0200 From: "Greg FitzPatrick" To: , Subject: SV: SKiCal: SKiCal specific component properties Date: Fri, 8 Sep 2000 14:44:37 +0200 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce Thank you - agreed. Greg Bruce: In section 3. SKiCal specific component properties there is text that says: In addition, the following component properties are defined in this memo. eventprop = ... However, SKiCal is not defining vEvent but rather extending it with new properties. This could cause some confusion if the readers interpret the ABNF as shown to be an entirely new eventprop than defined in RFC 2445 instead of the ABNF being extensions to RFC 2445. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Fri Sep 8 08:57: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 IAA21677 for ; Fri, 8 Sep 2000 08:57:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA16926 for ietf-calendar-bks; Fri, 8 Sep 2000 05:43:10 -0700 (PDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16920 for ; Fri, 8 Sep 2000 05:43:08 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep04-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000908124425.CAMG16784.fep04-svc.swip.net@metaacer>; Fri, 8 Sep 2000 14:44:25 +0200 From: "Greg FitzPatrick" To: Cc: "Ietf" Subject: SV: SKiCal & Roles Date: Fri, 8 Sep 2000 14:45:08 +0200 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Bruce 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. This is a reoccurring problem for SKiCal, but the benefits are that SKiCal does not confuse applications "tuned" for iCal. Bruce Kahn: Ok, I revisited SKiCal draft for another pass or two. One quick thing that poped out was the addition of "DIPROLE", "DITROLE" and "DITHROLE" to the current "ROLE" property parameter. Im 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). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Fri Sep 8 08:58: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 IAA21699 for ; Fri, 8 Sep 2000 08:58:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA16847 for ietf-calendar-bks; Fri, 8 Sep 2000 05:42:03 -0700 (PDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16840 for ; Fri, 8 Sep 2000 05:42:00 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep04-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000908124316.CAGV16784.fep04-svc.swip.net@metaacer>; Fri, 8 Sep 2000 14:43:16 +0200 From: "Greg FitzPatrick" To: , Subject: SV: SKiCal: SKiCal specific component properties (Part 2) Date: Fri, 8 Sep 2000 14:44:00 +0200 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ok - terms are values. We will look at management. Greg Bruce: Aright, a bit too tired and clicked on the send button instead of my SKiCal window tab (just above the button)... I did see the text in 3. SKiCal specific component properties that mentioned that SKiCal was extending the RFC 2445 ABNF: Therefore any component property, which MAY appear in a VEVENT iCalendar component, is also allowed in a SKiCal object. but the ABNF that followed it could be misread. That was my point in my runt posting... I also am curious about the phrase found at the bottom of this section, a "term": It is RECOMMENDED that publishers chose the terms used as TEXT type property values from authoritative lists of terms. Those publishers who consequently use terms found in such lists will facilitate extensive automatic treatment of their information. There is no clear definition of what 'term' is but Im guessing its "values". Can the SKiCal authors please define this term better before using it?? Also the talk of ""MANAGEMENT" header (Calendar object management)" is also a bit confusing since these are not RFC terms. Can someone please rephrase the contents of the last paragraph in that section a bit so it is clearer?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Fri Sep 8 10:09: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 KAA23033 for ; Fri, 8 Sep 2000 10:09:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA18374 for ietf-calendar-bks; Fri, 8 Sep 2000 06:53:40 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18365 for ; Fri, 8 Sep 2000 06:53:37 -0700 (PDT) Received: from HALVESTR-8KCDT.maxware.no (ams-vpdn-client-450.cisco.com [144.254.47.198]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id PAA27023; Fri, 8 Sep 2000 15:55:04 +0200 Message-Id: <4.3.2.7.2.20000908154328.037b6600@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Sep 2000 15:48:36 +0200 To: "Greg FitzPatrick" , From: Harald Alvestrand Subject: Re: SV: SKiCal extensibility Cc: "Ietf" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14:44 08/09/2000 +0200, Greg FitzPatrick wrote: >(Please fold values to separate lines...) While this may appear OK at first >pass, it precludes any new values that are not expressly put in the ABNF. >The lesson from iCalendar would make the ABNF: > > qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" / > "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / > "NOTPROHIBITED" / x-name / iana-token ) > >so that new values (or experimantal ones) can be added w/o breaking some >stricter interpretations!! there's actually another way to do this, too.... if the original ABNF is param = "FIRST" / "SECOND" and you want to make it clear that you are extending a definition, you can do it like this: param =/ "THIRD" which means that param can have all the old values, and THIRD too. Section 3.3 of RFC 2234. And of course, when you reuse something in a new context, you can always say: paramv2 = param / "THIRD" But in general, you want to include the iana-token thing unless you really, really want it to be a protocol error to specify an unknown value. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-calendar@mail.imc.org Fri Sep 8 10:11: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 KAA23095 for ; Fri, 8 Sep 2000 10:11:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA18373 for ietf-calendar-bks; Fri, 8 Sep 2000 06:53:39 -0700 (PDT) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18364 for ; Fri, 8 Sep 2000 06:53:37 -0700 (PDT) Received: from HALVESTR-8KCDT.maxware.no (ams-vpdn-client-450.cisco.com [144.254.47.198]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id PAA27029; Fri, 8 Sep 2000 15:55:08 +0200 Message-Id: <4.3.2.7.2.20000908154912.0347d5d0@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-Priority: 1 (Highest) Date: Fri, 08 Sep 2000 15:51:14 +0200 To: Bruce_Kahn@iris.com, ietf-calendar@imc.org From: Harald Alvestrand Subject: Re: SKiCal ABNF Quirk In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 22:36 06/09/2000 -0400, Bruce_Kahn@iris.com wrote: >Ok, Ill admit Im no ABNF guru but I think the ABNF in the draft needs to >be changed to be 'proper'. The format does not quite seem normal based on >my limited RFC 2445-2447 ABNF exposure but Ill see if I can put my finger >on it. In the SKiCal draft the first example is: > > Personroleparam = "DIPROLE" "=" text > ; It is RECOMMENDED that the text value be > ; chosen from a list, as described in section 4 > ; of this memo. One example of such a list is > ; given here: > > "PERFORMER" ; Appearing at the event > "CREATOR" ; Not necessarily present > "COMPOSER" > "CONDUCTOR" > "ARTIST" > "EDITOR" > "PRODUCER" > "GUIDE" > "SPEAKER" > "CHAIR" > "PRESENT" ; At the event > "REFERENCED" ; Not present at the event > "INVITED" As written, a Personroleparam can only have the value DIPROLE=PERFORMERCREATORCOMPOSERCONDUCTORARTISTEDITORPRODUCERGUIDESPEAKERCHAIRPRESENTREFERENCEDINVITED, which is probably not what was intended. If you want the examples to be examples, put a semicolon to the left of them. If you don't, they are part of the grammar - and putting items one after the other means that they are concatenated, not that they are alternatives. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-calendar@mail.imc.org Fri Sep 8 10:53:46 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 KAA23899 for ; Fri, 8 Sep 2000 10:53:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19124 for ietf-calendar-bks; Fri, 8 Sep 2000 07:36:21 -0700 (PDT) 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 HAA19120 for ; Fri, 8 Sep 2000 07:36:19 -0700 (PDT) Received: from metamatrix.se (dublin.metamatrix.se [193.14.119.156]) by ljudo.shortlist.se (Postfix) with ESMTP id CCA9BB34C6; Fri, 8 Sep 2000 16:37:59 +0200 (CEST) Message-ID: <39B8F9C7.4F3589AB@metamatrix.se> Date: Fri, 08 Sep 2000 16:37:59 +0200 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org Subject: Re: SKiCal & QUALVALUE 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 HAA19124 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA23899 Bruce_Kahn@iris.com wrote: > Section 2.5 Qualification value parameter shows an incorrect ABNF for > the new property parameter. The ABNF is: > qualvalparam = text > but it really needs to be: > qualvalparam = "QUALVALUE" = text Correct. > or probably even: > qualvalparam = "QUALVALUE" = > ( x-name ; Experimental type > / iana-token ) ; Other IANA registered > ; type If you look at the examples: ADMISSION;QUALTYPE=SKILL;QUALRULE=RECOMMENDED;QUALVALUE="Horse Riding Experience": ADMISSION;QUALTYPE=AGE;QUALRULE=REQUIRED;QUALVALUE=gt 5: you see that the qualvalue can be a range of different types, depending on the qualtype. So I think we need to allow any As always, it will be more easily treated by machines if values are choosen from well known namespaces, such as the list of IANA registered types. But there aren't too many of those lists around yet. (There will be, of course, when more and more information is being made available to an audience of robots and autonomous agents.) Thanks/Pär From owner-ietf-calendar@mail.imc.org Fri Sep 8 11:14: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 LAA24284 for ; Fri, 8 Sep 2000 11:14:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19546 for ietf-calendar-bks; Fri, 8 Sep 2000 07:58:39 -0700 (PDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19542 for ; Fri, 8 Sep 2000 07:58:38 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep04-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000908145954.CZGX16784.fep04-svc.swip.net@metaacer>; Fri, 8 Sep 2000 16:59:54 +0200 From: "Greg FitzPatrick" To: "Harald Alvestrand" , Cc: "Ietf" Subject: SV: SV: SKiCal extensibility Date: Fri, 8 Sep 2000 17:00:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20000908154328.037b6600@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id HAA19546 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24284 Harold Are you suggesting that we should have done this consequently when extending RFC 2445? Greg -----Ursprungligt meddelande----- Från: Harald Alvestrand [mailto:Harald@Alvestrand.no] Skickat: den 8 september 2000 15:49 Till: Greg FitzPatrick; Bruce_Kahn@iris.com Kopia: Ietf Ämne: Re: SV: SKiCal extensibility At 14:44 08/09/2000 +0200, Greg FitzPatrick wrote: >(Please fold values to separate lines...) While this may appear OK at first >pass, it precludes any new values that are not expressly put in the ABNF. >The lesson from iCalendar would make the ABNF: > > qualstatparam = "QUALRULE" "=" *1("REQUIRED" / "NOTREQUIRED" / > "RECOMMENDED" / "NOTRECOMMENDED" / "PROHIBITED" / > "NOTPROHIBITED" / x-name / iana-token ) > >so that new values (or experimantal ones) can be added w/o breaking some >stricter interpretations!! there's actually another way to do this, too.... if the original ABNF is param = "FIRST" / "SECOND" and you want to make it clear that you are extending a definition, you can do it like this: param =/ "THIRD" which means that param can have all the old values, and THIRD too. Section 3.3 of RFC 2234. And of course, when you reuse something in a new context, you can always say: paramv2 = param / "THIRD" But in general, you want to include the iana-token thing unless you really, really want it to be a protocol error to specify an unknown value. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-calendar@mail.imc.org Fri Sep 8 11:37: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 LAA24596 for ; Fri, 8 Sep 2000 11:37:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22119 for ietf-calendar-bks; Fri, 8 Sep 2000 08:19:34 -0700 (PDT) Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22108 for ; Fri, 8 Sep 2000 08:19:31 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep03-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000908152002.DHLE15523.fep03-svc.swip.net@metaacer>; Fri, 8 Sep 2000 17:20:02 +0200 From: "Greg FitzPatrick" To: "Harald Alvestrand" , , Subject: SV: SKiCal ABNF Quirk Date: Fri, 8 Sep 2000 17:20:45 +0200 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) In-Reply-To: <4.3.2.7.2.20000908154912.0347d5d0@127.0.0.1> 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 So I guess we were trying to describe the ultimate polymath:-) Thanks for the correction - we will get to that right away. Greg At 22:36 06/09/2000 -0400, Bruce_Kahn@iris.com wrote: >Ok, Ill admit Im no ABNF guru but I think the ABNF in the draft needs to >be changed to be 'proper'. The format does not quite seem normal based on >my limited RFC 2445-2447 ABNF exposure but Ill see if I can put my finger >on it. In the SKiCal draft the first example is: > > Personroleparam = "DIPROLE" "=" text > ; It is RECOMMENDED that the text value be > ; chosen from a list, as described in section 4 > ; of this memo. One example of such a list is > ; given here: > > "PERFORMER" ; Appearing at the event > "CREATOR" ; Not necessarily present > "COMPOSER" > "CONDUCTOR" > "ARTIST" > "EDITOR" > "PRODUCER" > "GUIDE" > "SPEAKER" > "CHAIR" > "PRESENT" ; At the event > "REFERENCED" ; Not present at the event > "INVITED" As written, a Personroleparam can only have the value DIPROLE=PERFORMERCREATORCOMPOSERCONDUCTORARTISTEDITORPRODUCERGUIDESPEAKERCHAIRP RESENTREFERENCEDINVITED, which is probably not what was intended. If you want the examples to be examples, put a semicolon to the left of them. If you don't, they are part of the grammar - and putting items one after the other means that they are concatenated, not that they are alternatives. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-ietf-calendar@mail.imc.org Fri Sep 8 12:07: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 MAA25108 for ; Fri, 8 Sep 2000 12:07:47 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA24884 for ietf-calendar-bks; Fri, 8 Sep 2000 08:48:40 -0700 (PDT) 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 IAA24876 for ; Fri, 8 Sep 2000 08:48:36 -0700 (PDT) From: Bruce_Kahn@iris.com To: =?iso-8859-1?q?P=E4r_Lanner=F6?= Cc: ietf-calendar@imc.org Subject: Re: SKiCal & QUALVALUE X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Fri, 8 Sep 2000 11:49:58 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/08/2000 11:54:13 AM, Serialize complete at 09/08/2000 11:54:13 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00570E8985256954_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00570E8985256954_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable P=E4r replied: >> or probably even: >> qualvalparam =3D "QUALVALUE" =3D >> ( x-name ; Experimental type >> / iana-token ) ; Other IANA registered >> ; type > >If you look at the examples: >ADMISSION;QUALTYPE=3DSKILL;QUALRULE=3DRECOMMENDED;QUALVALUE=3D"Horse=20 > Riding Experience": >ADMISSION;QUALTYPE=3DAGE;QUALRULE=3DREQUIRED;QUALVALUE=3Dgt 5:=20 >you see that the qualvalue can be a range of different types, depending >on the qualtype. >So I think we need to allow any=20 I do not think that x-name or iana-token restrict the contents of what the = data can be. If you check the ABNF from RFC 2445 you will find the=20 following relevant snippets: iana-token =3D 1*(ALPHA / DIGIT / "-") ; iCalendar identifier registered with IANA ... ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z DIGIT =3D %x30-39 ; 0-9 If you check out section 3.2 Parameters of RFC 2445 you can find a useful b= it on parameters (the=20 optinfo parameter really but it is applicable here): The "optinfo" parameter conveys optional information about the iCalendar object within the body part. [Snip] For example, it can be used to convey the "Attendee" response status to a meeting request. The parameter value consists of a string value. The parameter can be specified multiple times. [Snip] The value for the "optinfo" parameter is defined as follows: optinfo =3D infovalue / qinfovalue infovalue =3D iana-token / x-name qinfovalue =3D DQUOTE (infovalue) DQUOTE So I do not think that the suggested change to "x-name / iana-token"=20 should be any real concern since it allows for any value(s) and it leaves=20 the door open for future extensions w/o reissuing the RFCs (as previously=20 noted). In rechecking some background I think Ill suggest you recheck the=20 part of section 4.1 Content Lines that talks about how to generally parse = property parameters: param =3D param-name "=3D" param-value *("," param-value) ; Each property defines the specific ABNF for the parameters ; allowed on the property. Refer to specific properties for ; precise parameter ABNF. param-name =3D iana-token / x-token param-value =3D paramtext / quoted-string Perhaps just making the QUALVALUE paramter like the RFC 2445 CN parameter=20 is what you want... 2 choices for you to pick from (or you can find=20 another). Bruce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bruce Kahn INet: Bruce=5FKahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00570E8985256954_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
P=E4r replied:

>> or probably even:
>>     qualvalparam =3D "QUALVALUE" =3D
>>                   &nb= sp;     ( x-name              =  ; Experimental type
>>                   &nb= sp;    / iana-token )          ; Other I= ANA registered
>>                   &nb= sp;                     &= nbsp;      ; type
>
>If you look at the examples:
>ADMISSION;QUALTYPE=3DSKILL;QUALRULE=3DRECOMMENDED;QUALVALUE=3D"Hor= se  
> Riding Experience":
>ADMISSION;QUALTYPE=3DAGE;QUALRULE=3DREQUIRED;QUALVALUE=3Dgt 5:
>you see that the qualvalue can be a range of different types, depending=
>on the qualtype.
>So I think we need to allow any

I do not think that x-name or iana-t= oken restrict the contents of what the data can be.  If you check the = ABNF from RFC 2445 you will find the following relevant snippets:

     iana-token =3D 1*(ALPHA / DIGIT = / "-")
    ; iCalendar identifier registered with IANA
...
     ALPHA      =3D %x= 41-5A / %x61-7A   ; A-Z / a-z

    DIGIT      =3D %x30-39
       ; 0-9
If you check out section 3.2 Paramet= ers of RFC 2445 you can find a useful bit on parameters (the optinfo parame= ter really but it is applicable here):

   The "optinfo" parameter conve= ys optional information about the
  iCalendar object within the body part. [Snip]
  For example, it can be used to convey the "Attendee" resp= onse status
  to a meeting request. The parameter value consists of a string valu= e.

  The parameter can be specified multiple times.
[Snip]
   The value for the "optinfo" p= arameter is defined as follows:

       optinfo =3D infovalue / qinfovalue

       infovalue       =3D iana-token /= x-name

       qinfovalue      =3D DQUOTE (info= value) DQUOTE

So I do not think that the suggested= change to "x-name / iana-token" should be any real concern since= it allows for any value(s) and it leaves the door open for future extensio= ns w/o reissuing the RFCs (as previously noted). In rechecking some backgro= und I think Ill suggest you recheck the part of section 4.1 Content Lines &= nbsp;that talks about how to generally parse property parameters:

     param        = ;      =3D param-name "=3D" param-value
                    &nbs= p;    *("," param-value)
       ; Each property defines the specific ABNF for t= he parameters
       ; allowed on the property. Refer to specific pr= operties for
       ; precise parameter ABNF.

    param-name =3D iana-token / x-token

    param-value        =3D paramtext / quote= d-string

Perhaps just making the QUALVALUE pa= ramter like the RFC 2445 CN parameter is what you want...  2 choices f= or you to pick from (or you can find another).

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn                   &= nbsp;            INet: Bruce=5FKahn@iris.com<= br> Iris Associates                 &nb= sp;        Phone: 978.392.5335
Westford, MA, USA 01886               &n= bsp;    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00570E8985256954_=-- From owner-ietf-calendar@mail.imc.org Fri Sep 8 12:24: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 MAA25324 for ; Fri, 8 Sep 2000 12:24:48 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA25232 for ietf-calendar-bks; Fri, 8 Sep 2000 09:04:41 -0700 (PDT) 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 JAA25228 for ; Fri, 8 Sep 2000 09:04:34 -0700 (PDT) From: Bruce_Kahn@iris.com To: "Greg FitzPatrick" Cc: "Ietf" Subject: Re: SV: SKiCal & Roles X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Fri, 8 Sep 2000 12:06:08 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/08/2000 12:10:16 PM, Serialize complete at 09/08/2000 12:10:16 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005889A285256954_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005889A285256954_= Content-Type: text/plain; charset="us-ascii" Greg 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. I dont think you are really bending iCalendar by reusing "ROLE". Check for yourself: 4.2.16 Participation Role Parameter Name: ROLE Purpose: To specify the participation role for the calendar user specified by the property. Well, isn't that exactly what you are describing in your examples??: PERSONS;DIPROLE=REFERENCED:Marilyn Manson PERSONS;DIPROLE=CREATOR:Beethoven, Ludwig van ... THINGS;DITROLE=FOR-HIRE:Golf clubs THINGS;DITROLE=PRESENT:Car models of 2001 THINGS;DITROLE=DEMONSTRATED:Electrolux refrigerator door computers The only hair to split is that the 'calendar user' is not a cal-addr data type but rather some textual 'tag' associated to that kind of property... However thats a very tiny hair to try and split. > Nor have >we felt that it was a good idea to try to change 2445 merely to accommodate >SKiCal iCalendar was designed to be extensible so that anyone could build upon it. Hence the use of x-name and iana-token in much of the ABNF. As long as you dont not change the existing meanings (ie: REQ-PARTICIPANT is not a "required participant" in SKiCal but rather a caterer...) then I do not see any problem w/that. Anyone else see one?? 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 005889A285256954_= Content-Type: text/html; charset="us-ascii"
Greg 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.  

I dont think you are really bending iCalendar by reusing "ROLE".  Check for yourself:

4.2.16 Participation Role

  Parameter Name: ROLE

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

Well, isn't that exactly what you are describing in your examples??:

    PERSONS;DIPROLE=REFERENCED:Marilyn Manson
   PERSONS;DIPROLE=CREATOR:Beethoven, Ludwig van
...
    THINGS;DITROLE=FOR-HIRE:Golf clubs
   THINGS;DITROLE=PRESENT:Car models of 2001
   THINGS;DITROLE=DEMONSTRATED:Electrolux refrigerator door computers

The only hair to split is that the 'calendar user' is not a cal-addr data type but rather some textual 'tag' associated to that kind of property... However thats a very tiny hair to try and split.

>                                                                   Nor have
>we felt that it was a good idea to try to change 2445 merely to accommodate
>SKiCal

iCalendar was designed to be extensible so that anyone could build upon it.  Hence the use of x-name and iana-token in much of the ABNF.  As long as you dont not change the existing meanings (ie: REQ-PARTICIPANT is not a "required participant" in SKiCal but rather a caterer...) then I do not see any problem w/that.  Anyone else see one??

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 005889A285256954_=-- From owner-ietf-calendar@mail.imc.org Fri Sep 8 12:25: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 MAA25349 for ; Fri, 8 Sep 2000 12:25:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA25243 for ietf-calendar-bks; Fri, 8 Sep 2000 09:05:04 -0700 (PDT) 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 JAA25235 for ; Fri, 8 Sep 2000 09:05:00 -0700 (PDT) From: Bruce_Kahn@iris.com To: Message-ID: Date: Fri, 8 Sep 2000 12:06:32 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/08/2000 12:10:39 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: Harald penned: >and you want to make it clear that you are extending a definition, you can >do it like this: > > param =/ "THIRD" We use this in the first set of RFCs and I think it makes things clearer when spread out across lots of text or several texts. Will this work when extending something that is 'compound'?? For example, will that work when trying to extend something like this from RFC 2445: roleparam = "ROLE" "=" ("CHAIR" ; Indicates chair of the ; calendar entity / "REQ-PARTICIPANT" ; Indicates a participant whose ; participation is required / "OPT-PARTICIPANT" ; Indicates a participant whose ; participation is optional / "NON-PARTICIPANT" ; Indicates a participant who is ; copied for information ; purposes only / x-name ; Experimental role / iana-token) ; Other IANA role ; Default is REQ-PARTICIPANT Should the RFC 2445 have defined it this way instead: roleparam = "ROLE" "=" roleparamvalue roleparamvalue = ("CHAIR" ; Indicates chair of the ; calendar entity / "REQ-PARTICIPANT" ; Indicates a participant whose ; participation is required / "OPT-PARTICIPANT" ; Indicates a participant whose ; participation is optional / "NON-PARTICIPANT" ; Indicates a participant who is ; copied for information ; purposes only / x-name ; Experimental role / iana-token) ; Other IANA role ; Default is REQ-PARTICIPANT so that we could easily extend it in places like SKiCal?? Or is there a proper way to extend the former example in SKiCal? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From owner-ietf-calendar@mail.imc.org Fri Sep 8 16:16: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 QAA29594 for ; Fri, 8 Sep 2000 16:15:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA29580 for ietf-calendar-bks; Fri, 8 Sep 2000 12:58:43 -0700 (PDT) Received: from localhost.localdomain (guanabana.helixcode.com [140.239.238.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29576 for ; Fri, 8 Sep 2000 12:58:38 -0700 (PDT) Received: (from federico@localhost) by localhost.localdomain (8.9.3/8.9.3) id QAA20789; Fri, 8 Sep 2000 16:15:46 -0400 Date: Fri, 8 Sep 2000 16:15:46 -0400 Message-Id: <200009082015.QAA20789@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: federico set sender to federico@helixcode.com using -f From: Federico Mena Quintero X-Do-Not-Disturb: I'm on the verge of a universe-tilting breakthrough. To: Subject: Re: SV: SKiCal ABNF Quirk References: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Greg FitzPatrick" writes: > Since iCal addresses a considerably narrower scope of terminologies than > SKiCal, we have the luxury with iCal of being more "severe" in our > codifications and restraints. SKiCal has to be more permissive Is it just me, or does anyone else think SKiCal is severe overkill? What is wrong with just using a VEVENT component with SUMMARY: Pink Panther Philarmonic weekly concert DTSTART: DTEND: LOCATION: Pink Symphony Hall, 69 Some Street, Anytown, Anywhere DESCRIPTION: This week Inspector Clouseau himself conducts the renowned Pink Panther Philarmonic with a spectacular and loud programme with works by Bartók, Stravinski and Shostakovich. URL: http://www.pinkpantherphilarmonic.org/friday.html If you try to classify every possible public concert/conference/ exhibition/whatever, you'll end up with yet another inconsistent RFC just as thick as iTIP and iCalendar. Sorry for sounding bitter, but it sounds like people are proposing lots of stuff that nobody will ever implement. Federico From owner-ietf-calendar@mail.imc.org Fri Sep 8 16:51:11 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 QAA00318 for ; Fri, 8 Sep 2000 16:51:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA00137 for ietf-calendar-bks; Fri, 8 Sep 2000 13:30:25 -0700 (PDT) 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 NAA00133 for ; Fri, 8 Sep 2000 13:30:23 -0700 (PDT) Received: from metamatrix.se (dublin.metamatrix.se [193.14.119.156]) by ljudo.shortlist.se (Postfix) with ESMTP id 41959B34C6; Fri, 8 Sep 2000 22:32:10 +0200 (CEST) Message-ID: <39B94CCA.28128F23@metamatrix.se> Date: Fri, 08 Sep 2000 22:32:10 +0200 From: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= Organization: Metamatrix AB X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Federico Mena Quintero Cc: ietf-calendar@imc.org Subject: Re: SV: SKiCal ABNF Quirk References: <200009082015.QAA20789@localhost.localdomain> 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 NAA00137 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA00318 Federico Mena Quintero wrote: > Is it just me, or does anyone else think SKiCal is severe overkill? [...] > Sorry for sounding bitter, but it sounds like people are proposing > lots of stuff that nobody will ever implement. Actually my company and a few others in Scandinavia have implemented large parts of SKICal in several systems, and customers are eager to get a way to exchange event information more detailed than what is possible using RFC2445 without extensions. Why not standardize the most commonly needed extensions? (Price, Where to get tickets, Handicap facilities...) For sure, not many applications will make use of _all_ extensions, but the more that gets specified in a publicly available document, the less people will need to use their own proprietary extensions, and the more useful the information published on iCalendar/SKICal format will be. /Pär From owner-ietf-calendar@mail.imc.org Sat Sep 9 04:25: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 EAA20387 for ; Sat, 9 Sep 2000 04:25:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA11015 for ietf-calendar-bks; Sat, 9 Sep 2000 01:11:15 -0700 (PDT) Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11011 for ; Sat, 9 Sep 2000 01:11:14 -0700 (PDT) Received: from imc.org (HSE-Toronto-ppp100850.sympatico.ca [216.209.79.163]) by smtp11.bellglobal.com (8.8.5/8.8.5) with SMTP id EAA29279 for ietf-calendar@imc.org; Sat, 9 Sep 2000 04:20:35 -0400 (EDT) Message-Id: <200009090820.EAA29279@smtp11.bellglobal.com> From: Me@smtp11.bellglobal.com, Your.Friend.@smtp11.bellglobal.com REPLY-TO: colocatz@yahoo.com X-Mailer: EzyMassMailer V2.xx Date: 09 Sep 2000 To: Newsletter.Subscriber@smtp11.bellglobal.com Subject: Important Text - Something I need to tell you. Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We're not weird......we're sexy!!!!!!! http://205.232.74.175 From owner-ietf-calendar@mail.imc.org Sun Sep 10 03:18: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 DAA01754 for ; Sun, 10 Sep 2000 03:18:15 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA05226 for ietf-calendar-bks; Sat, 9 Sep 2000 23:58:22 -0700 (PDT) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA05222 for ; Sat, 9 Sep 2000 23:58:19 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA01529 for ietf-calendar@imc.org; Sun, 10 Sep 2000 00:00:04 -0700 (PDT) Date: Sun, 10 Sep 2000 00:00:04 -0700 (PDT) From: Doug Royer Message-Id: <200009100700.AAA01529@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 Sep 11 06:23: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 GAA28297 for ; Mon, 11 Sep 2000 06:23:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04957 for ietf-calendar-bks; Mon, 11 Sep 2000 03:05:12 -0700 (PDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04952 for ; Mon, 11 Sep 2000 03:05:10 -0700 (PDT) Received: from metaacer ([193.14.119.51]) by fep04-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with SMTP id <20000911100640.DQIO20452.fep04-svc.swip.net@metaacer>; Mon, 11 Sep 2000 12:06:40 +0200 From: "Greg FitzPatrick" To: "Federico Mena Quintero" , Subject: SV: SV: SKiCal ABNF Quirk Date: Mon, 11 Sep 2000 12:07:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200009082015.QAA20789@localhost.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id DAA04957 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA28297 Well nothing is "wrong" with doing what you have suggested below. And (liberally interpreting your generalizations) this is a valid SKiCal representation. But take a look out there on the Internet and you will see that there is a large, dynamic event marketplace, where various infomediarias are creating vertical sectors (walled gardens) with proprietary schemas. Now you either believe in end-to-end market solutions or you don't. I for one do. And proof that I am not alone on this is everywhere. For example take a look at the recently launched http://www.uddi.org/ It will be up to event publishers how much structure they desire in their postings. By reducing obligatory fields to a minimum we are giving them that choice. If structure creates efficiency - I believe it will be used. It certainly is the case in this country (Sweden) and I suspect that as other countries approach Scandinavia in (specially wireless) internet access the need for tighter structure and discovery efficiency will become more apparent. I suggest it is a good time to get started. btw sounds like a fun concert:-) Fredrico's example SUMMARY: Pink Panther Philarmonic weekly concert DTSTART: DTEND: LOCATION: Pink Symphony Hall, 69 Some Street, Anytown, Anywhere DESCRIPTION: This week Inspector Clouseau himself conducts the renowned Pink Panther Philarmonic with a spectacular and loud programme with works by Bartók, Stravinski and Shostakovich. URL: http://www.pinkpantherphilarmonic.org/friday.html But you have missed the point. From owner-ietf-calendar@mail.imc.org Mon Sep 11 11:52: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 LAA05400 for ; Mon, 11 Sep 2000 11:52:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14421 for ietf-calendar-bks; Mon, 11 Sep 2000 08:36:31 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14407; Mon, 11 Sep 2000 08:36:28 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA08634; Mon, 11 Sep 2000 11:40:17 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA13900; Mon, 11 Sep 2000 11:37:56 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: SKiCal & QUALVALUE X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 11 Sep 2000 11:37:29 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_09072000 |September 7, 2000) at 09/11/2000 11:37:32 AM, Serialize complete at 09/11/2000 11:37:32 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00456CBDC1256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00456CBDC1256953_= Content-Type: text/plain; charset="us-ascii" Bruce: I think you mean: qualvalparam = "QUALVALUE" "=" text or even qualvalparam = "QUALVALUE" = text -- Frank --=_alternative 00456CBDC1256953_= Content-Type: text/html; charset="us-ascii"
Bruce:

I think you mean:

   qualvalparam = "QUALVALUE" "=" text

or even

   qualvalparam = "QUALVALUE" = text

-- Frank --=_alternative 00456CBDC1256953_=-- From owner-ietf-calendar@mail.imc.org Mon Sep 11 11:54: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 LAA05442 for ; Mon, 11 Sep 2000 11:54:19 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA14419 for ietf-calendar-bks; Mon, 11 Sep 2000 08:36:30 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14406; Mon, 11 Sep 2000 08:36:28 -0700 (PDT) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA08631; Mon, 11 Sep 2000 11:40:17 -0400 (EDT) Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA13898; Mon, 11 Sep 2000 11:37:55 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: SKiCal ABNF Quirk X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: Date: Mon, 11 Sep 2000 11:37:30 -0400 X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V505_09072000 |September 7, 2000) at 09/11/2000 11:37:32 AM, Serialize complete at 09/11/2000 11:37:32 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0045AD82C1256953_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0045AD82C1256953_= Content-Type: text/plain; charset="us-ascii" Bruce: I would have thought that the "example" values need to be prefixed as comment lines. As "examples" they are not normative. "text" appears to be the only normative value. -- Frank --=_alternative 0045AD82C1256953_= Content-Type: text/html; charset="us-ascii"
Bruce:

I would have thought that the "example" values need to be prefixed as comment lines. As "examples" they are not normative. "text" appears to be the only normative value.

-- Frank --=_alternative 0045AD82C1256953_=-- From owner-ietf-calendar@mail.imc.org Mon Sep 11 12:28:46 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 MAA06010 for ; Mon, 11 Sep 2000 12:28:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17811 for ietf-calendar-bks; Mon, 11 Sep 2000 09:13:02 -0700 (PDT) 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 JAA17807 for ; Mon, 11 Sep 2000 09:13:00 -0700 (PDT) From: Bruce_Kahn@iris.com To: Frank_Dawson@lotus.com Cc: ietf-calendar@imc.org Subject: Re: SKiCal & QUALVALUE X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Mon, 11 Sep 2000 12:14:38 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/11/2000 12:18:53 PM, Serialize complete at 09/11/2000 12:18:53 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00595A9F85256957_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00595A9F85256957_= Content-Type: text/plain; charset="us-ascii" Frank suggested: > qualvalparam = "QUALVALUE" "=" text Correct. The '=' should have been quoted. > qualvalparam = "QUALVALUE" = text Nope, thats what I had originally. In order for the '=' to be part of the stream, it must be quoted. However, if the SKiCal folks are planning on standardizing several 'examples' then they _really_ should be putting them in the ABNF and codifying their proper usage. Otherwise there will only be a tag/parameter but no common values for the tag/parameter; not very useful in a standard intended to promote interoperability. 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 00595A9F85256957_= Content-Type: text/html; charset="us-ascii"
Frank suggested:
>   qualvalparam = "QUALVALUE" "=" text

Correct.  The '=' should have been quoted.

>   qualvalparam = "QUALVALUE" = text

Nope, thats what I had originally.  In order for the '=' to be part of the stream, it must be quoted.

However, if the SKiCal folks are planning on standardizing several 'examples' then they _really_ should be putting them in the ABNF and codifying their proper usage.  Otherwise there will only be a tag/parameter but no common values for the tag/parameter; not very useful in a standard intended to promote interoperability.


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 00595A9F85256957_=-- From owner-ietf-calendar@mail.imc.org Tue Sep 12 11:26: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 LAA06645 for ; Tue, 12 Sep 2000 11:26:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19151 for ietf-calendar-bks; Tue, 12 Sep 2000 08:07:37 -0700 (PDT) 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 IAA19146 for ; Tue, 12 Sep 2000 08:07:35 -0700 (PDT) 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 LAA11082; Tue, 12 Sep 2000 11:08:13 -0400 Received: from cst.ca (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 SVBYJZT9; Tue, 12 Sep 2000 11:08:12 -0400 Message-ID: <39BE46DD.E6E42084@cst.ca> Date: Tue, 12 Sep 2000 11:08:13 -0400 From: George Babics X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour , Doug Royer CC: ietf-calendar@imc.org Subject: VCOMMAND Specification 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 The only definition or specification given about VCOMMAND and CMDID are in section 2.7 of CAP: * A new iCalendar component, VCOMMAND, has been added. VCOMMANDs are needed to fully specify CAP commands. * TARGET is a new property within the VCOMMAND component. It indicates the calendars to which the command applies * CMDID is a Command ID that is used in a VCOMMAND to uniquely identify a command. Responses to a VCOMMAND will contain the same CMDID. If I understand it correctly: - VCOMMANDs are required for all CAP commands? (Or what is it meant by "fully specify"?) - CMDIDs are specified only with VCOMMAND? - TARGETs are only specified in VCOMMAND? If the above is true, then why are there many examples of CAP commands without VCOMMANDs, and TARGETs and CMDIDs outside of VCOMMANDs? (Perhaps VCOMMAND was added in a latter version of the draft and some of the examples were not updated.) If the above is false, then can someone clarify the meaning and purpose of VCOMMAND. Thanks, George From owner-ietf-calendar@mail.imc.org Tue Sep 12 11:39: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 LAA07028 for ; Tue, 12 Sep 2000 11:39:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19839 for ietf-calendar-bks; Tue, 12 Sep 2000 08:21:00 -0700 (PDT) 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 IAA19835 for ; Tue, 12 Sep 2000 08:20:58 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e8CFC8V24261 for ; Tue, 12 Sep 2000 08:12:14 -0700 (PDT) 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 G0S5DH00.5GF; Tue, 12 Sep 2000 08:22:29 -0700 Message-ID: <39BE4B3F.48080822@netscape.com> Date: Tue, 12 Sep 2000 08:26:55 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: George Babics CC: Doug Royer , ietf-calendar@imc.org Subject: Re: VCOMMAND Specification References: <39BE46DD.E6E42084@cst.ca> Content-Type: multipart/mixed; boundary="------------F9FBB49540B0EC80E5B3A98E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F9FBB49540B0EC80E5B3A98E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > The only definition or specification given about VCOMMAND and > CMDID are in section 2.7 of CAP: > > * A new iCalendar component, VCOMMAND, has been added. VCOMMANDs are > needed to fully specify CAP commands. > > * TARGET is a new property within the VCOMMAND component. It indicates > the calendars to which the command applies > > * CMDID is a Command ID that is used in a VCOMMAND to uniquely identify > a command. Responses to a VCOMMAND will contain the same CMDID. > > If I understand it correctly: > > - VCOMMANDs are required for all CAP commands? (Or what is it meant by > "fully specify"?) "fully specify" is misleading, it should be removed. VCOMMANDs are the way to specify a CAP command. > - CMDIDs are specified only with VCOMMAND? > - TARGETs are only specified in VCOMMAND? yep > If the above is true, then why are there many examples of CAP > commands without VCOMMANDs, and TARGETs and CMDIDs outside of VCOMMANDs? > (Perhaps VCOMMAND was added in a latter version of the draft and some > of the examples were not updated.) The examples are messed up. -Steve --------------F9FBB49540B0EC80E5B3A98E 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 --------------F9FBB49540B0EC80E5B3A98E-- From owner-ietf-calendar@mail.imc.org Tue Sep 12 14:00: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 OAA10814 for ; Tue, 12 Sep 2000 14:00:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA26632 for ietf-calendar-bks; Tue, 12 Sep 2000 10:42:49 -0700 (PDT) Received: from corp.talkcity.com (campbell.corp.talkcity.com [216.206.164.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26628 for ; Tue, 12 Sep 2000 10:42:47 -0700 (PDT) Received: from TORAN2K ([172.18.150.182]) by corp.talkcity.com (8.10.2/8.10.2) with SMTP id e8CHiOK12402 for ; Tue, 12 Sep 2000 10:44:24 -0700 (PDT) Reply-To: From: "tkanazawa" To: Subject: iCalendar Date: Tue, 12 Sep 2000 10:49:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0051_01C01CA7.2D999550" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C01CA7.2D999550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I have a question. Is there any software that uses iCalendar? Where can I get more information of how to use iCalendar? I am interested to know it looks like. Many thanks. Toran Toran Kanazawa Software Engineer Talk City Inc. Tel: (408) 871-5273 Fax: (408) 871-5235 tkanazawa@corp.talkcity.com ------=_NextPart_000_0051_01C01CA7.2D999550 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjMRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANAHCQAMAAoAMQAAAAIAKQEB A5AGABgHAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAACgAAAGlDYWxlbmRhcgAAAAIBcQABAAAAFgAAAAHAHOHUf+Be+BzUVUKInec4ppxo4TsAAAIB HQwBAAAAIQAAAFNNVFA6VEtBTkFaQVdBQENPUlAuVEFMS0NJVFkuQ09NAAAAAAsAAQ4AAAAAQAAG DgDOLrvhHMABAgEKDgEAAAAYAAAAAAAAAMPa/bgMDdQRkisAAQI3BBDCgAAACwAfDgEAAAACAQkQ AQAAAKkCAAClAgAAJQQAAExaRnXp7pvgAwAKAHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBj aArAc/BldDAgBxMCgwBQEGb4cHJxDlAQ3wHxEuEE9AESn0x1Y2lkYSBSSABwZHcFEHQLgGfNAoMz BWUU301hFsAEEKBlIElUQwKAfQqAaQjIIDsJaTUXUAoyMWw2MBqTDjA1CbsakzX/AFAbBABQG4Mb UB1LHoEbdPwwMhv8H4Yb7SABHOUZs1BzdHlsB5BoCeB0HnsHsAWwAMACc3MxIEkj0GFkFtEgMRmT XJJ2CJB3awuAZDQMYJ5jAFALAwu1FkBlbAkALiwKogqECoBJJPBhdlsZQBYwcQpQI3BpAiAuOyhl BCB0I9AJcCkgbnnoIHNvAYB3CsAZQCpwmRjwIHURIAQgaUMHQIMJ8BYgcj8gIFcqg9ZjA5EowGcR MCAEYCqhbwuAAhAkUSmSICsgJPBvOQfgdG8r4iw7KMBhbT0uQXQqkSNwCYAvcmtuSy9RFrAgCQBv awQgbPhpa2Up1SgEGOAq4Suh9m4ykDMLVAWwA5EK4yhG5zYuCzAy4GVwC5Ax8RYQ+GN0bAqxJMEI 0ABBDDChEgMyNCBUC9IyLwAbNXI5dEs55ABwYXphdytQNuo4CmIC0RRCJ3FT/SsmRQ8gC4AJ4BfA Njo48KkOUGV4N9BkK0A0IqHbFzML8Dg5wTjwMykgOOH3ObAJUDjwNTHQOOI1oT/hfCBDQpMAoEHi FMBCQnl9QplJQpMLkEHiAOA48Db+ICnQOPIoFEAlChEC0TljFRFQVCewOizgKDQwgDgpIDg3MS0O QMY3QaA1tUZheEhwSKqmM0JgKAR0aztlQAWhZHAuAZBsaxYAI4Au/wWgMOA1qgswOPAC0QFAKBMF GbEAT0AAAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AIIAYAAAAAAMAAAAAA AABGAAAAABCFAAAAAAAAAwAPgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAADAD2ACCAGAAAA AADAAAAAAAAARgAAAABShQAAJ2oBAAsASoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwBM gAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAE2ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAB4AZIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAALAGWACCAGAAAAAADA AAAAAAAARgAAAAAGhQAAAAAAAB4AeIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAA AAAeAHmACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgB6gAggBgAAAAAAwAAA AAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsAgIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAA AgH4DwEAAAAQAAAAw9r9uAwN1BGSKwABAjcEEAIB+g8BAAAAEAAAAMPa/bgMDdQRkisAAQI3BBAC AfsPAQAAAJYAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/ uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXHRlc3RcTG9jYWwgU2V0dGluZ3Nc QXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xvdXRsb29rLnBzdAAAAAMA/g8FAAAA AwANNP03AAACAX8AAQAAADsAAAA8TkVCQkpDQ0xNRE5MUFBJUEFJQk5FRUtNQ0JBQS50a2FuYXph d2FAY29ycC50YWxrY2l0eS5jb20+AAADAAYQbzGT0gMABxD3AAAAAwAQEAAAAAADABEQAAAAAB4A CBABAAAAZQAAAEhFTExPLElIQVZFQVFVRVNUSU9OSVNUSEVSRUFOWVNPRlRXQVJFVEhBVFVTRVNJ Q0FMRU5EQVI/V0hFUkVDQU5JR0VUTU9SRUlORk9STUFUSU9OT0ZIT1dUT1VTRUlDQUxFTkQAAAAA baM= ------=_NextPart_000_0051_01C01CA7.2D999550-- From owner-ietf-calendar@mail.imc.org Wed Sep 13 07:13:55 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 HAA04516 for ; Wed, 13 Sep 2000 07:13:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA29235 for ietf-calendar-bks; Wed, 13 Sep 2000 03:53:17 -0700 (PDT) Received: from marathon.wipro.net.in (marathon.wipro.net.in [202.177.128.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29225 for ; Wed, 13 Sep 2000 03:53:08 -0700 (PDT) Received: from rakshak ([202.177.157.194]) by marathon.wipro.net.in (Netscape Messaging Server 4.15) with ESMTP id G0TNTT00.54U; Wed, 13 Sep 2000 16:28:41 +0530 Received: from 192.168.3.1 by rakshak ([192.168.3.3] running VPOP3) with ESMTP; Wed, 13 Sep 2000 16:27:23 +0530 Received: from earth.canon-in.com (earth [192.168.3.5]) by NT_SERVER.ho.canon.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SZ1463MG; Wed, 13 Sep 2000 16:25:17 +0530 Received: by EARTH with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 16:24:48 +0530 Message-ID: From: Anil Sharma To: tkanazawa@corp.talkcity.com, ietf-calendar@imc.org Subject: RE: iCalendar Date: Wed, 13 Sep 2000 16:24:47 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Server: VPOP3 V1.4.0b - Registered to: Canon India Limited Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is one being implemented by me. You can't 'use' iCalendar. You have to implement it. Regards, Anil > -----Original Message----- > From: tkanazawa [mailto:tkanazawa@corp.talkcity.com] > Sent: Tuesday, September 12, 2000 11:20 PM > To: ietf-calendar@imc.org > Subject: iCalendar > > Hello, > > I have a question. > Is there any software that uses iCalendar? Where can I get more > information of how to use iCalendar? I am interested to know it looks > like. > > Many thanks. > > Toran > > > > Toran Kanazawa > Software Engineer > > Talk City Inc. > Tel: (408) 871-5273 > Fax: (408) 871-5235 > tkanazawa@corp.talkcity.com > > > > -------------------------------------------------------------------------- > -- > Visit us at http://www.canon-asia.com > From owner-ietf-calendar@mail.imc.org Wed Sep 13 12:10: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 MAA11361 for ; Wed, 13 Sep 2000 12:10:40 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA10741 for ietf-calendar-bks; Wed, 13 Sep 2000 08:56:20 -0700 (PDT) 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 IAA10731 for ; Wed, 13 Sep 2000 08:56:16 -0700 (PDT) From: Bruce_Kahn@iris.com To: Cc: ietf-calendar@imc.org Subject: Re: iCalendar X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Wed, 13 Sep 2000 12:02:10 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/13/2000 11:58:30 AM, Serialize complete at 09/13/2000 11:58:31 AM, Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/13/2000 11:58:31 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0057DD9885256959_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0057DD9885256959_= Content-Type: text/plain; charset="us-ascii" Toran asked: >Is there any software that uses iCalendar? There are several packages that implement iCalendar to one degree or another. There is Lotus Organzier (5.x or 6.x). Sun has a Calendar Server that supports it. Some versions of Outlook (Express too??) support it. Lotus Notes will have it soon. Exchange is to get it soon too. There is also Eric B's nifty libical package you can check out. There are other vendors that also support iCalendar to various degrees but in order to avoid overlooking some, Id hope they chime in with "We support it in product X"... >Where can I get more information >of how to use iCalendar? Not sure if you want an implementors guide (which is a draft that is being worked on by some folks in this WG) or if you want a "Users Guide" for educating users about what iCalendar is and what it is used for. The former can be found at http://www.imc.org/draft-ietf-calsch-imp-guide but the latter doesnt exist. Thats a job best done outside this WG... >I am interested to know it looks like. I would suggest you browse the RFC 2445 to get an understanding of what iCalendar is. Then really read the RFCs 2446 & 2447 to get a better understanding of what iCalendar looks like in actual use. 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 0057DD9885256959_= Content-Type: text/html; charset="us-ascii"
Toran asked:
>Is there any software that uses iCalendar?

There are several packages that implement iCalendar to one degree or another.  There is Lotus Organzier (5.x or 6.x).  Sun has a Calendar Server that supports it.  Some versions of Outlook (Express too??) support it.  Lotus Notes will have it soon.  Exchange is to get it soon too.  There is also Eric B's nifty libical package you can check out.  There are other vendors that also support iCalendar to various degrees but in order to avoid overlooking some, Id hope they chime in with "We support it in product X"...

>Where can I get more information
>of how to use iCalendar?

Not sure if you want an implementors guide (which is a draft that is being worked on by some folks in this WG) or if you want a "Users Guide" for educating users about what iCalendar is and what it is used for.  The former can be found at http://www.imc.org/draft-ietf-calsch-imp-guide but the latter doesnt exist.  Thats a job best done outside this WG...

>I am interested to know it looks like.

I would suggest you browse the RFC 2445 to get an understanding of what iCalendar is.  Then really read the RFCs 2446 & 2447 to get a better understanding of what iCalendar looks like in actual use.  

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 0057DD9885256959_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 13 12:54:30 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 MAA12591 for ; Wed, 13 Sep 2000 12:54:29 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA14530 for ietf-calendar-bks; Wed, 13 Sep 2000 09:41:57 -0700 (PDT) Received: from mail.lan-aces.com (SMTP.LAN-ACES.COM [206.109.52.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14526 for ; Wed, 13 Sep 2000 09:41:56 -0700 (PDT) Message-Id: <200009131641.JAA14526@ns.secondary.com> Received: from [206.109.52.2] (rpatters@mail.lan-aces.com) by mail.lan-aces.com; Wed, 13 Sep 2000 11:44:08 -0500 X-WM-Posted-At: mail.lan-aces.com; Wed, 13 Sep 00 11:44:08 -0500 Date: Wed, 13 Sep 2000 11:44:09 -0500 From: Ralph.Patterson@lan-aces.com To: tkanazawa@corp.talkcity.com cc: ietf-calendar@imc.org Reply-to: Ralph.Patterson@lan-aces.com Subject: cc: RE: iCalendar X-Mailer: Office-Logic/Win32 6.10 X-Net-User: rpatters MIME-Version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA14527 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit *** Comment from Ralph Patterson on 9/13/2000 at 9:59:44 a CST *** Toran, LAN-ACES, Incorporated includes iCalendar compliant transaction information in the Office-Logic Groupware package as well as the WebScheduler (TM) software. When scheduling an appointment with users, a message is sent to the attendee with the information in both a text and iCalendar format. It is then the responsibility of the receiving client to decide how to handle the information. In the case of Office-Logic, it shows up as a dialog box on the bottom of the e-mail message with Accept, Decline, or Tentative and an optional Alarm field. You can download a trial of the software from http://www.LAN-ACES.com and take a look if you would like. Regards, Ralph Patterson (additional contact information is at the bottom of this message) *** End of comment *** On Wed, Sep 13, 2000 5:54 a, Anil Sharma wrote: > >Date: Wed, 13 Sep 2000 16:24:47 +0530 >From: Anil Sharma >To: tkanazawa@corp.talkcity.com, ietf-calendar@imc.org >Subject: RE: iCalendar > >There is one being implemented by me. You can't 'use' iCalendar. You have to >implement it. > >Regards, >Anil > >> -----Original Message----- >> From: tkanazawa [mailto:tkanazawa@corp.talkcity.com] >> Sent: Tuesday, September 12, 2000 11:20 PM >> To: ietf-calendar@imc.org >> Subject: iCalendar >> >> Hello, >> >> I have a question. >> Is there any software that uses iCalendar? Where can I get more >> information of how to use iCalendar? I am interested to know it looks >> like. >> >> Many thanks. >> >> Toran >> >> >> >> Toran Kanazawa >> Software Engineer >> >> Talk City Inc. >> Tel: (408) 871-5273 >> Fax: (408) 871-5235 >> tkanazawa@corp.talkcity.com >> >> >> >> -------------------------------------------------------------------------- >> -- >> Visit us at http://www.canon-asia.com >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< LAN-ACES, Inc. mailto: Ralph.Patterson@LAN-ACES.COM Support: mailto:support@lan-aces.com ... (281) 890-9786 Sales: mailto:sales@lan-aces.com ... (800)-LAN-ACES (281.890.9787) FAX: (281)-890-9731 http://www.lan-aces.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Office-Logic Groupware (Formerly Right Hand Man) Version 6.x information available on our web site! Ask your sales rep about Competitive Upgrades!!!! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Software Piracy and the Law --------------------------- United States law prohibits duplicating software for profit, making multiple copies for use by different users within an organization, and giving an unauthorized copy to another individual. If caught with pirated software, you or your company may be tried under both civil and criminal law. A civil action may be instituted for injunction, actual damages (including infringer's profits), or statutory damages up to $100,000 per infringement. Criminal penalties for copyright infringement include fine up to $250,000 and jail terms up to five years, or both. Have a nice day! ---------------------------- From owner-ietf-calendar@mail.imc.org Wed Sep 13 14:19: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 OAA15372 for ; Wed, 13 Sep 2000 14:19:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA17351 for ietf-calendar-bks; Wed, 13 Sep 2000 10:55:53 -0700 (PDT) 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 KAA17347 for ; Wed, 13 Sep 2000 10:55:51 -0700 (PDT) From: MCiavari@meetingmaker.com Received: by lnsmtp.on.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 85256959.0062FCD5 ; Wed, 13 Sep 2000 14:01:12 -0400 X-Lotus-FromDomain: ON TECHNOLOGY To: ietf-calendar@imc.org Message-ID: <85256959.0062FADA.00@lnsmtp.on.com> Date: Wed, 13 Sep 2000 13:48:53 -0400 Subject: Timezone URL 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: Hi guys, does anyone have the URL handy to the Olsen database containing the zip files for all timezones? Can you send it to me please... Thanks... Michael Ciavarini From owner-ietf-calendar@mail.imc.org Thu Sep 14 07:36:30 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 HAA08640 for ; Thu, 14 Sep 2000 07:36:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA12891 for ietf-calendar-bks; Thu, 14 Sep 2000 04:21:58 -0700 (PDT) Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA12886 for ; Thu, 14 Sep 2000 04:21:56 -0700 (PDT) Received: from modem-181.algae-blennie.dialup.pol.co.uk ([62.136.222.181] helo=helixcode.com) by cmailg3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 13ZX7f-0001ut-00; Thu, 14 Sep 2000 12:24:08 +0100 Message-ID: <39BFB949.7CC16FDD@helixcode.com> Date: Wed, 13 Sep 2000 18:28:41 +0100 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: Bruce_Kahn@iris.com CC: tkanazawa@corp.talkcity.com, ietf-calendar@imc.org Subject: Re: iCalendar 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: > > Toran asked: > >Is there any software that uses iCalendar? > > There are several packages that implement iCalendar to one degree or another. There is Lotus Organzier (5.x or 6.x). Sun has a Calendar Server that supports > it. Some versions of Outlook (Express too??) support it. Lotus Notes will have it soon. Exchange is to get it soon too. There is also Eric B's nifty > libical package you can check out. There are other vendors that also support iCalendar to various degrees but in order to avoid overlooking some, Id hope > they chime in with "We support it in product X"... OK. We (Helix Code) support it as the native format in Evolution, via libical. Evolution is a free (GPL'ed) mailer/calendar/organizer for Unix systems, running under the Gnome environment. Release 1.0 should be in a few months. (http://www.helixcode.com) Damon From owner-ietf-calendar@mail.imc.org Thu Sep 14 10:27:46 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 KAA12962 for ; Thu, 14 Sep 2000 10:27:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17318 for ietf-calendar-bks; Thu, 14 Sep 2000 07:05:51 -0700 (PDT) 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 HAA17314 for ; Thu, 14 Sep 2000 07:05:51 -0700 (PDT) Received: (cpmta 27024 invoked from network); 14 Sep 2000 07:07:37 -0700 Received: from unknown (HELO sartre) (209.220.133.162) by smtp.criticalpath.net (209.228.12.56) with SMTP; 14 Sep 2000 07:07:37 -0700 X-Sent: 14 Sep 2000 14:07:37 GMT Message-ID: <010201c01e54$7dcda850$a285dcd1@sartre> From: "Colin DuPlantis" To: References: <39BFB949.7CC16FDD@helixcode.com> Subject: Re: iCalendar Date: Thu, 14 Sep 2000 07:01:39 -0700 Organization: Critical Path, Inc. 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > There are other vendors that also support iCalendar to various degrees but in order to avoid overlooking some, Id hope > > they chime in with "We support it in product X"... > On that note, Critical Path supports a subset of iCalendar within iCAP, a CAP-like protocol in our EventCenter (now known as InSchedule) product. This is a commercial product, nominally targeted at user communities in the 100s and up, which provides web enabled calendaring. More info: http://www.cp.net/products/insch_cal_overview.html. Thanks! - C From owner-ietf-calendar@mail.imc.org Sun Sep 17 03:18: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 DAA01888 for ; Sun, 17 Sep 2000 03:18:06 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA02749 for ietf-calendar-bks; Sat, 16 Sep 2000 23:57:45 -0700 (PDT) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02745 for ; Sat, 16 Sep 2000 23:57:43 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA05865 for ietf-calendar@imc.org; Sun, 17 Sep 2000 00:00:03 -0700 (PDT) Date: Sun, 17 Sep 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200009170700.AAA05865@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 Sep 18 12:48: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 MAA14461 for ; Mon, 18 Sep 2000 12:48:37 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA18761 for ietf-calendar-bks; Mon, 18 Sep 2000 09:21:13 -0700 (PDT) Received: from agony.busboom.org (24-25-200-10.san.rr.com [24.25.200.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18757 for ; Mon, 18 Sep 2000 09:21:11 -0700 (PDT) From: eric@softwarestudio.org Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id JAA13767 for ; Mon, 18 Sep 2000 09:23:46 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 18 Sep 2000 09:23:45 -0700 (PDT) X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: RFC 2445 Issues List Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463809014-1618013071-969293792=:3085" Content-ID: Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463809014-1618013071-969293792=:3085 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Frank Dawson and I have compiled a list of all known ( to us ) issues with RFC 2445. The list is online as html at: http://softwarestudio.org/iCal/2445Issues.html An abbreviated version of the list is also attached to this email. The text version does not have the links to the email archive that are in the HTML version. Frank and I are currently working on creating proposed text to address each issue, except for typos. I will be maintaining the list and posting it regularly both to ietf-calendar@imc.org and to the website. To add new items to the list, please post them to ietf-calendar@imc.org, and please try to include some proposed test that will address the problem. Changes covered by RFC 2445 Section 7 must be in the format described in that section. If you notice an issue that has been discussed on the list in the past, has not been resolved, and is not on the list, or to note errors in the list, please contact me directly. eric. ---1463809014-1618013071-969293792=:3085 Content-Type: TEXT/PLAIN; NAME="Issues.txt" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="Issues.txt" Content-Transfer-Encoding: BASE64 UkZDMjQ0NSBJc3N1ZXMgTGlzdA0KDQpUaGlzIGlzIGEgc3VtbWFyeSB2ZXJz aW9uIG9mIHRoZSBSRkMyNDQ1IGlzc3VlcyBsaXN0LiBQbGVhc2Ugc2VlIHRo ZQ0KaHRtbCB2ZXJzaW9uICggZmlsZTovLy9ob21lL2VyaWMvZG9jdW1lbnRz L2lDYWwvSXNzdWVzLmh0bWwgKSBmb3INCmNvbXBsZXRlIGRldGFpbHMuDQoN Cg0KMCAgRGlzcG9zaXRpb24gVHlwZSAgIFN1bW1hcnkNCjEgIE9wZW4gICAg IElDUiAgICBGTVRZUEUgY2FuJ3QgaG9sZCBNSU1FIHR5cGU7IG5vIC8gYWxs b3dlZA0KMiAgT3BlbiAgICAgSUNSICAgIEJZREFZIHRlcm1pbm9sb2d5IGlz IENvbmZ1c2luZy4gDQozICBPcGVuICAgICBFUlIgICAgREFURSBEVFNUQVJU IGFuZCBSRUNVUlJFTkNFLUlEDQo1ICBPcGVuICAgICBFUlIgICAgTXVsdGlw bGUgQVRURU5ERUUgd2l0aCBTYW1lIFZhbHVlDQo2ICBPcGVuICAgICBJQ1Ig ICAgTWl4ZWQgREFURSBhbmQgREFURS1USU1FDQo3ICBPcGVuICAgICBJQ1Ig ICAgSW5jb25zaXN0ZW5jZXkgaW4gVUlEIHByb3ANCjggIER1cGUgKDEpIElD UiAgICBTcGVjaWZ5IEZpbGUgbmFtZSBpbiBBVFRBQ0g/DQo5ICBPcGVuICAg ICBFUlIgICAgV2Vla251bWJlciBpbmRlcGVuZGVudCBvZiBzdGFydCBvZiB3 ZWVrPw0KMTMgT3BlbiAgICAgRVJSICAgIFBVQkxJU0ggJiBObyBPcmdhbml6 ZXIgaW4gTm9uLWdyb3VwIHNjaGVkdWxlZA0KCQkgICBtZWV0aW5ncw0KMTUg T3BlbiAgICAgSUNSICAgIFJlc3RyaWN0aW9ucyBvbiBSRUNVUiBydWxlcw0K MTcgT3BlbiAgICAgQ1IgICAgIENoYW5nZXMgdG8gUkVRVUVTVC1TVEFUVVMN CjE4IE9wZW4gICAgIENSICAgICBOZXcgVFJBTlNQIFZhbHVlcyBmb3IgQ0FQ DQoxOSBPcGVuICAgICBDUiAgICAgTmV3IEdFT19CT1VORFMgcHJvcGVydHkN CjIwIE9wZW4gICAgIENSICAgICBBZGQgTmV3IENBUCBjb21wb25lbnRzIHRv IHNwZWMNCjIyIE9wZW4gICAgIElDUiAgICAgQUJORiBkb2Vzbid0IGN1cnJl bnRseSBhbGxvdyByZWdpc3RlcmVkIGV4dGVuc2lvbnMNCjIzIE9wZW4gICAg IElDUiAgICBEaXNhbGxvdyBSRUNVUlJFTkNFLUlEIG9mIERBVEUgZm9yID4x IG9jY3VyZW5jZXMgcGVyDQoJCSAgIGRheQ0KMTYgT3BlbiAgICAgSU5GTyAg IFdoeSBpcyBVTlRJTCBvbmx5IFVUQz8NCjM0IE9wZW4gICAgIFR5cG8gICBQ YWdlIDExMCwgc2VjdGlvbiA0LjguNC41LCBjYW5jZWxlZCB0byBjYW5jZWxs ZWQgZm9yDQoJCSAgIGNvbnNpc3RlbmN5DQozMCBPcGVuICAgICBUeXBvICAg UGFnZSA0Niwgc2VjdGlvbiA0LjMuMTEsIC8gJXgzQy01QiB0byAvICV4M0Mt NUIgLw0KMTAgT3BlbiAgICAgVHlwbyAgIENvbmZsaWN0IGluIE11bHRpcGxl IG9jY3VycmVuY2Ugb2YgREVTQ1JJUFRJT04NCjMyIE9wZW4gICAgIFR5cG8g ICBQYWdlIDg0LCBzZWN0aW9uIDQuOC4xLjcsIEYxMjMsIHRvIEYxMjNcLA0K MzEgT3BlbiAgICAgVHlwbyAgIFBhZ2UgNTIsIHNlY3Rpb24gNC42LCBmcmVl YnVzeWMgLyB0byBmcmVlYnVzeWMNCjMzIE9wZW4gICAgIFR5cG8gICBQYWdl IDg4LCBzZWN0aW9uIDQuOC4xLjExLCBzdGF0cGFyYW1dIHRvIHN0YXRwYXJh bQ0KMzggT3BlbiAgICAgVHlwbyAgIFBhZ2UgMTM4LCBzZWN0aW9uIDUsIHRl eHQvY2FsZW5kYXIgdG8NCgkJICAgdGV4dC9jYWxlbmRhcjtNRVRIT0Q9eHl6 O0NPTVBPTkVOVA0KCQkgICA9VkVWRU5UDQozOSBPcGVuICAgICBUeXBvICAg UGFnZSAxMzgsIHNlY3Rpb24gNSwgVFJJR0dFUjoxOTk4MDQwM1QxMjAwMDAg dG8NCgkJICAgVFJJR0dFUjoxOTk4MDQwM1QxMjAwMDBaDQo0MCBPcGVuICAg ICBUeXBvICAgUGFnZSAxNDMsIHNlY3Rpb24gNy4yLjQsIC4uaXMgYXBwb2lu dGVkIHRvIHRoZS4uIHRvDQoJCSAgIC4uaXMgYXBwb2ludGVkIGJ5IHRoZS4u DQozNSBPcGVuICAgICBUeXBvICAgUGFnZSAxMTAsIHNlY3Rpb24gNC44LjQu NSwgW3JlbHBhcmFtXSB0byByZWxwYXJhbQ0KMzYgT3BlbiAgICAgVHlwbyAg IFBhZ2UgMTEwLCBzZWN0aW9uIDQuOC40LjUsIHhwYXJtIHRvIHhwYXJhbQ0K MzcgT3BlbiAgICAgVHlwbyAgIFBhZ2UgMTI4LCBzZWN0aW9uIDQuOC42LjMs IC8gdHJpZ2FicykgdG8gLyB0cmlnYWJzKQ0KCQkgICBDUkxGDQo0ICBPcGVu ICAgICBUeXBvICAgT3JkZXJpbmcgb2YgUGFyYW1ldGVycyBpbiBBQk5GDQoy MSBPcGVuICAgICBUeXBvICAgNC4yLjE4ICBTZW50IEJ5IGV4YW1wbGU6IHVz ZSA9IGluc3RlYWQgb2YgOg0KMTIgT3BlbiAgICAgVHlwbyAgIFR5cG8gaW4g NC44LjEuNw0KMTEgT3BlbiAgICAgVHlwbyAgIE5lZWQgQ1JMRiBpbiBUUklH R0VSIHNwZWMNCjE0IE9wZW4gICAgIFR5cG8gICBGaXggZXJyb3JzIGluIGV4 YW1wbGVzDQoyNyBPcGVuICAgICBUeXBvICAgUGFnZSAyMiwgc2VjdGlvbiA0 LjIuNiwgTVVTVCBlYWNoIGJlIHNwZWNpZmllZCB0bw0KCQkgICBNVVNUIGJl IHNwZWNpZmllZA0KMjggT3BlbiAgICAgVHlwbyAgIFBhZ2UgMjIsIHNlY3Rp b24gNC4yLjYsIFRoZSBpbmRpdmlkdWFsIFVSSSB0byBUaGUNCgkJICAgVVJJ DQoyOSBPcGVuICAgICBUeXBvICAgUGFnZSA0NSwgc2VjdGlvbiA0LjMuMTEs IEVTQ0FQRUQtQ0hBUiA9ICB0bw0KCQkgICBFU0NBUEVELUNIQVIgPSAoDQoy NCBPcGVuICAgICBUeXBvICAgUGFnZSAxNCwgc2VjdGlvbiA0LjEsIHgtdG9r ZW4gdG8geC1uYW1lDQoyNSBPcGVuICAgICBUeXBvICAgUGFnZSAyMSwgc2Vj dGlvbiA0LjIuNCwgdXNlcyB0byB1c2Vycw0KMjYgT3BlbiAgICAgVHlwbyAg IFBhZ2UgMjIsIHNlY3Rpb24gNC4yLjYsIHZhbHVlcyB0byB2YWx1ZQ0K ---1463809014-1618013071-969293792=:3085-- From owner-ietf-calendar@mail.imc.org Tue Sep 19 12:21: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 MAA19250 for ; Tue, 19 Sep 2000 12:21:45 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA01399 for ietf-calendar-bks; Tue, 19 Sep 2000 08:59:45 -0700 (PDT) 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 IAA01394 for ; Tue, 19 Sep 2000 08:59:43 -0700 (PDT) From: Bruce_Kahn@iris.com To: eric@softwarestudio.org Cc: ietf-calendar@imc.org Subject: RFC 2445 Issue: Mixed DATE and DATE-TIME X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Tue, 19 Sep 2000 12:06:07 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/19/2000 12:02:27 PM, Serialize complete at 09/19/2000 12:02:27 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005839E98525695F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005839E98525695F_= Content-Type: text/plain; charset="us-ascii" In quickly glancing at the nice list Frank and Eric put together I wanted to revisit one topic: 6 Open ICR Mixed DATE and DATE-TIME The linked page msg02600 (http://www.imc.org/ietf-calendar/mail-archive/msg02600.html) reads in part: The value types for DTSTART, DTEND, DUE, RDATE, EXDATE, RRULE/EXRULE (for UNTIL value components) MUST match types. One caveat to this is recurrence rules and the ability to have BYHOUR, BYMINUTE, BYSECOND. Perhaps this is addressed in one of the other issues but if there a DTSTART;VALUE=DATE and an RRULE:...,BYHOUR=8,9 then the RRULE does NOT match the type of the DTSTART. I pointed this out recently but noone responded that I saw. I did it WRT RECURRENCE-ID and the requirement that the data type match DTSTART but there was a BYHOUR on the RRULE... Ill let the wordsmiths work on the proper text for dealing with this case. I would suggest that recurrence rules be precluded from having BYxxx values that generate data points that are not of the same data type. (Chalk it up on the list of growing recurrence rule changes...) 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 005839E98525695F_= Content-Type: text/html; charset="us-ascii"
In quickly glancing at the nice list Frank and Eric put together I wanted to revisit one topic:

6  Open     ICR    Mixed DATE and DATE-TIME

The linked page msg02600 (http://www.imc.org/ietf-calendar/mail-archive/msg02600.html) reads in part:

The value types for DTSTART, DTEND, DUE, RDATE, EXDATE, RRULE/EXRULE (for
UNTIL value components) MUST match types.
One caveat to this is recurrence rules and the ability to have BYHOUR, BYMINUTE, BYSECOND.  Perhaps this is addressed in one of the other issues but if there a DTSTART;VALUE=DATE and an RRULE:...,BYHOUR=8,9 then the RRULE does NOT match the type of the DTSTART.  I pointed this out recently but noone responded that I saw.  I did it WRT RECURRENCE-ID and the requirement that the data type match DTSTART but there was a BYHOUR on the RRULE...

Ill let the wordsmiths work on the proper text for dealing with this case.  I would suggest that recurrence rules be precluded from having BYxxx values that generate data points that are not of the same data type.  (Chalk it up on the list of growing recurrence rule changes...)

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 005839E98525695F_=-- From owner-ietf-calendar@mail.imc.org Tue Sep 19 12:42: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 MAA19762 for ; Tue, 19 Sep 2000 12:42:48 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA02446 for ietf-calendar-bks; Tue, 19 Sep 2000 09:22:27 -0700 (PDT) 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 JAA02441 for ; Tue, 19 Sep 2000 09:22:25 -0700 (PDT) From: Bruce_Kahn@iris.com To: eric@softwarestudio.org Cc: ietf-calendar@imc.org Subject: RFC 2445 Issue: ABNF doesn't currently allow registered extensions X-Mailer: Lotus Notes Build V60_08292000 August 29, 2000 Message-ID: Date: Tue, 19 Sep 2000 12:28:50 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 09/19/2000 12:25:09 PM, Serialize complete at 09/19/2000 12:25:09 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005A4DF88525695F_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A4DF88525695F_= Content-Type: text/plain; charset="us-ascii" After a pass or two on the SKiCal drafts I revisited the ABNF in the RFCs and I think we need to revise the published iCalendar ABNF so that extensions can be more easily added by efforts like SKiCal. Im sure that Harald can correct my ABNF mistakes but the format we used for our ABNF does not allow for adding just new values. Harald has noted that a proper way to extend an ABNF is to use the form: param =/ "THIRD" or paramv2 = param / "THIRD" to indicate that an addition is being done. However, the way we wrote up much of our ABNF in RFC 2445, this is not that simple. For example, if we look at PARTSTAT (Section 4.2.12) you will see the following ABNF: partstatparam = "PARTSTAT" "=" ("NEEDS-ACTION" ; Event needs action / "ACCEPTED" ; Event accepted / "DECLINED" ; Event declined / "TENTATIVE" ; Event tentatively ; accepted / "DELEGATED" ; Event delegated / x-name ; Experimental status / iana-token) ; Other IANA registered ; status ; These are the participation statuses for a "VEVENT". Default is ; NEEDS-ACTION partstatparam /= "PARTSTAT" "=" ("NEEDS-ACTION" ; To-do needs action / "ACCEPTED" ; To-do accepted / "DECLINED" ; To-do declined / "TENTATIVE" ; To-do tentatively ; accepted / "DELEGATED" ; To-do delegated / "COMPLETED" ; To-do completed. ; COMPLETED property has ;date/time completed. / "IN-PROCESS" ; To-do in process of ; being completed / x-name ; Experimental status / iana-token) ; Other IANA registered ; status ; These are the participation statuses for a "VTODO". Default is ; NEEDS-ACTION [Snip] I can follow the intent of this ABNF, to describe 3 possible sets of values for PARTSTAT; one for vEvents, vToDos and VJournals. However, if I reread the ABNF, it appears that we are saying that parstatparam can be written as: "PARSTAT" "=" "ACCEPTED" "PARSTAT" "=" "IN-PROCESS". (Im sure Ill hear otherwise if Im misreading it!). Based on Haralds note on the SKiCal draft and ABNF, I think we really should have written the ABNF as: partstatparam = "PARTSTAT" "=" partstatparamval partstatparamval = ("NEEDS-ACTION" ; Event needs action / "ACCEPTED" ; Event accepted / "DECLINED" ; Event declined / "TENTATIVE" ; Event tentatively ; accepted / "DELEGATED" ; Event delegated / x-name ; Experimental status / iana-token) ; Other IANA registered ; status ; These are the participation statuses for a "VEVENT". Default is ; NEEDS-ACTION partstatparamval /= ("NEEDS-ACTION" ; To-do needs action / "ACCEPTED" ; To-do accepted / "DECLINED" ; To-do declined / "TENTATIVE" ; To-do tentatively ; accepted / "DELEGATED" ; To-do delegated / "COMPLETED" ; To-do completed. ; COMPLETED property has ;date/time completed. / "IN-PROCESS" ; To-do in process of ; being completed / x-name ; Experimental status / iana-token) ; Other IANA registered ; status ; These are the participation statuses for a "VTODO". Default is ; NEEDS-ACTION [Snip] so that anyone can easily add values to PARTSTAT by simply using: partstatparamvalSKi /= partstatparamval / ("DISCUSSED" .... ; Concept is discussed or just partstatparamval /= ("DISCUSSED" .... ; Concept is discussed So, in a nutshell I think that the ABNF we used in malformed in that it does not allow for easy extensions later on because we used the form "name" "=" "list_of_values" in the ABNF instead of "name" "=" "valuelist" & valuelist = "list_of_values" form. We should correct this when we correct the other ABNF oversight... Bruce PS: Someone should double check the proper use of "/=" or "=/" in ABNF and make sure we do it right... =========================================================================== 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 005A4DF88525695F_= Content-Type: text/html; charset="us-ascii"
After a pass or two on the SKiCal drafts I revisited the ABNF in the RFCs and I think we need to revise the published iCalendar ABNF so that extensions can be more easily added by efforts like SKiCal.  Im sure that Harald can correct my ABNF mistakes but the format we used for our ABNF does not allow for adding just new values.  Harald has noted that a proper way to extend an ABNF is to use the form:

   param =/ "THIRD"
or
   paramv2 = param / "THIRD"

to indicate that an addition is being done.  However, the way we wrote up much of our ABNF in RFC 2445, this is not that simple.  

For example, if we look at PARTSTAT (Section 4.2.12) you will see the following ABNF:

     partstatparam      = "PARTSTAT" "="
                        ("NEEDS-ACTION"        ; Event needs action
                       / "ACCEPTED"            ; Event accepted
                       / "DECLINED"            ; Event declined
                       / "TENTATIVE"           ; Event tentatively
                                               ; accepted
                       / "DELEGATED"           ; Event delegated
                       / x-name                ; Experimental status
                       / iana-token)           ; Other IANA registered
                                               ; status
    ; These are the participation statuses for a "VEVENT". Default is
    ; NEEDS-ACTION
    partstatparam      /= "PARTSTAT" "="
                        ("NEEDS-ACTION"        ; To-do needs action
                       / "ACCEPTED"            ; To-do accepted
                       / "DECLINED"            ; To-do declined
                       / "TENTATIVE"           ; To-do tentatively
                                               ; accepted
                       / "DELEGATED"           ; To-do delegated
                       / "COMPLETED"           ; To-do completed.
                                               ; COMPLETED property has
                                               ;date/time completed.
                       / "IN-PROCESS"          ; To-do in process of
                                               ; being completed
                       / x-name                ; Experimental status
                       / iana-token)           ; Other IANA registered
                                               ; status
    ; These are the participation statuses for a "VTODO". Default is
    ; NEEDS-ACTION
[Snip]
I can follow the intent of this ABNF, to describe 3 possible sets of values for PARTSTAT; one for vEvents, vToDos and VJournals.  However, if I reread the ABNF, it appears that we are saying that parstatparam can be written as: "PARSTAT" "=" "ACCEPTED" "PARSTAT" "=" "IN-PROCESS".  (Im sure Ill hear otherwise if Im misreading it!).  Based on Haralds note on the SKiCal draft and ABNF, I think we really should have written the ABNF as:

     partstatparam      = "PARTSTAT" "=" partstatparamval

    partstatparamval   = ("NEEDS-ACTION"        ; Event needs action
                       / "ACCEPTED"            ; Event accepted
                       / "DECLINED"            ; Event declined
                       / "TENTATIVE"           ; Event tentatively
                                               ; accepted
                       / "DELEGATED"           ; Event delegated
                       / x-name                ; Experimental status
                       / iana-token)           ; Other IANA registered
                                               ; status
    ; These are the participation statuses for a "VEVENT". Default is
    ; NEEDS-ACTION
    partstatparamval   /= ("NEEDS-ACTION"        ; To-do needs action
                       / "ACCEPTED"            ; To-do accepted
                       / "DECLINED"            ; To-do declined
                       / "TENTATIVE"           ; To-do tentatively
                                               ; accepted
                       / "DELEGATED"           ; To-do delegated
                       / "COMPLETED"           ; To-do completed.
                                               ; COMPLETED property has
                                               ;date/time completed.
                       / "IN-PROCESS"          ; To-do in process of
                                               ; being completed
                       / x-name                ; Experimental status
                       / iana-token)           ; Other IANA registered
                                               ; status
    ; These are the participation statuses for a "VTODO". Default is
    ; NEEDS-ACTION
[Snip]

so that anyone can easily add values to PARTSTAT by simply using:

     partstatparamvalSKi /= partstatparamval / ("DISCUSSED" ....       ; Concept is discussed
or just

     partstatparamval    /= ("DISCUSSED" ....       ; Concept is discussed
So, in a nutshell I think that the ABNF we used in malformed in that it does not allow for easy extensions later on because we used the form "name" "=" "list_of_values" in the ABNF instead of "name" "=" "valuelist" & valuelist = "list_of_values" form.  We should correct this when we correct the other ABNF oversight...

Bruce
PS: Someone should double check the proper use of "/=" or "=/" in ABNF and make sure we do it right...
===========================================================================
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 005A4DF88525695F_=-- From owner-ietf-calendar@mail.imc.org Wed Sep 20 06:08: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 GAA17059 for ; Wed, 20 Sep 2000 06:08:46 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA15872 for ietf-calendar-bks; Wed, 20 Sep 2000 02:48:42 -0700 (PDT) Received: from ns2.system-io.co.jp. (ns2.system-io.co.jp [203.139.112.11]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA15868 for ; Wed, 20 Sep 2000 02:48:40 -0700 (PDT) From: nile333@kadet.co.uk Received: from gnr.net by ns2.system-io.co.jp. (SMI-8.6/SMI-SVR4) id SAA14894; Wed, 20 Sep 2000 18:46:30 +0900 Date: Wed, 20 Sep 2000 18:46:30 +0900 Message-Id: <200009200946.SAA14894@ns2.system-io.co.jp.> To: nile333@kadet.co.uk Subject: So, How in the heck have you been? Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: So, How in the heck have you been? Do you remember holding previous conversations regarding business and money making opportunities? I did not send this to you in error! You Said: If only I could find an easier way to make a higher income! and If I had more money, I could spend more time with my Family, and less time at work and I sure could use more money so I could pay off my bills once and for all! And I would love to get involved in a business in which will generate money while I am not at work (like a Gas Pump)! Dear Friend, There is a possibility that we haven’t met, but you were chosen by someone to receive this E-Mail. Please, please, print this off and read thoroughly. Be sure that you don’t miss any of the points outlined. Then put it down, and then read it again. I am sending you a whole lot of information in which you might not understand the first time you read it. If you don’t believe this program will work for you, send it to 10-20 of your closest friends (in which you trust deeply), and ask them what they think? This really works! Have faith, don’t miss this opportunity, get involved also, and it will work for you as it does for us!!!! Due to the popularity of this letter on the Internet, A Major Nightly News Program recently dedicated an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make extra money at home. The results have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting. You will understand only if you get involved! ********** THE ENTIRE PLAN IS HERE BELOW ********** **** Print This Now For Future Reference **** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make AT LEAST $50,000 in less than 90 days! If not, forward this to someone who would like to make this kind of money. It works (like designed) but only for those who follow it to the letter! Please read this program THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! Hello, My name is Johnathon Rourke, I’m from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for the past twelve yearsdown-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year,I incurred many unforeseen financial problems. I owed my family, friends and creditors over$35,000. The economy was taking a toll on my business and I just could not seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life. I am writing to share the experience I hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion,were not cost effective. They were either toodifficult for me to comprehend or the initial investment was too muchfor me to risk to see if they would work. But as I was saying, in December of 1997 I received this program.I didn’t send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly. I couldn’t believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and a little worried about the legalaspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal ! After determining the program was LEGAL I decided WHY NOT!?!?? Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don’t need any paper for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. In less than one week,I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON’T SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT SEND OUT MORE PROGRAMS UNTIL YOU! DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL. Well, I had 196 orders for REPORT #2. 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, received $58,000 with more coming in every day. I paid off ALL my debts and bought a much need new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it won’t work if you don’t try it. This program does work, But you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won’t work and you’ll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose toparticipate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are financial trouble like I was, or you want to start your own business, consider this a sign. I DID! $$ Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, cpuld not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn’t working. Finally, I figured it out. It wasn’t me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don’t have to tell you what happened to the unemployment rate because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, THE RICH GET RICHER ANDTHE POOR GET POORER. The traditional methods of making money will never allow you to move up or get rich, inflation will see to that You have just received the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few months than you have everimagined.I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copyof this exciting report to everyone you can think of. One of the people you send this to may send out 50,000 and your name will be on everyone of them! REMEMBER though, ------ the MORE YOU SEND OUT, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU!! NOW DO IT!! BEFORE YOU delete this program from your in box, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. $$$ IT WORKS!!! $$$ Jody Jacobs Richmond, VA. HERE’S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say BULL, please read this program carefully. This is not a chain letter,but a perfectly legal money making business. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we sell and deliver a product for EVERY dollar received. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the EASIEST marketing plan anywhere! It is simply order filling by e-mail! The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E-COMMERCE, the information highway, the wave of the future ! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 each) They come to you by e-mail. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk e-mail service companies (search for bulk email) and have them send 25,000 50,000 emails for you about $49+. (4) Orders will come to you by postal mail simply e-mail them the Report they ordered. Let me ask you isn’t this about as easy as it gets? By the way there are over 50 MILLION e-mail address with millions more joining the internet each year so don’t worry about running out or saturation. People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and order one. Same thing with this letter. I received this letter many times then one day I decided it was time to try it. YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can’t sell them if you don’t order them). For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail each of the four reports.Save them on your computer so you can send them to the 1,000’s of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you’ve ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire e-mail to send by e-mail to prospects. Report #1 will tell you how to download bulk email software and email address so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month! Your cost to participate in this is practically nothing ( surely you can afford $20 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL let’s say that you decide to start small, just to see how it goes, and we’ll assume you and all those involved email out only 2,000 programs each. Let’s also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out thousands of thousands of programs instead of 2,000 (Why stop at 2000?) But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2.Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That’s 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let’s say you decide to start small to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response). Also assume that everyone else in YOUR ORGANIZATION gets only 10 downline members. Look how this small number accumulates to achieve the STAGGERING results below: 1St level your first 10 send you $5........................$50 2nd level 10 members from those 10 ($5 x 100)............$500 3rd level 10 members from those 100 ($5 x 1,000)......$5,000 4th level 10 members from those 1,000 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ------------------------------------------------55,5550 $$$$$ AMAZING ISN’T IT Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100’s of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! People are going to get emails about this plan from you or somebody else and many will work this plan the question is Don’t you want your name to be on the emails they will send out? *** DON’T MISS OUT !!!*** ***JUST TRY IT ONCE !!!*** ***SEE WHAT HAPPENS !!!*** ***YOU'LL BE AMAZED !!!*** ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can’t advertise until they receive the report! GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:-- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets write: (a) the number & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1b The Insider’s Guide to Advertising for Free on the Internet ORDER REPORT #1 FROM: NICK NICHOLAS 473 MICHIGAN ST ST.PAUL, MN 55102 NOTE: I and every member below are dedicated at helping you with this program so it will work for you also. TRY US! REPORT #2 The Insider’s Guide to Sending Bulk E-Mail on the Internet ORDER REPORT #2 FROM: DIANE COLON 1811 TAMARIND AVE # 206 LOS ANGELES, CA. 90028 REPORT #3 The Secrets to Multilevel Marketing on the Internet ORDER REPORT #3 FROM: MELISSA HOGENMILLER 3709 MONHEIM ROAD CONOVER, WI 54519 REPORT #4 How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet ORDER REPORT #4 FROM: CATHY BARROW 10 SYCAMORE STREET CONWAY, SC 29527 *************TIPS FOR SUCCESS*************** TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letter (with your name on them). --ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be patient and persistent with this program- If you follow the instructions exactly results WILL FOLLOW. $$$$ ************ YOUR SUCCESS GUIDELINES *************** Follow these guidelines to guarantee your success: If you don’t receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mail until you do. Then a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don’t continue advertising or sending e-mail until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question: ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? 1. If the answer is no, then please look at the following facts about this super simple MLM program: NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start! Nothing to learn, No skills needed! (Surely you know how to send email?) 2. No equipment to buy you already have a computer and internet connection so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Email copies of the reports are FREE!) 4. All of your customers pay you in CASH! This program will change your LIFE FOREEVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above __ SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOT: If you need help with starting a business, registering a business name, learning now income tax is handled, etc., contact your local office of the Small Business Administration (A Federal Agency) 1-800-827-5722 for free help and answers to questions. Also the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington DC. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From owner-ietf-calendar@mail.imc.org Wed Sep 20 17:12: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 RAA08163 for ; Wed, 20 Sep 2000 17:12:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA07259 for ietf-calendar-bks; Wed, 20 Sep 2000 13:56:12 -0700 (PDT) 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 NAA07251 for ; Wed, 20 Sep 2000 13:56:11 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e8KKq8n28554 for ; Wed, 20 Sep 2000 13:52:08 -0700 (PDT) Received: from netscape.com ([192.18.125.2]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G17E9H00.CVK; Wed, 20 Sep 2000 13:58:29 -0700 Message-ID: <39C9245F.1C922FD6@netscape.com> Date: Wed, 20 Sep 2000 13:55:59 -0700 From: rans@netscape.com (Richard Shusterman) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.7 [en]C-AOLNSCP (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tkanazawa@corp.talkcity.com CC: ietf-calendar@imc.org Subject: Re: iCalendar 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: > Toran asked: > >Is there any software that uses iCalendar? > > There are several packages that implement iCalendar to one degree or > another. There is Lotus Organzier (5.x or 6.x). Sun has a Calendar > Server that supports it. Some versions of Outlook (Express too??) > support it. Lotus Notes will have it soon. Exchange is to get it > soon too. There is also Eric B's nifty libical package you can check > out. There are other vendors that also support iCalendar to various > degrees but in order to avoid overlooking some, Id hope they chime in > with "We support it in product X"... iPlanet Calendar Server also supports iCalendar. Check it out at: http://www.iplanet.com/products/infrastructure/messaging/ics/index.html Our current version is 2.1 but we are about to release 5.0 From owner-ietf-calendar@mail.imc.org Sun Sep 24 03:19: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 DAA02184 for ; Sun, 24 Sep 2000 03:19:38 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA27926 for ietf-calendar-bks; Sat, 23 Sep 2000 23:57:11 -0700 (PDT) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA27922 for ; Sat, 23 Sep 2000 23:57:09 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA28847 for ietf-calendar@imc.org; Sun, 24 Sep 2000 00:00:04 -0700 (PDT) Date: Sun, 24 Sep 2000 00:00:04 -0700 (PDT) From: Doug Royer Message-Id: <200009240700.AAA28847@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 Sep 25 01:33: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 BAA19029 for ; Mon, 25 Sep 2000 01:33:09 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA27374 for ietf-calendar-bks; Sun, 24 Sep 2000 22:12:24 -0700 (PDT) Received: from agony.busboom.org (24-25-200-10.san.rr.com [24.25.200.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA27370 for ; Sun, 24 Sep 2000 22:12:19 -0700 (PDT) From: eric@softwarestudio.org Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id WAA12406; Sun, 24 Sep 2000 22:15:23 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Sun, 24 Sep 2000 22:15:23 -0700 (PDT) X-Sender: eric@agony.busboom.org To: Bruce_Kahn@iris.com cc: ietf-calendar@imc.org Subject: Re: RFC 2445 Issue: ABNF doesn't currently allow registered extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 19 Sep 2000 Bruce_Kahn@iris.com wrote: > So, in a nutshell I think that the ABNF we used in malformed in that it > does not allow for easy extensions later on because we used the form > "name" "=" "list_of_values" in the ABNF instead of "name" "=" "valuelist" > & valuelist = "list_of_values" form. We should correct this when we > correct the other ABNF oversight... Bruce, I've added this to the issues list, #41. eric. From owner-ietf-calendar@mail.imc.org Wed Sep 27 16:41:32 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 QAA22198 for ; Wed, 27 Sep 2000 16:41:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA06985 for ietf-calendar-bks; Wed, 27 Sep 2000 13:16:26 -0700 (PDT) Received: from agony.busboom.org (24-25-200-10.san.rr.com [24.25.200.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06981 for ; Wed, 27 Sep 2000 13:16:25 -0700 (PDT) From: eric@softwarestudio.org Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id NAA00815 for ; Wed, 27 Sep 2000 13:19:49 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Wed, 27 Sep 2000 13:19:49 -0700 (PDT) X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Proposed Text for RFC2445 Issue #3 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: This is a proposal to address RFC2445 Issue number 3, from the issues list online at: http://www.softwarestudio.org/iCal/2445Issues.html Issue #3 is: DATE DTSTART and RECURRENCE-ID http://www.imc.org/ietf-calendar/mail-archive/msg03549.html This proposal will be open for discussion for two weeks, so please send any comments soon. eric. ---------------------------------------------------------------------------- In section 4.8.4.4, Recurrence ID, change: If the value of the "DTSTART" property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. to: If the value of the "DTSTART" property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. The "DTSTART" property MUST NOT have a DATE type value if any recurrence rule for the the component has a BYHOUR, BYMINUTE or BYSECOND BYxxx rule part. From owner-ietf-calendar@mail.imc.org Wed Sep 27 16: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 QAA22230 for ; Wed, 27 Sep 2000 16:43:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA06760 for ietf-calendar-bks; Wed, 27 Sep 2000 13:11:55 -0700 (PDT) Received: from agony.busboom.org (24-25-200-10.san.rr.com [24.25.200.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06753 for ; Wed, 27 Sep 2000 13:11:54 -0700 (PDT) From: eric@softwarestudio.org Received: from localhost (eric@localhost) by agony.busboom.org (8.9.3/8.9.3) with ESMTP id NAA00811 for ; Wed, 27 Sep 2000 13:15:13 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Wed, 27 Sep 2000 13:15:13 -0700 (PDT) X-Sender: eric@agony.busboom.org To: ietf-calendar@imc.org Subject: Proposed Text for RFC2445 Issue #1 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: This is a proposal to address RFC2445 Issue number 1, from the issues list online at: http://www.softwarestudio.org/iCal/2445Issues.html Issue #1 is: FMTYPE can't hold MIME type; no / allowed http://www.imc.org/ietf-calendar/mail-archive/msg02989.html This proposal will be open for discussion for two weeks, so please send any comments soon. eric. ----------------------------------------------------------------------------- There are two parts to the proposal: 1) Add a new parameter type, FILE-NAME 2) Modify the ATTACH property to use the new parameter 1) Add a new parameter type, FILE-NAME ---------------------- Parameter Name: FILE-NAME Purpose: To specify the filename of a referenced object Format Definition: The property parameter is defined by the following notation: filenameparam = "FILE-NAME" "=" param-value Description: This parameter can be specified on properties that are used to reference an object. The parameter specifies the file name of the referenced object. Example: ATTACH;FILE-NAME=agenda.doc;FMTTYPE=application/binary :ftp://domain.com/pub/docs/agenda.doc ---------------------- 2) Modify the ATTACH property to use the new parameter --------------------- attparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" fmttypeparam) / (";" filenameparam )/ ; the following is optional, ; and MAY occur more than once (";" xparam) -------------------- From owner-ietf-calendar@mail.imc.org Thu Sep 28 11:44:59 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 LAA24164 for ; Thu, 28 Sep 2000 11:44:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA12022 for ietf-calendar-bks; Thu, 28 Sep 2000 08:14:34 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12012 for ; Thu, 28 Sep 2000 08:14:32 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id LAA26096 for ; Thu, 28 Sep 2000 11:20:40 -0400 Message-ID: <39D33F2A.3DA0A5FF@ecal.com> Date: Thu, 28 Sep 2000 08:52:58 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Proposed Text for RFC2445 Issue #1 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@softwarestudio.org wrote: > FMTYPE can't hold MIME type; no / allowed > http://www.imc.org/ietf-calendar/mail-archive/msg02989.html > There are two parts to the proposal: > > 1) Add a new parameter type, FILE-NAME How does this solve the problem with FMTTYPE? -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |There are footprints on the moon. No feet, just| |francis@ecal.com|footprints. | \================================================================/