From owner-ietf-calendar@mail.imc.org Mon May 1 11:58:44 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 LAA29032 for ; Mon, 1 May 2000 11:58:43 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA07150 for ietf-calendar-bks; Mon, 1 May 2000 08:34:12 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07146 for ; Mon, 1 May 2000 08:34:10 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id LAA29220; Mon, 1 May 2000 11:39:24 -0400 Message-ID: <390DA52B.DA699204@ecal.com> Date: Mon, 01 May 2000 11:39:23 -0400 From: John Stracke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: calsch WG Subject: [Fwd: I-D ACTION:draft-stracke-calsch-ical-reviewer-00.txt] 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 I-D I wrote up in Adelaide about fixing the Method Reviewer process has finally come through (bit of a long story, and not an interesting one). This addresses the problems I pointed out in Oslo (no way to appeal decisions to accept, only decisions to reject; no explicit power for the ADs to remove an MR; only the original proposer can appeal decisions to reject). The sense of the room at the time was that they were pretty theoretical problems (agreed), but worth fixing. What does the WG think now? Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Fixing the iCalendar Registration Process > Author(s) : J. Stracke > Filename : draft-stracke-calsch-ical-reviewer-00.txt > Pages : 2 > Date : 28-Apr-00 > > This document discusses a problem with the [ICALENDAR] registration > process, which gives the Method Reviewer too much power, and proposes > a fix. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-stracke-calsch-ical-reviewer-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-stracke-calsch-ical-reviewer-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-stracke-calsch-ical-reviewer-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ----------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <20000428081336.I-D@ietf.org> -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Maybe only the solipsists are imaginary. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu May 4 14:39:05 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 OAA13655 for ; Thu, 4 May 2000 14:39:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13004 for ietf-calendar-bks; Thu, 4 May 2000 11:09:43 -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 LAA13000 for ; Thu, 4 May 2000 11:09:41 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id LAA02066; Thu, 4 May 2000 11:15:04 -0700 (PDT) Date: Thu, 4 May 2000 11:15:04 -0700 (PDT) From: Doug Royer Message-Id: <200005041815.LAA02066@royer.com> To: doug@royer.com Subject: Gone fishing Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If you don't hear from me in the next few weeks, I am taking some time off. It has been a couple of years since I have taken a long vacation and my body is demanding one. I'll work on the IANA-TIMEZONE, CALSCH, and IMPP when I get back. -Doug From owner-ietf-calendar@mail.imc.org Sun May 7 03:21:53 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 DAA02305 for ; Sun, 7 May 2000 03:21:52 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA17974 for ietf-calendar-bks; Sat, 6 May 2000 23:54:33 -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 XAA17969 for ; Sat, 6 May 2000 23:54:31 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA17859 for ietf-calendar@imc.org; Sun, 7 May 2000 00:00:03 -0700 (PDT) Date: Sun, 7 May 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200005070700.AAA17859@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 CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: 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 ? Y ------------------------------------------------------------------------------ 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 From owner-ietf-calendar@mail.imc.org Tue May 9 14:18: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 OAA26954 for ; Tue, 9 May 2000 14:18:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23836 for ietf-calendar-bks; Tue, 9 May 2000 10:48:22 -0700 (PDT) Received: from scooby.lineone.net ([194.75.152.224]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23285; Tue, 9 May 2000 10:36:53 -0700 (PDT) Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST) Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd> From: "Charlie Fletcher - www.ukdata.com" To: "Finance Director" Subject: Instant On-Line Credit Reports Date: Tue, 9 May 2000 16:34:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 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 Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies From owner-ietf-calendar@mail.imc.org Sun May 14 03:29:17 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 DAA03512 for ; Sun, 14 May 2000 03:29:16 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA21137 for ietf-calendar-bks; Sat, 13 May 2000 23:53:59 -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 XAA21133 for ; Sat, 13 May 2000 23:53:56 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA10828 for ietf-calendar@imc.org; Sun, 14 May 2000 00:00:03 -0700 (PDT) Date: Sun, 14 May 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200005140700.AAA10828@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 CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: 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 ? Y ------------------------------------------------------------------------------ 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 From owner-ietf-calendar@mail.imc.org Sun May 14 20: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 ESMTP id UAA12857 for ; Sun, 14 May 2000 20:54:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA15994 for ietf-calendar-bks; Sun, 14 May 2000 17:32:26 -0700 (PDT) Received: from agony.qualcomm.com (annex1-p2.qualcomm.com [129.46.85.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15989 for ; Sun, 14 May 2000 17:32:24 -0700 (PDT) Received: from localhost (eric@localhost) by agony.qualcomm.com (8.9.3/8.9.3) with ESMTP id RAA32627 for ; Sun, 14 May 2000 17:34:04 -0700 X-Authentication-Warning: agony.qualcomm.com: eric owned process doing -bs Date: Sun, 14 May 2000 17:34:04 -0700 (PDT) From: Eric Busboom X-Sender: eric@agony.qualcomm.com To: ietf-calendar@imc.org Subject: Should COMMAs be escaped in LOCATION? 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: RFC 2445 has the following example text for LOCATION, which takes a TEXT value: LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": Conference Room - F123, Bldg. 002 In this example, as well as examples in RFC 2446, the commas are unescaped. Is this correct? Section 4.3.11 specifies that commas in text values must be escaped. eric. From owner-ietf-calendar@mail.imc.org Mon May 15 13:17:46 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 NAA07366 for ; Mon, 15 May 2000 13:17:45 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA24800 for ietf-calendar-bks; Mon, 15 May 2000 09:50:23 -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 JAA24785 for ; Mon, 15 May 2000 09:50:01 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Should COMMAs be escaped in LOCATION? X-Mailer: Lotus Notes Build V60_05032000 May 03, 2000 Message-ID: Date: Mon, 15 May 2000 12:55:27 -0400 X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_05032000|May 03, 2000) at 05/15/2000 12:55:34 PM, Serialize by Notes Client on Bruce Kahn/Iris(Build V60_05032000|May 03, 2000) at 05/15/2000 12:55:34 PM, Serialize complete at 05/15/2000 12:55:34 PM, Itemize by Notes Client on Bruce Kahn/Iris(Build V60_05032000|May 03, 2000) at 05/15/2000 12:55:35 PM, S/MIME Sign complete at 05/15/2000 12:55:35 PM, Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 05/15/2000 12:56:47 PM, Serialize complete at 05/15/2000 12:56:47 PM MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z01886_boundary_sign Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an S/MIME signed message. ---------z01886_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 005CFA6E852568E0_=" This is a multipart message in MIME format. --=_alternative 005CFA6E852568E0_= Content-Type: text/plain; charset="us-ascii" Eric asked: >RFC 2445 has the following example text for LOCATION, which takes a TEXT >value: > > LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": > Conference Room - F123, Bldg. 002 > >In this example, as well as examples in RFC 2446, the commas are >unescaped. Is this correct? That depends on if LOCATION is allowed to be multivalued or not. If it were, then it would be legit. However according to 2445 it is not so the comma must be escapified. >Section 4.3.11 specifies that commas in text >values must be escaped. Only if they are NOT the delimiter of multiple values as in, say, CLASS. So the crux of the problem boils down to: Does the property support multiple values or not? If not, you can "be forgiving" and treat it as an oversight or you can "be strict" and use just part of the parsed property value or toss it entirely. Frank/RFC 244x Update Monitor: The examples need another pass to fix these mistakes since LOTS of programmers code to examples instead of to the text/BNF!! 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 005CFA6E852568E0_= Content-Type: text/html; charset="us-ascii"
Eric asked:
>RFC 2445 has the following example text for LOCATION, which takes a TEXT
>value:
>
> LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
>      Conference Room - F123, Bldg. 002
>
>In this example, as well as examples in RFC 2446, the commas are
>unescaped. Is this correct?

That depends on if LOCATION is allowed to be multivalued or not.  If it were, then it would be legit.  However according to 2445 it is not so the comma must be escapified.

>Section 4.3.11 specifies that commas in text
>values must be escaped.

Only if they are NOT the delimiter of multiple values as in, say, CLASS.  So the crux of the problem boils down to: Does the property support multiple values or not?  If not, you can "be forgiving" and treat it as an oversight or you can "be strict" and use just part of the parsed property value or toss it entirely.

Frank/RFC 244x Update Monitor: The examples need another pass to fix these mistakes since LOTS of programmers code to examples instead of to the text/BNF!!

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 005CFA6E852568E0_=-- ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5 yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34 GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5 jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p 8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34 GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxNTE2NTUzNFowIwYJKoZIhvcNAQkEMRYEFD+NkQE+cSIU qr6YGfYULh7peqAvMA0GCSqGSIb3DQEBAQUABEAA/YXdhp1bYP3yfjZzs0Uj0ic6oD8ectudUdCb rzks3JZ6N4cWLVJ8H5SBbkROtiMxrehpFY32WvcFvqpWQ/dB ---------z01886_boundary_sign-- From owner-ietf-calendar@mail.imc.org Mon May 15 13:24:12 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 NAA07403 for ; Mon, 15 May 2000 13:24:11 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA24915 for ietf-calendar-bks; Mon, 15 May 2000 09:56:46 -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 JAA24908 for ; Mon, 15 May 2000 09:56:37 -0700 (PDT) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Should COMMAs be escaped in LOCATION? X-Mailer: Lotus Notes Build V60_05032000 May 03, 2000 Message-ID: Date: Mon, 15 May 2000 13:02:23 -0400 X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_05032000|May 03, 2000) at 05/15/2000 01:02:30 PM, Serialize by Notes Client on Bruce Kahn/Iris(Build V60_05032000|May 03, 2000) at 05/15/2000 01:02:30 PM, Serialize complete at 05/15/2000 01:02:30 PM, Itemize by Notes Client on Bruce Kahn/Iris(Build V60_05032000|May 03, 2000) at 05/15/2000 01:02:30 PM, S/MIME Sign complete at 05/15/2000 01:02:30 PM, Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 05/15/2000 01:03:10 PM, Serialize complete at 05/15/2000 01:03:11 PM, Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 05/15/2000 01:03:11 PM MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z01886_boundary_sign Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an S/MIME signed message. ---------z01886_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 005D86F6852568E0_=" This is a multipart message in MIME format. --=_alternative 005D86F6852568E0_= Content-Type: text/plain; charset="us-ascii" One additional footnote to Erics question: >Is this correct? If you are parsing vCalendar (remember that VERSION:1.0 spec??) then the values are "strings" (Shame on you vCalendar authors!!) and as such, if you are parsing a vCalendar LOCATION then the example is technically "correct" since the string is only terminated by the CRLF followed by a non-LWSP character. Escapement of the comma is NOT required or of any meaning since the data was loosely typed (as opposed to the strong data typing of iCalendar). So, for vCalendar the example IS correct. For iCalendar, see previous reply. I mentioned vCalendar since there are some sites that currently use it (ie: Musi-cal) and I found at least a dozen projects that used (or still use) vCalendar as the data format so you should be somewhat sensitive to its presence. 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 005D86F6852568E0_= Content-Type: text/html; charset="us-ascii"
One additional footnote to Erics question:

>Is this correct?

If you are parsing vCalendar (remember that VERSION:1.0 spec??) then the values are "strings" (Shame on you vCalendar authors!!) and as such, if you are parsing a vCalendar LOCATION then the example is technically "correct" since the string is only terminated by the CRLF followed by a non-LWSP character.  Escapement of the comma is NOT required or of any meaning since the data was loosely typed (as opposed to the strong data typing of iCalendar).

So, for vCalendar the example IS correct.  For iCalendar, see previous reply.

  I mentioned vCalendar since there are some sites that currently use it (ie: Musi-cal) and I found at least a dozen projects that used (or still use) vCalendar as the data format so you should be somewhat sensitive to its presence.

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 005D86F6852568E0_=-- ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5 yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34 GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5 jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p 8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34 GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDUxNTE3MDIzMFowIwYJKoZIhvcNAQkEMRYEFGELU0lMKwa2 lH5GFgcwi/6y40YqMA0GCSqGSIb3DQEBAQUABECQvBxAjuDfBhUFMMnvwvH/cvl4/Tyn7LdN/SxZ TuPYrmdXQ86zGb6vPwdQAxWtpBeXeN0AxFYG6jrIQ2sXNwJ2 ---------z01886_boundary_sign-- From owner-ietf-calendar@mail.imc.org Fri May 19 14:30:32 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 OAA09229 for ; Fri, 19 May 2000 14:30:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA16127 for ietf-calendar-bks; Fri, 19 May 2000 11:01:12 -0700 (PDT) Received: from klaymen.rim.net (mail.rim.net [206.51.26.155]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16122 for ; Fri, 19 May 2000 11:01:10 -0700 (PDT) Received: from SMTP (navieg1.rim.net [192.17.64.254]) by klaymen.rim.net (8.9.3/8.9.1) with SMTP id OAA16210 for ; Fri, 19 May 2000 14:08:29 -0400 Received: from ice.rim.net ([10.1.3.11]) by 192.17.64.254 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 19 May 2000 18:07:40 0000 (GMT) Received: by ice.rim.net with Internet Mail Service (5.5.2650.21) id ; Fri, 19 May 2000 14:07:39 -0400 Message-ID: From: Antony Davies To: "'ietf-calendar@imc.org'" Subject: question about CR's Date: Fri, 19 May 2000 14:07:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: How do I encode CR's in a mime message so that CR LF pairs are not transformed by sendmail into just LF's. This is happending in text/calendar attachments. I must have missed something obvious in RFC822 TIA, ------------------------------------- Antony Davies, Software, Research In Motion adavies@rim.net From owner-ietf-calendar@mail.imc.org Sun May 21 03:24: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 DAA02857 for ; Sun, 21 May 2000 03:24:41 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA05364 for ietf-calendar-bks; Sat, 20 May 2000 23:53:23 -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 XAA05357 for ; Sat, 20 May 2000 23:53:21 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA17366 for ietf-calendar@imc.org; Sun, 21 May 2000 00:00:03 -0700 (PDT) Date: Sun, 21 May 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200005210700.AAA17366@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 CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: 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 ? Y ------------------------------------------------------------------------------ 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 From owner-ietf-calendar@mail.imc.org Sun May 21 14:01:17 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 OAA09281 for ; Sun, 21 May 2000 14:01:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA01104 for ietf-calendar-bks; Sun, 21 May 2000 10:43:02 -0700 (PDT) Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01099 for ; Sun, 21 May 2000 10:43:00 -0700 (PDT) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.10.1/2000040900) with ESMTP id TAA05476 for ; Sun, 21 May 2000 19:49:50 +0200 (CEST) Received: from grizzly.ps.uni-sb.de (grizzly.ps.uni-sb.de [134.96.186.68]) by cs.uni-sb.de (8.10.1/2000040900) with ESMTP id TAA21229 for ; Sun, 21 May 2000 19:49:54 +0200 (CEST) Received: from ps.uni-sb.de (IDENT:bodirsky@godzilla.ps.uni-sb.de [134.96.186.124]) by grizzly.ps.uni-sb.de (8.9.1a/8.9.1) with ESMTP id TAA02517 for ; Sun, 21 May 2000 19:49:53 +0200 Message-ID: <392821C1.5D0C4BA7@ps.uni-sb.de> Date: Sun, 21 May 2000 19:49:53 +0200 From: Manuel Bodirsky Organization: Programming Systems Lab, DFKI Saarbruecken X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1smp i686) X-Accept-Language: de, ru, en MIME-Version: 1.0 To: calendar Subject: Simple Constraints between Events? 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 Hello, perhaps we want to implement parts of the iCalendar+CAP-Protokoll for our application, but we've not found out how to implement certain things: What we need is a kind of constraint between different events/todos, like 'this event has to take place before that event'. To be more precise: Two CU's, 'A' and 'B', want to fix two dates, 'I' and 'II'. 'A' knows, that 'I' must take place before 'II'. It's now important that he is able to let 'B' know that there is this constraint, because 'B' might have to do some sophisticated sceduling to fullfill this constraint. What we don't want to do, is to let 'B' ask for a date, and 'A' simply rejects, if it violates the constraint. This would lead to a combinatorical explosion when 'B' has to schedule a lot of constrained todos at several resources. Do we have to extend the protocol? Is it possible to extend the protocol? Thank you very much, Manuel Bodirsky From owner-ietf-calendar@mail.imc.org Sun May 21 22:03: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 WAA12678 for ; Sun, 21 May 2000 22:03:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA19125 for ietf-calendar-bks; Sun, 21 May 2000 18:43:45 -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 SAA19116 for ; Sun, 21 May 2000 18:43:44 -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 VAA05236; Sun, 21 May 2000 21:49:59 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id VAA25023; Sun, 21 May 2000 21:50:10 -0400 (EDT) To: Manuel Bodirsky Cc: ietf-calendar@imc.org Subject: Re: Simple Constraints between Events? X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Sun, 21 May 2000 21:44:20 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 05/21/2000 09:44:17 PM, Serialize complete at 05/21/2000 09:44:17 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000A0B8D852568E7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000A0B8D852568E7_= Content-Type: text/plain; charset="us-ascii" Manuel: The RELATED-TO property is intended to show relationships between calendar events. For example: BEGIN:VCALENDAR VERSION:2.0 blah, blah.. BEGIN:VEVENT UID:123 RELATED-TO;RELTYPE=CHILD:321 DTSTART:20000521T133000Z DTEND:20000521T143000Z blah, blah.. END:VEVENT BEGIN:VEVENT UID:321 RELATED-TO;RELTYPE=PARENT:123 DTSTART:20000521T200000Z DTEND:20000521T210000Z blah, blah.. END:VEVENT can be used to show that the event 123 is the parent of event 321 and event 321 is the child of event 123. According to RFC2445, "Change sto a calendar component referenced by this property can have an implicit impact on the related calendar component. For example, if a group event changes its start or end date or time, the the related, dependent events will need to have their start and end dates changed in a corresponding way. So, I think that this is what you want. However, you may have more relationship implications that you want to convey than is codified in RFC2445 within this property. -- Frank --=_alternative 000A0B8D852568E7_= Content-Type: text/html; charset="us-ascii"
Manuel:

The RELATED-TO property is intended to show relationships between calendar events. For example:

BEGIN:VCALENDAR
VERSION:2.0
blah, blah..
BEGIN:VEVENT
UID:123
RELATED-TO;RELTYPE=CHILD:321
DTSTART:20000521T133000Z
DTEND:20000521T143000Z
blah, blah..
END:VEVENT
BEGIN:VEVENT
UID:321
RELATED-TO;RELTYPE=PARENT:123
DTSTART:20000521T200000Z
DTEND:20000521T210000Z
blah, blah..
END:VEVENT

can be used to show that the event 123 is the parent of event 321 and event 321 is the child of event 123.

According to RFC2445, "Change sto a calendar component referenced by this property can have an implicit impact on the related calendar component. For example, if a group event changes its start or end date or time, the the related, dependent events will need to have their start and end dates changed in a corresponding way.

So, I think that this is what you want.

However, you may have more relationship implications that you want to convey than is codified in RFC2445 within this property.

-- Frank --=_alternative 000A0B8D852568E7_=-- From owner-ietf-calendar@mail.imc.org Sun May 21 23:06:39 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 XAA13911 for ; Sun, 21 May 2000 23:06:38 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA27877 for ietf-calendar-bks; Sun, 21 May 2000 19:40:43 -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 TAA27864 for ; Sun, 21 May 2000 19:40:41 -0700 (PDT) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: CalConnect "Spring" results X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Sun, 21 May 2000 22:47:09 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 05/21/2000 10:47:21 PM, Serialize complete at 05/21/2000 10:47:21 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000F42CF852568E7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000F42CF852568E7_= Content-Type: text/plain; charset="us-ascii" On April 11 and 12, CalConnect Spring was held in Boston. It was graciously hosted by MIT and chaired by Bob Mahoney. The following companies and representatives were in attendance: Tom Ransdell, Lotus, Dan Gurney, Iris/Lotus, John Sun, iPlanet, Ki Wong, iPlanet, Katia Hage, Microsoft, Colin DuPlantis, Critical Path, Bob Mahoney, MIT, and finally, Paul Hill, MIT. Pat Egen sat at home with a broken leg, and assisted (poorly) from the sidelines. The following products and versions were tested: EventCenter Version 3.0 (Critical Path) Outlook 2000 and Outlook Express 5.0 (Microsoft) iPlanet - internal unreleased alpha version iCS 5.0, server and client (Netscape) Organizer (Lotus) First off, thanks to everyone for their efforts. There was consensus that all participants have a lot of work to do, and that another testing event should be held in the fall. A west coast location was suggested, although some interest was also expressed for New Orleans or San Antonio. All participants felt that great progress would be made in the coming months. Little interoperability has occurred so far. Repeating events and canceled events seem to be causing problems. Parsers are working OK but the actual generation of the data objects is very inconsistent. Problems found with recurrence included the following: - one vendor always generates and expects rrules, but cannot handle rdates. - two vendors always generate rdates and cannot currently handle rrules. - one vendor handles rrules but cannot handle exceptions. There was a brief discussion about redesigning recurrence. Some useful alternatives were suggested but the developers also seemed to be willing to live with the current specification. They did feel that word-smithing would help. This will be brought back to the list in more detail for some review. The biggest complaints are currently with iMIP and the MIME handling. "iMIP under-constrains what may be emitted by a data source; this requires a client to handle every possible case" which is perceived as a heavy burden by the developers. Regarding MIME: "(multipart mixed vs. multipart alternative vs. text-alternative vs. attachments ...)" - the developers would be happier if there fewer options, or perhaps some stronger assertions in the draft. This too will be put on the list. There has been virtually no interoperability testing of alarms yet. There were some side issues relating to alarms, which will be brought back to the list. There has been virtually no testing of conformance with line lengths yet. A number of minor problems with blank spaces, terminating lines, and MIME boundaries were observed and are in the process of being fixed by the implementors. No tester has fully implemented Journals. One vendor has the support in the parser but no support in the front end, so they cannot be generated or displayed by the product. All of the implementors indicate that supporting Journals is intended and that no obstacles are seen, they are just lower on the priority list so far. There has been no testing of signed or encrypted objects. This should be a major goal of the next testing event. Some progress is better than no progress. Look for additional activity on the list as we post some of the items referenced above. CalConnect Fall will be announced later in the year. Respectfully submitted, Pat Egen --=_alternative 000F42CF852568E7_= Content-Type: text/html; charset="us-ascii"
On April 11 and 12, CalConnect Spring was held in Boston. It was graciously hosted by MIT and chaired by Bob Mahoney.  The following companies and representatives were in attendance:

Tom Ransdell, Lotus, Dan Gurney, Iris/Lotus, John Sun, iPlanet, Ki Wong, iPlanet,
Katia Hage, Microsoft, Colin DuPlantis, Critical Path, Bob Mahoney, MIT, and finally, Paul Hill, MIT. Pat Egen sat at home with a broken leg, and assisted (poorly) from the sidelines.                      
The following products and versions were tested:

EventCenter Version 3.0 (Critical Path)
Outlook 2000 and Outlook Express 5.0 (Microsoft)
iPlanet - internal unreleased alpha version iCS 5.0, server and client (Netscape)
Organizer (Lotus)
First off, thanks to everyone for their efforts.  There was consensus that all participants have a lot of work to do, and that another testing event should be held in the fall.  A west coast location was suggested, although some interest was also expressed for New Orleans or San Antonio.  All participants felt that great progress would be made in the coming months.

Little interoperability has occurred so far. Repeating events and canceled events seem to be causing problems. Parsers are working OK but the actual generation of the data objects is very inconsistent.

Problems found with recurrence included the following:
- one vendor always generates and expects rrules, but cannot handle rdates.
- two vendors always generate rdates and cannot currently handle rrules.
- one vendor handles rrules but cannot handle exceptions.

There was a brief discussion about redesigning recurrence. Some useful alternatives were suggested but the developers also seemed to be willing to live with the current specification. They did feel that word-smithing would help.  This will be brought back to the list in more detail for some review.

The biggest complaints are currently with iMIP and the MIME handling. "iMIP under-constrains what may be emitted by a data source; this requires a client to handle every possible case" which is perceived as a heavy burden by the developers.

Regarding MIME: "(multipart mixed vs. multipart alternative vs. text-alternative vs.
attachments ...)" - the developers would be happier if there fewer options, or perhaps some stronger assertions in the draft.  This too will be put on the list.

There has been virtually no interoperability testing of alarms yet. There were some side issues relating to alarms, which will be brought back to the list.

There has been virtually no testing of conformance with line lengths yet.

A number of minor problems with blank spaces, terminating lines, and MIME boundaries were observed and are in the process of being fixed by the implementors.

No tester has fully implemented Journals. One vendor has the support in the parser but no support in the front end, so they cannot be generated or displayed by the product. All of the implementors indicate that supporting Journals is intended and that no obstacles
are seen, they are just lower on the priority list so far.

There has been no testing of signed or encrypted objects. This should be a major goal of the next testing event.

Some progress is better than no progress.  Look for additional activity on the list as we post some of the items referenced above.  CalConnect Fall will be announced later in the year.

Respectfully submitted,

Pat Egen --=_alternative 000F42CF852568E7_=-- From owner-ietf-calendar@mail.imc.org Mon May 22 06:54:22 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 GAA28963 for ; Mon, 22 May 2000 06:54:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA16657 for ietf-calendar-bks; Mon, 22 May 2000 03:24:13 -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 DAA16653 for ; Mon, 22 May 2000 03:24:11 -0700 (PDT) Received: from gregs (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id 22AA1B34C4; Mon, 22 May 2000 12:30:56 +0200 (CEST) From: "Greg FitzPatrick" To: "Manuel Bodirsky" , "calendar" Subject: SV: Simple Constraints between Events? Date: Mon, 22 May 2000 12:30:29 +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.2314.1300 In-Reply-To: <392821C1.5D0C4BA7@ps.uni-sb.de> Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Manuel Bodirsky wrote: What we need is a kind of constraint between different events/todos, like 'this event has to take place before that event'. frank answers that the RELATED-TO property might fit the bill - but he reserves himself. In SKiCal we make clear that the RELATED-TO property is about the relationship between calendar objects describing events and not the relationship between the events themselves. Therefore we have extended 2445 with http://www.ietf.org/internet-drafts/draft-many-ical-ski-01.txt 3.1.5 Part of another event Property Name: PARTOF Purpose: This property specifies another event, of which the described event is part of. This does not imply an inheritance of properties from the named PARTOF-event but rather a relevance. Value Type: TEXT. (EUID for another SKiCal/iCalendar object.) Property Parameters: Non-standard property parameters can be specified on this property. It is RECOMMENDED that a Common Name parameter (cnparam) be specified on this property. Conformance: This property CAN be specified within a "VEVENT" calendar component. Description: This property allows for the publisher of an event to indicate that the event is part of another event, such as a festival or a package of tourist attractions. This property resembles the RELATED-TO;RELTYPE=parent property of RFC-2445, but that property defines a relationship between calendar objects and not between events themselves. Format Definition: The property is defined by the following notation: partof = "PARTOF" partofparam ":" text CRLF partofparam = ; the following is optional, ; but MUST NOT occur more than once (";" languageparam ) / (";" cnparam ) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: PARTOF;CN=Vattenfestivalen:<19990401T080045Z-F192713@stoinfo.se> PARTOF;CN=2004 Winter Olympics:<19991202@olympic.org> PARTOF: we also describe the property relative times, which will receive a formal description in the next version of SKiCal. 3.2.4 Relative Times Relative Time properties are times dependent upon the times for other events. They cannot exist independently. Example: A bus departs from the ferry terminal 20 minutes after the ferryboat arrives, whenever that is. Greg From owner-ietf-calendar@mail.imc.org Mon May 22 11:51: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 LAA04065 for ; Mon, 22 May 2000 11:51:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24060 for ietf-calendar-bks; Mon, 22 May 2000 08:21:15 -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 IAA24056; Mon, 22 May 2000 08:21: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 LAA18120; Mon, 22 May 2000 11:27:25 -0400 (EDT) Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA25027; Mon, 22 May 2000 11:27:29 -0400 (EDT) To: "Greg FitzPatrick" Cc: bodirsky@ps.uni-sb.de, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: SV: Simple Constraints between Events? X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Mon, 22 May 2000 11:21:31 -0400 X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 05/22/2000 11:21:37 AM, Serialize complete at 05/22/2000 11:21:37 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0054DD0D852568E7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054DD0D852568E7_= Content-Type: text/plain; charset="us-ascii" Greg FitzPatrick wrote, in part: >This property resembles the >RELATED-TO;RELTYPE=parent property of RFC-2445, but that property >defines a relationship between calendar objects and not between >events themselves. RELATED-TO specifies a relationship between calendar components (i.e., VEVENT, VTODO, VJOURNAL). Isn't this the same semantics as this new SkiCal property? I am confused. -- Frank --=_alternative 0054DD0D852568E7_= Content-Type: text/html; charset="us-ascii"
Greg FitzPatrick wrote, in part:

>This property resembles the
>RELATED-TO;RELTYPE=parent property of RFC-2445, but that property
>defines a relationship between calendar objects and not between
>events themselves.

RELATED-TO specifies a relationship between calendar components (i.e., VEVENT, VTODO, VJOURNAL). Isn't this the same semantics as this new SkiCal property? I am confused.

-- Frank

--=_alternative 0054DD0D852568E7_=-- From owner-ietf-calendar@mail.imc.org Sun May 28 03:33:08 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 DAA04124 for ; Sun, 28 May 2000 03:33:07 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA17567 for ietf-calendar-bks; Sat, 27 May 2000 23:52:47 -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 XAA17563 for ; Sat, 27 May 2000 23:52:45 -0700 (PDT) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA23906 for ietf-calendar@imc.org; Sun, 28 May 2000 00:00:03 -0700 (PDT) Date: Sun, 28 May 2000 00:00:03 -0700 (PDT) From: Doug Royer Message-Id: <200005280700.AAA23906@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 CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: 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 ? Y ------------------------------------------------------------------------------ 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