From owner-ietf-calendar@mail.imc.org  Sun Oct  1 00:25: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 AAA06949
	for <calsch-archive@odin.ietf.org>; Sun, 1 Oct 2000 00:25:06 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id VAA22631
	for ietf-calendar-bks; Sat, 30 Sep 2000 21:02:00 -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 VAA22626
	for <ietf-calendar@imc.org>; Sat, 30 Sep 2000 21:01:58 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id VAA05426;
	Sat, 30 Sep 2000 21:05:34 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Sat, 30 Sep 2000 21:05:34 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
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: <Pine.LNX.4.21.0009242214400.1388-100000@agony.busboom.org>
Message-ID: <Pine.LNX.4.21.0009302105230.1072-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

<On Sun, 24 Sep 2000 eric@softwarestudio.org wrote:

> 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  Sun Oct  1 03:19:54 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 DAA02163
	for <calsch-archive@odin.ietf.org>; Sun, 1 Oct 2000 03:19:53 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA26229
	for ietf-calendar-bks; Sat, 30 Sep 2000 23:56:35 -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 XAA26225
	for <ietf-calendar@imc.org>; Sat, 30 Sep 2000 23:56:33 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA08482
	for ietf-calendar@imc.org; Sun, 1 Oct 2000 00:00:03 -0700 (PDT)
Date: Sun, 1 Oct 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200010010700.AAA08482@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: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=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?					<variable>
      Can the server decide not to do this?	Y
  
 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 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 Oct  2 11:40: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 LAA09727
	for <calsch-archive@odin.ietf.org>; Mon, 2 Oct 2000 11:40:07 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16985
	for ietf-calendar-bks; Mon, 2 Oct 2000 08:19:40 -0700 (PDT)
Received: from localhost.localdomain (thibault.org [207.8.144.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16981
	for <ietf-calendar@imc.org>; Mon, 2 Oct 2000 08:19:38 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id LAA10344
	for <ietf-calendar@imc.org>; Mon, 2 Oct 2000 11:25:44 -0400
Message-ID: <39D8A8F7.CC98A4EF@ecal.com>
Date: Mon, 02 Oct 2000 11:25:43 -0400
From: John Stracke <francis@ecal.com>
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: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
References: <Pine.LNX.4.21.0009302108231.1072-100000@agony.busboom.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

eric@softwarestudio.org wrote:

> Well, it doesn't, since there isn't a problem with FMTYPE. The name of the
> issue is an error. ( I got the wrong Subject: line with the message. I
> should have declared #1 a duplicate of #8, and used the Subject from #8. )

Um.  <dig, dig> OK, well, we had one person post suggesting a filename, last
November, with no explanation why, and it doesn't look like anybody ever
commented; looks like we don't have consensus in favor of this one.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |In the long run, there is no middle ground   |
|francis@ecal.com|between justice and genocide.                |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Mon Oct  2 15:33: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 PAA13049
	for <calsch-archive@odin.ietf.org>; Mon, 2 Oct 2000 15:33:11 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA22103
	for ietf-calendar-bks; Mon, 2 Oct 2000 12:14:29 -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 MAA22095
	for <ietf-calendar@imc.org>; Mon, 2 Oct 2000 12:14:25 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id MAA22737;
	Mon, 2 Oct 2000 12:17:57 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Mon, 2 Oct 2000 12:17:57 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: John Stracke <francis@ecal.com>
cc: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
In-Reply-To: <39D8A8F7.CC98A4EF@ecal.com>
Message-ID: <Pine.LNX.4.21.0010021211040.1072-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

On Mon, 2 Oct 2000, John Stracke wrote:

> Um.  <dig, dig> OK, well, we had one person post suggesting a filename, last
> November, with no explanation why, and it doesn't look like anybody ever
> commented; looks like we don't have consensus in favor of this one.

Right, but the issue is on the list because there were no comments. If the
request had generated comments and had been rejected, I would have ignored
it. The whole purpose for making a formal proposal for the issue is to
encourage the discussion that did not happen the first time around.

So, do you agree or disgree with the proposal?

eric. 



From owner-ietf-calendar@mail.imc.org  Mon Oct  2 15:43:25 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13181
	for <calsch-archive@odin.ietf.org>; Mon, 2 Oct 2000 15:43:20 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA22346
	for ietf-calendar-bks; Mon, 2 Oct 2000 12:21:10 -0700 (PDT)
Received: from localhost.localdomain (thibault.org [207.8.144.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22342
	for <ietf-calendar@imc.org>; Mon, 2 Oct 2000 12:21:08 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id PAA11322
	for <ietf-calendar@imc.org>; Mon, 2 Oct 2000 15:27:15 -0400
Message-ID: <39D8E192.54CEFE83@ecal.com>
Date: Mon, 02 Oct 2000 15:27:15 -0400
From: John Stracke <francis@ecal.com>
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: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
References: <Pine.LNX.4.21.0010021211040.1072-100000@agony.busboom.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Eric Busboom wrote:

> So, do you agree or disgree with the proposal?

I disagree, but not strongly.  I oppose it because I don't see any reason to do
it; if someone shows me a good use case, I might change my mind.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |This is not a self-referential .signature.   |
|francis@ecal.com|                                             |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Mon Oct  2 20:14:21 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 UAA16028
	for <calsch-archive@odin.ietf.org>; Mon, 2 Oct 2000 20:14:21 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id QAA28433
	for ietf-calendar-bks; Mon, 2 Oct 2000 16:52:35 -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 QAA28429
	for <ietf-calendar@imc.org>; Mon, 2 Oct 2000 16:52:33 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id QAA23126;
	Mon, 2 Oct 2000 16:56:21 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Mon, 2 Oct 2000 16:56:21 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: John Stracke <francis@ecal.com>
cc: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
In-Reply-To: <39D8E192.54CEFE83@ecal.com>
Message-ID: <Pine.LNX.4.21.0010021623520.1072-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

On Mon, 2 Oct 2000, John Stracke wrote:

> Eric Busboom wrote:
> 
> > So, do you agree or disgree with the proposal?
> 
> I disagree, but not strongly.  I oppose it because I don't see any reason to do
> it; if someone shows me a good use case, I might change my mind.
> 

I think we should add the FILE-NAME parameter to ATTACH. 

Without this parameter, an attendee will have a different name for the
attached file than the organizer on the attendee's local store. This isn't
a problem while the attendee accesses the attached file though the CUA,
but attachements tend to have a longer lifetime than the message they are
attached to.

If you send a document to me in a meeting proposal, I am likely to want to
keep the document for later reference, even after the CS has archived the
meeting proposal and it is no longer available to the CUA. ( At my last
company, no events older than 6 months were accessible. ) That means the
document will be on my hard drive, seperated from the CUA, so it is going
to need a sensible name. If it does not have the same name as the the
Organizer gave it originally, then it will be impossible for the organizer
and the attendees to refer to the document out of band.

Adding a filename parameter to ATTACH would allow the document to keep the
same name among the organizer and all attendees. 

eric. 




From owner-ietf-calendar@mail.imc.org  Tue Oct  3 10:35:17 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 KAA12657
	for <calsch-archive@odin.ietf.org>; Tue, 3 Oct 2000 10:35:16 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16014
	for ietf-calendar-bks; Tue, 3 Oct 2000 06:58:12 -0700 (PDT)
Received: from localhost.localdomain ([216.52.68.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16010
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 06:58:10 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA20377
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 10:04:51 -0400
Message-ID: <39D9E782.4CCBE0CD@ecal.com>
Date: Tue, 03 Oct 2000 10:04:50 -0400
From: John Stracke <francis@ecal.com>
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: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
References: <Pine.LNX.4.21.0010021623520.1072-100000@agony.busboom.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Eric Busboom wrote:

> I think we should add the FILE-NAME parameter to ATTACH.
>
> Without this parameter, an attendee will have a different name for the
> attached file than the organizer on the attendee's local store.

First, note that this is not a completely solvable problem.  If the attendee and the
organizer use different filesystems, the organizer may use a filename which the
attendee's system does not allow.

That being said, let's analyze the problem.  ATTACH: references fall into three
categories:

   * A "fetch a file" URL, which includes a filename.  (If it's an http: URL, the
     server can also use the Content-Disposition: header.)
   * A cid: URL, which references another body part in the MIME message, in which
     case, again, the sender can use Content-Disposition:.
   * Inline binary content.  This is the only case in which the FILE-NAME param
     might be needed.

If we introduce FILE-NAME, then the first two cases become problematic: what if the
FILE-NAME and the filename derived from the URL don't match? Different
implementations will make different choices, and you'll be right back where you
started.

Since the first two cases are probably preferable (they use existing general-purpose
infrastructure instead of something invented just for iCalendar), I'd choose not
hurting them over helping the inline binary form.

> company, no events older than 6 months were accessible. ) That means the
> document will be on my hard drive, seperated from the CUA, so it is going
> to need a sensible name.

Most documents have titles.  Most non-technical users probably like titles better
than filenames.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |I'm a .sig virus...and, boy, am I tired!     |
|francis@ecal.com|                                             |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Tue Oct  3 12:52:57 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17180
	for <calsch-archive@odin.ietf.org>; Tue, 3 Oct 2000 12:52:57 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA23368
	for ietf-calendar-bks; Tue, 3 Oct 2000 09:21:46 -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 JAA23362
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 09:21:41 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id JAA25403;
	Tue, 3 Oct 2000 09:25:32 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Tue, 3 Oct 2000 09:25:32 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: John Stracke <francis@ecal.com>
cc: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
In-Reply-To: <39D9E782.4CCBE0CD@ecal.com>
Message-ID: <Pine.LNX.4.21.0010030851170.1072-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

On Tue, 3 Oct 2000, John Stracke wrote:

John, you said you didn't feel strongly about this issue :).

> First, note that this is not a completely solvable problem.  If the attendee and the
> organizer use different filesystems, the organizer may use a filename which the
> attendee's system does not allow.

That's strictly true, but I don't know any filesystems that pervert
filenames so badly that they on longer contain any
information. "PROPOSA~.DOC" is still better than "X45GHHWD3.DAT"

>    * A "fetch a file" URL, which includes a filename.  (If it's an http: URL, the
>      server can also use the Content-Disposition: header.)

Sometimes the URL includes a filename, but it is becoming more common to
distribute URLs that point into a document management system (I've used
LiveLink) where the filename is either a node number or is deeply embedded
in the URL. 

Using Content-Disposition is a good way to do it, but only from the HTTP
Server's perspective. I think it just moves the responsibility for a
problem in the calendaring application to a system that is not controlled
by the calendaring spec. If you rely on Content-Disposition, sometimes you
will get it, and sometimes you won't. 

> If we introduce FILE-NAME, then the first two cases become problematic: what if the
> FILE-NAME and the filename derived from the URL don't match? Different
> implementations will make different choices, and you'll be right back where you
> started.

Clients will only make different choices if the specification does not
indicate which choice to make. 

If we add the FILE-NAME parameter, and specify how to resolve conflicts
between it, the Content-Disposition filename part, and the URL filename,
there should be no problems. To this end, I propose these rules: 

	1) Use the value of the FILE-NAME parameter
	2) If no FILE-NAME, use the value from Content-Disposition
	3) If no Content-Disposition, use the filename part of the URL
	4) If no file-name in URL ( it is a cgi or query string ) make
	something up.

Would this solve some of your concerns?

At my last company, it was very common to attach documents to Email, and
Eudora would put them in an attachments directory. I spent a fair amount
of time looking through that directory for documents that I had received
many months before. For these searches, the file names on the documents
were critical, so I think this is an important issue. 

eric. 




From owner-ietf-calendar@mail.imc.org  Tue Oct  3 13:23:33 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 NAA18595
	for <calsch-archive@odin.ietf.org>; Tue, 3 Oct 2000 13:23:32 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24158
	for ietf-calendar-bks; Tue, 3 Oct 2000 09:58:04 -0700 (PDT)
Received: from localhost.localdomain ([216.52.68.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24154
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 09:58:02 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id NAA20894
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 13:04:44 -0400
Message-ID: <39DA11AC.2625FC19@ecal.com>
Date: Tue, 03 Oct 2000 13:04:44 -0400
From: John Stracke <francis@ecal.com>
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: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
References: <Pine.LNX.4.21.0010030851170.1072-100000@agony.busboom.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Eric Busboom wrote:

> On Tue, 3 Oct 2000, John Stracke wrote:
>
> John, you said you didn't feel strongly about this issue :).

Yeah, well...

> >    * A "fetch a file" URL, which includes a filename.  (If it's an http: URL, the
> >      server can also use the Content-Disposition: header.)
>
> Sometimes the URL includes a filename, but it is becoming more common to
> distribute URLs that point into a document management system (I've used
> LiveLink) where the filename is either a node number or is deeply embedded
> in the URL.

Mmm.  Such systems are arguably broken, because the documents being managed can't use
relative URLs to point to each other.  I have no particular remorse over not supporting
them.

> Using Content-Disposition is a good way to do it, but only from the HTTP
> Server's perspective. I think it just moves the responsibility for a
> problem in the calendaring application to a system that is not controlled
> by the calendaring spec.

That's a *good* thing.  We should not be specifying features that already exist.

> > If we introduce FILE-NAME, then the first two cases become problematic: what if the
> > FILE-NAME and the filename derived from the URL don't match? Different
> > implementations will make different choices, and you'll be right back where you
> > started.
>
> Clients will only make different choices if the specification does not
> indicate which choice to make.

Excuse me while I laugh hollowly.

Example of a category of client that will not follow the FILE-NAME spec: one that already
exists.

More generally, any time we have to introduce rules like this to clear up an ambiguity,
we can be certain that we're making a mistake.  It is better to make sure that it is not
possible to construct an ambiguous message.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |If all the world's a stage, I want to operate|
|francis@ecal.com|the trap door.                               |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Tue Oct  3 16:32:34 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22786
	for <calsch-archive@odin.ietf.org>; Tue, 3 Oct 2000 16:32:33 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA28002
	for ietf-calendar-bks; Tue, 3 Oct 2000 13:02:48 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27995
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 13:02:44 -0700 (PDT)
Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA08260
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 16:06:30 -0400 (EDT)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id QAA94348;
	Tue, 3 Oct 2000 16:06:30 -0400 (EDT)
	(envelope-from lennox)
Date: Tue, 3 Oct 2000 16:06:30 -0400 (EDT)
Message-Id: <200010032006.QAA94348@conrail.cs.columbia.edu>
From: Jonathan Lennox <lennox@cs.columbia.edu>
To: ietf-calendar@imc.org
Subject: RFC 2445: Recurrence question
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

RFC 2445 says:

   If BYxxx rule part values are found which are beyond the available
   scope (ie, BYMONTHDAY=30 in February), they are simply ignored.

Does this also apply to a value derived from DTSTART?  I.e., is the second
occurence of

        DTSTART:20000831T090000Z
        RRULE:FREQ=MONTHLY

October 31, 2000, and September is skipped?

-- 
Jonathan Lennox
lennox@cs.columbia.edu


From owner-ietf-calendar@mail.imc.org  Tue Oct  3 17:02:22 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23238
	for <calsch-archive@odin.ietf.org>; Tue, 3 Oct 2000 17:02:22 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA29376
	for ietf-calendar-bks; Tue, 3 Oct 2000 13:43:58 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29367
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 13:43:52 -0700 (PDT)
Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA11180
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 16:47:40 -0400 (EDT)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id QAA94398;
	Tue, 3 Oct 2000 16:47:40 -0400 (EDT)
	(envelope-from lennox)
Date: Tue, 3 Oct 2000 16:47:40 -0400 (EDT)
Message-Id: <200010032047.QAA94398@conrail.cs.columbia.edu>
From: Jonathan Lennox <lennox@cs.columbia.edu>
To: ietf-calendar@imc.org
Subject: RFC 2445: Question on interaction of RRULE COUNT and Timezones
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

In an RRULE with a COUNT parameter, is the recurrence count supposed to take
into account repeated or dropped times due to time zone shifts?
Specifically, is the full enumeration of

        DTSTART;TZID=US-Eastern:20001028T013000
        RRULE:FREQ=DAILY;BYHOUR=1;COUNT=4

Sat, Oct 28 2000, 01:30:00 EDT
Sun, Oct 29 2000, 01:30:00 EDT
Sun, Oct 29 2000, 01:30:00 EST (1 hour later)
Mon, Oct 30 2000, 01:30:00 EST

or is there an occurence on October 31 as well (as you would expect in the
absence of a DST shift)?

Similarly, what happens for

        DTSTART;TZID=US-Eastern:20000401T023000
        RRULE:FREQ=DAILY;BYHOUR=2;COUNT=4

(the EST - EDT transition)?  Is April 2nd skipped?  Does it matter whether
the duration is more or less than a half hour?

-- 
Jonathan Lennox
lennox@cs.columbia.edu


From owner-ietf-calendar@mail.imc.org  Tue Oct  3 19:02: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 TAA24550
	for <calsch-archive@odin.ietf.org>; Tue, 3 Oct 2000 19:02:06 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02165
	for ietf-calendar-bks; Tue, 3 Oct 2000 15:37:28 -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 PAA02161
	for <ietf-calendar@imc.org>; Tue, 3 Oct 2000 15:37:27 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id PAA25983;
	Tue, 3 Oct 2000 15:41:19 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Tue, 3 Oct 2000 15:41:19 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: John Stracke <francis@ecal.com>
cc: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
In-Reply-To: <39DA11AC.2625FC19@ecal.com>
Message-ID: <Pine.LNX.4.21.0010031538330.1072-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

On Tue, 3 Oct 2000, John Stracke wrote:

> More generally, any time we have to introduce rules like this to clear up an ambiguity,
> we can be certain that we're making a mistake.  It is better to make sure that it is not
> possible to construct an ambiguous message.

You're right. I don't really like additional rules either. However, I
still think it is important to keep file names for attached data
consistent between organizers and attendees. If my suggestions will not
get us there, can you suggest something that will?

eric. 



From owner-ietf-calendar@mail.imc.org  Wed Oct  4 12:41: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 MAA25686
	for <calsch-archive@odin.ietf.org>; Wed, 4 Oct 2000 12:41:03 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24347
	for ietf-calendar-bks; Wed, 4 Oct 2000 09:19:26 -0700 (PDT)
Received: from localhost.localdomain (thibault.org [207.8.144.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24343
	for <ietf-calendar@imc.org>; Wed, 4 Oct 2000 09:19:24 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA23378
	for <ietf-calendar@imc.org>; Wed, 4 Oct 2000 12:25:33 -0400
Message-ID: <39DB59FD.693C0406@ecal.com>
Date: Wed, 04 Oct 2000 12:25:33 -0400
From: John Stracke <francis@ecal.com>
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: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
References: <Pine.LNX.4.21.0010031538330.1072-100000@agony.busboom.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Eric Busboom wrote:

> You're right. I don't really like additional rules either. However, I
> still think it is important to keep file names for attached data
> consistent between organizers and attendees. If my suggestions will not
> get us there, can you suggest something that will?

How about this:

   * Deprecate the inline-binary syntax for ATTACH, in favor of using data: URIs (RFC-2397).
   * Write a document extending data: URIs to permit arbitrary Content-* headers (a Good
     Thing for many purposes, not just calendaring; for example, tagging inline content with
     Content-Language).
   * Now, if you want to send an inline attachment with a filename, use a data: URI with a
     Content-Disposition.

--
/================================================================\
|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.                                    |
\================================================================/





From owner-ietf-calendar@mail.imc.org  Wed Oct  4 16:36: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 QAA01285
	for <calsch-archive@odin.ietf.org>; Wed, 4 Oct 2000 16:36:54 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA29274
	for ietf-calendar-bks; Wed, 4 Oct 2000 13:08:09 -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 NAA29270
	for <ietf-calendar@imc.org>; Wed, 4 Oct 2000 13:08:05 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: John Stracke <francis@ecal.com>
Cc: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
X-Mailer: Lotus Notes Build V60_10012000 October 01, 2000
Message-ID: <OF17E13BD2.CD414A21-ON8525696E.006D643F@iris.com>
Date: Wed, 4 Oct 2000 16:11:22 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at
 10/04/2000 04:12:06 PM,
	Serialize complete at 10/04/2000 04:12:08 PM,
	Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at
 10/04/2000 04:12:08 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006F158D8525696E_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 006F158D8525696E_=
Content-Type: text/plain; charset="us-ascii"

John proposed:
>   * Deprecate the inline-binary syntax for ATTACH, in favor of using 
data: URIs (RFC-2397).
>   * Write a document extending data: URIs to permit arbitrary Content-* 
headers (a Good
>     Thing for many purposes, not just calendaring; for example, tagging 
inline content with
>     Content-Language).
>   * Now, if you want to send an inline attachment with a filename, use a 
data: URI with a
>     Content-Disposition.

I have a concern about backwards compatability here and usefulness of the 
effort.  The bullets effectively replace the current inline form with 
another to "fix" an issue that noone seems to have really run into yet in 
their engines that Ive seen.  While Im no fan of the inline binary (a last 
minute addition by Ye Ole Editors w/o any WG air time), I do not want to 
make changes that breaks work thats already been done and in use.

Wouldn't it be much much simpler to NOT inline ATTACHments that you want 
to convey such meta information for and instead put them into their own 
proper MIME body part w/the desired headers??  For the quite rare case of 
wanting to inline 'em you lose that info??

I did an admittedly quick survey of ~5 active C&S users here and I could 
find _0_ attachments under ~200K (.DOC files).    The _vast_ majority were larger 
typically .ZIPs of presentations or overheads averaging well over ~325K.

Unless there is some real interest in keeping inline ATTACHments then why 
not just remove the ability outright?  Its simpler and faster than doing 
all the bullets.  That way I can keep the existing code that works for 
vCards (where my SOUND, LOGO and PHOTO all are inline) w/o writing new 
code for a case that IMNHO is less than .5% of the ATTACHment cases...

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 006F158D8525696E_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">John proposed:</font>
<br><font size=2 face="Courier New">&gt; &nbsp; * Deprecate the inline-binary syntax for ATTACH, in favor of using data: URIs (RFC-2397).<br>
&gt; &nbsp; * Write a document extending data: URIs to permit arbitrary Content-* headers (a Good<br>
&gt; &nbsp; &nbsp; Thing for many purposes, not just calendaring; for example, tagging inline content with<br>
&gt; &nbsp; &nbsp; Content-Language).<br>
&gt; &nbsp; * Now, if you want to send an inline attachment with a filename, use a data: URI with a<br>
&gt; &nbsp; &nbsp; Content-Disposition.</font>
<br>
<br><font size=2 face="sans-serif">I have a concern about backwards compatability here and usefulness of the effort. &nbsp;The bullets effectively replace the current inline form with another to &quot;fix&quot; an issue that noone seems to have really run into yet in their engines that Ive seen. &nbsp;While Im no fan of the inline binary (a last minute addition by Ye Ole Editors w/o any WG air time), I do not want to make changes that breaks work thats already been done and in use.</font>
<br>
<br><font size=2 face="sans-serif">Wouldn't it be much much simpler to NOT inline ATTACHments that you want to convey such meta information for and instead put them into their own proper MIME body part w/the desired headers?? &nbsp;For the quite rare case of wanting to inline 'em you lose that info??</font>
<br>
<br><font size=2 face="sans-serif">I did an admittedly quick survey of ~5 active C&amp;S users here and I could find <u>_0_</u> attachments under ~200K (.DOC files). &nbsp; &nbsp;The _vast_ majority were larger &nbsp;typically .ZIPs of presentations or overheads averaging well over ~325K.</font>
<br>
<br><font size=2 face="sans-serif">Unless there is some real interest in keeping inline ATTACHments then why not just remove the ability outright? &nbsp;Its simpler and faster than doing all the bullets. &nbsp;That way I can keep the existing code that works for vCards (where my SOUND, LOGO and PHOTO all are inline) w/o writing new code for a case that IMNHO is less than .5% of the ATTACHment cases...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 006F158D8525696E_=--


From owner-ietf-calendar@mail.imc.org  Thu Oct  5 06:24:14 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 GAA24484
	for <calsch-archive@odin.ietf.org>; Thu, 5 Oct 2000 06:24:13 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id CAA20906
	for ietf-calendar-bks; Thu, 5 Oct 2000 02:50:26 -0700 (PDT)
Received: from hotmail.com (f40.law7.hotmail.com [216.33.237.40])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA20901
	for <ietf-calendar@imc.org>; Thu, 5 Oct 2000 02:50:24 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 5 Oct 2000 02:53:57 -0700
Received: from 203.199.129.60 by lw7fd.law7.hotmail.msn.com with HTTP;	Thu, 05 Oct 2000 09:53:56 GMT
X-Originating-IP: [203.199.129.60]
From: "Nitin Shingne" <n_shingne@hotmail.com>
To: ietf-calendar@imc.org
Cc: n_shingne@hotmail.com
Subject: Problem with Modify an Instance of Recurring Events ? RFC2445 & 46
Date: Thu, 05 Oct 2000 09:53:56 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F40jcxtniFKULPEhGD10000dce5@hotmail.com>
X-OriginalArrivalTime: 05 Oct 2000 09:53:57.0197 (UTC) FILETIME=[2DB077D0:01C02EB2]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Hi All,



Step1: Create a recurring event starting on 4th October and
	recurres everyday till 14th Oct.
	assume 	UID:AAAA1111@a.com
		SEQUENCE:0
		RID:20001004T100000Z
		...... & rest of the properties....

Step2: Modify an instance of this recurring event. say the one of 8th
Oct. Change the start time to 11 AM. According to RFC 2446 only the
Sequence number shall be incremented
	so the values shall be as
		UID:AAAA1111@a.com
		SEQUENCE:1
		RID:20001008T110000Z

Step3: Now modify all the instances of the recurring instance by
selecting the one dated	4th Oct to change the start time to 12PM.
	so the values shall be as
		UID:AAAA1111@a.com
		SEQUENCE:1
		RID:20001004T120000Z

Question: Now how do I differentiate between the event on 8th & other
events.	e.g. I now delete event dated 4th & all it's recurring
instances, then how shall I avoid deleting the event dated 8th Oct.?

Is it that the event created in Step 2 should have been assigned a new UID?



thanks & regards,
nitin
n_shingne@hotmail.com
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.



From owner-ietf-calendar@mail.imc.org  Thu Oct  5 09:06:29 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28260
	for <calsch-archive@odin.ietf.org>; Thu, 5 Oct 2000 09:06:28 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA27200
	for ietf-calendar-bks; Thu, 5 Oct 2000 05:36:53 -0700 (PDT)
Received: from localhost.localdomain ([216.52.68.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27196
	for <ietf-calendar@imc.org>; Thu, 5 Oct 2000 05:36:48 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id IAA26690
	for <ietf-calendar@imc.org>; Thu, 5 Oct 2000 08:43:41 -0400
Message-ID: <39DC777C.E151BCB8@ecal.com>
Date: Thu, 05 Oct 2000 08:43:40 -0400
From: John Stracke <francis@ecal.com>
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: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
References: <OF17E13BD2.CD414A21-ON8525696E.006D643F@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Bruce_Kahn@iris.com wrote:

> Wouldn't it be much much simpler to NOT inline ATTACHments that
> you want to convey such meta information for and instead put
> them into their own proper MIME body part w/the desired
> headers??  For the quite rare case of wanting to inline 'em you
> lose that info??

Yeah, that does make sense.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"But she calls her ship _Mercy of the Goddess_!"|
|francis@ecal.com|"Kali." "Oh."                                   |
\=================================================================/





From owner-ietf-calendar@mail.imc.org  Fri Oct  6 13:49: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 NAA09417
	for <calsch-archive@odin.ietf.org>; Fri, 6 Oct 2000 13:49:46 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12545
	for ietf-calendar-bks; Fri, 6 Oct 2000 10:22:11 -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 KAA12541
	for <ietf-calendar@imc.org>; Fri, 6 Oct 2000 10:22:09 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id KAA11587
	for <ietf-calendar@imc.org>; Fri, 6 Oct 2000 10:26:15 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Fri, 6 Oct 2000 10:26:15 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: calsch WG <ietf-calendar@imc.org>
Subject: Re: Proposed Text for RFC2445 Issue #1
In-Reply-To: <39DC777C.E151BCB8@ecal.com>
Message-ID: <Pine.LNX.4.21.0010061015520.10819-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

On Thu, 5 Oct 2000, John Stracke wrote:

> Bruce_Kahn@iris.com wrote:
> 
> > Wouldn't it be much much simpler to NOT inline ATTACHments that
> > you want to convey such meta information for and instead put
> > them into their own proper MIME body part w/the desired
> > headers??  For the quite rare case of wanting to inline 'em you
> > lose that info??
> 
> Yeah, that does make sense.

If inline attachments for which a file name is important are going to be
rare then I wouldn't mind ignoring the issue. 

Then, unless there are other objections, I will REJECT RFC2445 issue #1. 

Perhaps we should also add a bit to the Implementors Guide, suggesting
that implementors stick to non-inlined attachments if the filename is
important.

Now, what do you think about issue #3?
	http://www.imc.org/ietf-calendar/mail-archive/msg04618.html

eric. 




From owner-ietf-calendar@mail.imc.org  Fri Oct  6 14:21: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 OAA09974
	for <calsch-archive@odin.ietf.org>; Fri, 6 Oct 2000 14:21:30 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA13163
	for ietf-calendar-bks; Fri, 6 Oct 2000 11:02: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 LAA13159
	for <ietf-calendar@imc.org>; Fri, 6 Oct 2000 11:02:10 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id LAA11627;
	Fri, 6 Oct 2000 11:06:16 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Fri, 6 Oct 2000 11:06:15 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: Nitin Shingne <n_shingne@hotmail.com>
cc: ietf-calendar@imc.org
Subject: Re: Problem with Modify an Instance of Recurring Events ? RFC2445
 & 46
In-Reply-To: <F40jcxtniFKULPEhGD10000dce5@hotmail.com>
Message-ID: <Pine.LNX.4.21.0010061033320.10819-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

On Thu, 5 Oct 2000, Nitin Shingne wrote:

> Question: Now how do I differentiate between the event on 8th & other
> events.	e.g. I now delete event dated 4th & all it's recurring
> instances, then how shall I avoid deleting the event dated 8th Oct.?

Nitin, 

I suspect that you will have to explicitly compare each of the occurrences
to the original event to determine that any of them has been modified. It
seems that SEQUENCE is only used to distinguish revisions of a component
within a single pair of UID and RECURRENCE-ID. I don't think it was
intended for the use you suggest. 

Specifically regarding deletes, why wouldn't you want to delete the
8th? I'd expect that the 8th is still part of the set of recurring events,
and if you are going to delete the set, you'd delete the 8th also,
regardless of any modifications you make to it.
 
If your recurring event is a daily status meeting ( I *hate* those) and
you come to your senses and want to cancel all of them, why wouldn't you
want to cancel the one that you had to move later in the afternoon?

If you intend to change the event on the 8th so something else entirely --
you decide to skip the status meeting and hold a going away lunch for the
people who left the company because of your dreadful status meetings, then
you should CANCEL the meeting on the 8th and schedule a new meeting on the
8th, with a new UID. 


eric. 







From owner-ietf-calendar@mail.imc.org  Sat Oct  7 07:35:13 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04612
	for <calsch-archive@odin.ietf.org>; Sat, 7 Oct 2000 07:35:12 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA29479
	for ietf-calendar-bks; Sat, 7 Oct 2000 04:18:58 -0700 (PDT)
Received: from cmailg5.svr.pol.co.uk (cmailg5.svr.pol.co.uk [195.92.195.175])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA29474
	for <ietf-calendar@imc.org>; Sat, 7 Oct 2000 04:18:56 -0700 (PDT)
Received: from modem-232.massachusetts.dialup.pol.co.uk ([62.137.72.232] helo=helixcode.com)
	by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0)
	id 13hs4H-00078b-00; Sat, 07 Oct 2000 12:23:06 +0100
Message-ID: <39DDCEDA.139F9961@helixcode.com>
Date: Fri, 06 Oct 2000 14:08:42 +0100
From: Damon Chaplin <damon@helixcode.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Lennox <lennox@cs.columbia.edu>
CC: ietf-calendar@imc.org
Subject: Re: RFC 2445: Recurrence question
References: <200010032006.QAA94348@conrail.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jonathan Lennox wrote:
> 
> RFC 2445 says:
> 
>    If BYxxx rule part values are found which are beyond the available
>    scope (ie, BYMONTHDAY=30 in February), they are simply ignored.
> 
> Does this also apply to a value derived from DTSTART?  I.e., is the second
> occurence of
> 
>         DTSTART:20000831T090000Z
>         RRULE:FREQ=MONTHLY
> 
> October 31, 2000, and September is skipped?

Yes, I think so. (At least, that is how I have coded it.)

Damon




From owner-ietf-calendar@mail.imc.org  Sun Oct  8 03:24:14 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 DAA02592
	for <calsch-archive@odin.ietf.org>; Sun, 8 Oct 2000 03:24:14 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA17721
	for ietf-calendar-bks; Sat, 7 Oct 2000 23:56:00 -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 XAA17717
	for <ietf-calendar@imc.org>; Sat, 7 Oct 2000 23:55:58 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA15244
	for ietf-calendar@imc.org; Sun, 8 Oct 2000 00:00:03 -0700 (PDT)
Date: Sun, 8 Oct 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200010080700.AAA15244@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: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=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?					<variable>
      Can the server decide not to do this?	Y
  
 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 W-9 CAP MOVE method. Issues with VCARs.	Y
     [see note in CAP 7.2.1.5]
 
 W-10 CAP Text mandatory in all response	N
      codes
 
 W-11 CAP Text optional in response codes	Y
      (some response codes may have 
       mandatory data that follows)
       
 W-12 CAP Should parts of response code be	Y
      separated by ';'
      
 W-13 CAP Store Schema				Y
 
 W-14 CAP VEVENT Schema				Y
 
 W-15 CAP VTODO Schema				Y
 
 W-16 CAP VJOURNAL Schema			Y
 
 W-17 CAP VCAR Schema				Y

 W-18 CAP UPN definition, including anonymous	Y
      user and how UPN's are used in LDAP and
      certificates.
 
 W-19 CAP Group definitions, dynamic and	Y
      static and how groups are used in VCARs.
      Policy definitions, in a VCAR format.

 W-20 Associating UPN values with CREATED	N
      and LAST-MODIFIED properties.

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			Y in process

 W-23 CAP Calendar property to allow/disallow	N
      overlapped booking OPAQUE entries?

 W-24 CAP Calendar CHARSET property issues	Y

 W-25 Remove MUST from UID in 4.8.4.7		Y

 W-26 Write/Submit information draft/rfc	Y

 W-27 How a query can specify if the recurrence	Y
      rules are to be expanded by the CS.

 W-28 Cal-Props - PATH				N
      (CAP-00 - 12.2)
      Will there need to be one?		N
      Optional?					N

 W-29 Import/Export				Y - sync only

 W-30 Transport protocol name (transport vs	Y
      application layer)

 W-31 NOOP command?				Y

 W-32 NOOP advisory only?			Y

 W-33 Should DISCONNECT be called QUIT?		U

 W-34 Format following error codes. Are		Y
      they well defined? If not they
      need to be machine determinable. 

 W-35 Move DNS and SLP to seperate draft?	Y

------------------------------------------------------------------------------

 The following are a list of action items for the draft editors:
 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------
	
 C-1 Remove unused definitions				N

 C-2 Fix up changes in authentication		Alex	Y
     text as commented on the list		Paul

 C-3 Text for 2.7 [Finding CAP Servers]		Doug	D
 
 C-4 VCAR examples				Doug?	Y
 
 C-5 PUBLISH text					Y
 
 C-6 REQUEST text					Y
 
 C-7 REPLY text						Y

 C-8 ADD text						Y
 
 C-9 CANCEL text 					Y
 
 C-10 REFRESH text					Y
 
 C-11 COUNTER text					Y
 
 C-12 DECLINECOUNTER Text				Y

 C-13 Post CAP-00.txt					Y

 C-14 Redo state diagram to include STARTTLS		Y
      and IDENTIFY command.

 C-15 Document the 'CALMASTER' calendar property	Y

 C-16 (2.11)  Query Schema				Y

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties			Y

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS				D

	Format? Text needs to be written.

 C-20 (13.) Security Considerations			Y

	See editors note - more text.

 C-21 Resubmit REQUIREMENTS draft.			Y

 C-22 Document MAXSIZE and MAXRESULT			N

 C-23 Document METHOD is stored in CS database		N
       Only one 'CREATE' per UID.
       Multple non-CREATE per UID.

 C-24 Fix the RESPONSE's to be consistant.		N
      and multiple components, one for each TARGET.

------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:
 (iCal, iTIP, iMIP)

 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------

 I-1 MIME alternate/related			Frank	?
     MUST be supported.

 I-2 Remove ordering of properties and		Frank	?
     parameters in draft.

 I-3 S/MIME and RFC1847.			U
     [CAP] 2.2.3

 I-4 Add ALARMID to VALARM!


 I-5 iTIP error. VJOURNAL should be
     0 (not 0+) for CANCEL


------------------------------------------------------------------------------


Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM

--------------------------------------------------------------------------
Work: Doug.Royer@Software.com              Home    801 Woodside Rd #14-244
      530 E. Montecito St.                 Office: Redwood City, CA 94061
      Santa Barbara, CA 93103
      805-957-1790 x541                    Personal Email: Doug@Royer.com

Tuesday discussion:

DONE
Section 2.4.3 - editor note:
	Change with new paragraph;  Groups may be in a directory with its
	own ACL model and CAP should use the directory service to expand a
	UPN subject to the directory service access control model
	for the authenticated entity.  

DONE
Section 2.4.4.1 - editor note:
	Your access is a  union of all your grants minus a union of all
	your denies.  (We still need to discuss  ordering - allow or not.
	We may not want to fool with it).

DONE
Section 2.4.4.2 - editor note:
	We need an example (Steve/Doug) - Paul needs to read this note an example).

Section 2.6
	CALID - need to define that relative CALID must be consistent with
	the scheme specific part of URI as defined in RFC xxx. - Steve

Section 2.9
	Will be discussed earlier in draft - remove altogether.

Section 7.1.3
	Need to get IANA registration

Section 7.1.3
	Delete editors note about blank on examples.  Need to add an
	unsuccessful login.  Delete all lines except the line that starts with
	"The following...." - (* Who will do this example)

DONE
Section 7.2.1.1.1
	Get rid of whole paragraph (pargraph above).  If you want to
	generate unique relative CALids, use the GENERATE UID command
	and use the result as the relative CALid.  (we need to make
	sure that the results are characters that are compatible
	with our definition of calids)

Section 7.2.1.3.
	The result needs to be consistent with CALID character rules
	(i.e. no spaces). The example needs one more line with a dot.
	Steve will do this.

DONE
Section 7.2.1.5
	This issue goes away because we are not doing heirarchial.
	Remove editors note

Section 7.2.1.7
	Add an example of a partial result - we want to get something that
	matches some things, and on the ones you don't have access, you don't
	have rights to some of the components. George will write up something. 

Section 7.2.2
	Need restriction tables.  Some are CAP - for the rest of them
	use iTIP tables (Steve/Doug) we all need to review the text

DONE
Section 7.2.3.2
	Pull editors note - fix applied

Section 8.0
	Response codes.  Need to make sure response codes in all drafts - iCal,
	iMip and iTip and examples. Error numbers need to be the same.  Put
	text about error codes in comments below the examples (so that
	people don't look at them as being required in their text).  Pat
	will look at the codes.	

Section 11.0
	DTN, DTSTAMP, etc are implementations that may need to be considered.
	Restrictions tables may resolve these issues. 

Section 12.0
	Leave as is until we get people to agree.  On version shipped after
	last call, this is what we are going to enhance this section. It
	does not make sense to do this until working group last call.
	Updates to iCalendar need to be written and will not be submitted
	to IANA until last call to WG. Doug

Section 13.0
	This section is not ready for prime time. Need Paul Hill.
	Need an editors note.

Section 14.0
	Needs to be reformatted - Doug will make sure it is consistent.
	George will do 14

DONE
Section 15.1.1.
	Steve - additions or changes to the CAP schema (replaces Define
	the Entity).  Word entity needs to be removed and replaced throughout
	the document).

Section 15.1.4
	Submit entity for approval - John submitted to list.  Need to find.
	Get John's text and add back into CAP draft.  John submitted as a
	separate draft document. Use the MIME appeal verbage with John's
	additional text. Point WG at John's draft and say it should be
	included in the draft.  We need to also submit to April Marine as well.

DONE
Section 16.0
	Remove reference to vCard

- - - - - - 
Assignment list:

Section 2.4.4.2 - VCAR example  (Steve/Doug)
Sectoin 2.6 - Steve will research
Section 7.1.3 - IANA registration (Pat)
Section 7.1.3 - example of unsuccessful login (Who)
Section 7.2.1.1. - look at Calid characters (Doug)
Section 7.2.1.3 - example line (Steve)
Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug)
Section 7.2.2. - Restriction tables (Steve/Doug)
Section 8.0 - look at consistency of Response code in all drafts (Pat)
Section 12.0 - needs work. Check for consistency - Doug
Section 13.0 - Paul Hill
Section 14.0 - George
Section 15.1.1 - replace text (Pat)
Section 15.1.4 - add John's text to doc and put on list to look at proposal.
 - - - - -

Work on Restriction table

Editor note: Remove references to VDATA (mistake)


Editor note:
GENERATE UID is not a method.  It's wrong in section 7.1.2.3
Ditto with NOOP - Section 7.2.1.6



From owner-ietf-calendar@mail.imc.org  Sun Oct  8 09:33:34 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09264
	for <calsch-archive@odin.ietf.org>; Sun, 8 Oct 2000 09:33:34 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26955
	for ietf-calendar-bks; Sun, 8 Oct 2000 06:13:45 -0700 (PDT)
Received: from ra.ibn.de (root@p3E9C26D6.dip0.t-ipconnect.de [62.156.38.214])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26951
	for <ietf-calendar@imc.org>; Sun, 8 Oct 2000 06:13:42 -0700 (PDT)
Received: from ibn.de (root@ra.ibn.de [192.168.5.100])
	by ra.ibn.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA00838
	for <ietf-calendar@imc.org>; Sun, 8 Oct 2000 15:05:54 +0200
Message-ID: <39E07130.A4EE7E6D@ibn.de>
Date: Sun, 08 Oct 2000 15:05:52 +0200
From: Martin Neimeier <nei@ibn.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF-Calendar-Mailinglist <ietf-calendar@imc.org>
Subject: VCAR-Specification ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello,

where can I get the latest definitions for the VCAR-Component (or better a newer version of
RFC-2445) ?

Regards
Martin Neimeier
-- 
UNIX was never designed to keep people from doing stupid things, because
that policy would also keep them from doing clever things.   (Doug Gwyn)
--
Martin Neimeier/Ingenieur-Buero Neimeier/Schwarzach/Germany
mailto:nei@ibn.de/http://www.ibn.de(under heavy
reconstruction)/Tel:+49(6262)912344/Fax:+49(6262)912347


From owner-ietf-calendar@mail.imc.org  Sun Oct  8 13:05:57 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10151
	for <calsch-archive@odin.ietf.org>; Sun, 8 Oct 2000 13:05:56 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03915
	for ietf-calendar-bks; Sun, 8 Oct 2000 09:43:07 -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 JAA03911
	for <ietf-calendar@imc.org>; Sun, 8 Oct 2000 09:43:06 -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 e98Ge8I17850
	for <ietf-calendar@imc.org>; Sun, 8 Oct 2000 09:40:08 -0700 (PDT)
Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com
          (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with
          ESMTP id G24EM600.3BM; Sun, 8 Oct 2000 09:46:54 -0700 
Message-ID: <39E0A46D.70E393D4@netscape.com>
Date: Sun, 08 Oct 2000 09:44:29 -0700
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Martin Neimeier <nei@ibn.de>
CC: IETF-Calendar-Mailinglist <ietf-calendar@imc.org>
Subject: Re: VCAR-Specification ?
References: <39E07130.A4EE7E6D@ibn.de>
Content-Type: multipart/mixed;
 boundary="------------367E6D873B5528AC37773ABB"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.
--------------367E6D873B5528AC37773ABB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Martin,

The VCAR component is not actually described in RFC2445. It is an extension being defined for
CAP.  The latest version is at
ftp://royer.com/pub/CALSCH/draft-ietf-calsch-cap-03-interim.txt.gz

-Steve

Martin Neimeier wrote:

> Hello,
>
> where can I get the latest definitions for the VCAR-Component (or better a newer version of
> RFC-2445) ?
>
> Regards
> Martin Neimeier
> --
> UNIX was never designed to keep people from doing stupid things, because
> that policy would also keep them from doing clever things.   (Doug Gwyn)
> --
> Martin Neimeier/Ingenieur-Buero Neimeier/Schwarzach/Germany
> mailto:nei@ibn.de/http://www.ibn.de(under heavy
> reconstruction)/Tel:+49(6262)912344/Fax:+49(6262)912347

--------------367E6D873B5528AC37773ABB
Content-Type: text/x-vcard; charset=us-ascii;
 name="sman.vcf"
Content-Description: Card for Steve Mansour
Content-Disposition: attachment;
 filename="sman.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Mansour;Steve
tel;fax:650-937-2103
tel;work:650-937-2378
x-mozilla-html:FALSE
org:Netscape
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043;
x-mozilla-cpt:;-10552
fn:Steve Mansour
end:vcard

--------------367E6D873B5528AC37773ABB--



From owner-ietf-calendar@mail.imc.org  Sun Oct  8 20:44: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 UAA12483
	for <calsch-archive@odin.ietf.org>; Sun, 8 Oct 2000 20:44:28 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id RAA11938
	for ietf-calendar-bks; Sun, 8 Oct 2000 17:10:07 -0700 (PDT)
Received: from xjf.xjfi.net (szptt103-190.szptt.net.cn [202.103.190.150] (may be forged))
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA11934
	for <ietf-calendar@imc.org>; Sun, 8 Oct 2000 17:10:05 -0700 (PDT)
Date: Sun, 8 Oct 2000 17:10:05 -0700 (PDT)
From: rsb@docsj.de
Message-Id: <200010090010.RAA11934@ns.secondary.com>
Received: from pavilion (204.31.170.62 [204.31.170.62]) by xjf.xjfi.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id 4PRZ2AM9; Mon, 9 Oct 2000 08:21:07 +0800
To: rsb@docsj.de
Subject: At last, HERBAL V the all natural alternative!
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


Herbal V: An Incredible All-Natural Healthy Alternative 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $24


______ 2 Bottles of Herbal V $44


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.


From owner-ietf-calendar@mail.imc.org  Sun Oct  8 21:37: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 VAA13805
	for <calsch-archive@odin.ietf.org>; Sun, 8 Oct 2000 21:37:38 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12948
	for ietf-calendar-bks; Sun, 8 Oct 2000 18:16:57 -0700 (PDT)
Received: from mail2.svr.pol.co.uk (mail2.svr.pol.co.uk [195.92.193.210])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12943
	for <ietf-calendar@imc.org>; Sun, 8 Oct 2000 18:16:54 -0700 (PDT)
Received: from modem-81.curufin.dialup.pol.co.uk ([62.136.148.209] helo=helixcode.com)
	by mail2.svr.pol.co.uk with esmtp (Exim 3.13 #0)
	id 13iRcs-0001gk-00; Mon, 09 Oct 2000 02:21:11 +0100
Message-ID: <39E115D3.67B931F8@helixcode.com>
Date: Mon, 09 Oct 2000 01:48:19 +0100
From: Damon Chaplin <damon@helixcode.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Lennox <lennox@cs.columbia.edu>
CC: ietf-calendar@imc.org
Subject: Re: RFC 2445: Question on interaction of RRULE COUNT and Timezones
References: <200010032047.QAA94398@conrail.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Jonathan Lennox wrote:
> 
> In an RRULE with a COUNT parameter, is the recurrence count supposed to take
> into account repeated or dropped times due to time zone shifts?
> Specifically, is the full enumeration of
> 
>         DTSTART;TZID=US-Eastern:20001028T013000
>         RRULE:FREQ=DAILY;BYHOUR=1;COUNT=4
> 
> Sat, Oct 28 2000, 01:30:00 EDT
> Sun, Oct 29 2000, 01:30:00 EDT
> Sun, Oct 29 2000, 01:30:00 EST (1 hour later)
> Mon, Oct 30 2000, 01:30:00 EST
> 
> or is there an occurence on October 31 as well (as you would expect in the
> absence of a DST shift)?

I'd be surprised if there were 2 events on Oct 29. It is supposed to be a DAILY
recurrence.

Though I don't know which of the 2 occurrences on Oct 29 should be used.
Anyone know if the spec covers this?
I'd probably go for the first time (EDT).

 
> Similarly, what happens for
> 
>         DTSTART;TZID=US-Eastern:20000401T023000
>         RRULE:FREQ=DAILY;BYHOUR=2;COUNT=4
> 
> (the EST - EDT transition)?  Is April 2nd skipped?  Does it matter whether
> the duration is more or less than a half hour?

That's an interesting question too.
I'd guess that if the occurrence disappears completely you skip it,
otherwise it gets truncated.

Damon



From owner-ietf-calendar@mail.imc.org  Sun Oct  8 22: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 SMTP id WAA15056
	for <calsch-archive@odin.ietf.org>; Sun, 8 Oct 2000 22:40:19 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id TAA14638
	for ietf-calendar-bks; Sun, 8 Oct 2000 19:20:47 -0700 (PDT)
Received: from mail2.mia.bellsouth.net (mail2.mia.bellsouth.net [205.152.144.14])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA14634
	for <ietf-calendar@imc.org>; Sun, 8 Oct 2000 19:20:46 -0700 (PDT)
From: bubblehead32@hotmail.com
Received: from www.goldendeckcasino.com (adsl-61-143-206.mia.bellsouth.net [208.61.143.206])
	by mail2.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id WAA19312;
	Sun, 8 Oct 2000 22:14:48 -0400 (EDT)
Message-Id: <200010090214.WAA19312@mail2.mia.bellsouth.net>
To: <>
Subject: WOW!!! Highest Payouts Around!!!!!!!!
Date: Sun, 08 Oct 2000 21:57:08 -0400
X-Sender: bubblehead32@hotmail.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3
X-MSMail-Priority: Normal
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html.

If you would like to be removed from these mailings in the future please mailto:bubblehead32@hotmail.com?subject=remove


From owner-ietf-calendar@mail.imc.org  Mon Oct  9 10:30:17 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 KAA04737
	for <calsch-archive@odin.ietf.org>; Mon, 9 Oct 2000 10:30:16 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA09406
	for ietf-calendar-bks; Mon, 9 Oct 2000 07:06:56 -0700 (PDT)
Received: from localhost.localdomain ([216.52.68.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09402
	for <ietf-calendar@imc.org>; Mon, 9 Oct 2000 07:06:55 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA09670
	for <ietf-calendar@imc.org>; Mon, 9 Oct 2000 10:14:13 -0400
Message-ID: <39E1D2B4.9CF67093@ecal.com>
Date: Mon, 09 Oct 2000 10:14:12 -0400
From: John Stracke <francis@ecal.com>
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: RFC 2445: Question on interaction of RRULE COUNT and Timezones
References: <200010032047.QAA94398@conrail.cs.columbia.edu> <39E115D3.67B931F8@helixcode.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Damon Chaplin wrote:

> I'd probably go for the first time (EDT).

So would I, because people who are staying up until 1:30AM are probably going to
say, "OK, 1:30 is two hours past 11:30".

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Chris is the most self-effacing guy I know."|
|francis@ecal.com|"Well, I'm not *that* good at it."           |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Mon Oct  9 16:00: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 QAA09518
	for <calsch-archive@odin.ietf.org>; Mon, 9 Oct 2000 16:00:59 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA18858
	for ietf-calendar-bks; Mon, 9 Oct 2000 12:35:37 -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 MAA18854
	for <ietf-calendar@imc.org>; Mon, 9 Oct 2000 12:35:36 -0700 (PDT)
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id MAA25209
	for <ietf-calendar@imc.org>; Mon, 9 Oct 2000 12:40:00 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Mon, 9 Oct 2000 12:40:00 -0700 (PDT)
From: Eric Busboom <eric@softwarestudio.org>
X-Sender: eric@agony.busboom.org
To: ietf-calendar@imc.org
Subject: Proposed Text for RFC2445 Issue #15: Recurrence Rules
Message-ID: <Pine.LNX.4.21.0010091156090.25070-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


This is a proposal to address RFC2445 Issue number 15, from the issues
list online at:
 
        http://www.softwarestudio.org/iCal/2445Issues.html
 
Issue #15 is:

	Restrictions on RECUR rules
	http://www.imc.org/ietf-calendar/mail-archive/msg03656.html

This proposal will be open for discussion for two weeks, so please send
any comments soon.
 
eric.
 
-----------------------------------------------------------------------------
 
[This proposed text is an addition to RFC2445, section 4.3.10. It is
intended to disallow recurrence rules that are nonsensical or for which
there is no common interpretation. The goal is to make it easier to
implement recurrences and make it more likely that differenct
implementations will be interoperable]

[ NOTE: If you want to dispute this proposal *please* include an
illustrative recurrence rule and an accompanying description. This is a
really complex subject and we need to keep the discussions grounded in
actual use and need. ]

There are two types of BYxxx rules; date BYxxx rule parts that specify
time periods equal to or longer than a day, and time BYxxx rule parts that
specify the time periods less than a day. The day BYxxx rule parts are :
BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY. The time BYxxx rule
parts are BYHOUR, BYMINUTE, and BYSECOND. BYSETPOS is neither a date rule
part nor time rule part. 

Not all date BYxxx rule parts can appear simultaneously in a single
recurrence rule. Date BYxxx rule part restrictions are:

	[a] If the BYYEARDAY part appears in a rule , no other date rule
	part may appear.

	[b] BYWEEKNO and BYMONTH rule parts may not both appear. 
	[ except when week covers two months?]

Furthermore, not all date rule parts may be used with all recurrence
intervals.

	[c] For MONTHLY recurrences (FREQ=MONTHLY) neither BYYEARDAY nor
	BYWEEKNO may appear.

	[d] For WEEKLY recurrences (FREQ=WEEKLY) neither BYMONTHDAY nor
	BYYEARDAY may appear.
 
There are no restrictions regarding combinations of date rule parts and
time rule parts. There are no restrictions with using any combination of
time rule parts


[ The BYYEARDAY part, for a given year, effectively specifies the month,
day of month, and week number, so restriction [a] eliminates ambiguity
between the day of year and other specifiers. 

Restrictions [b] is similar, since the week number specifies the month for
a given year. There may be a probably with this restriction when the week
overlaps two months, though.

]



From owner-ietf-calendar@mail.imc.org  Tue Oct 10 11:57:13 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06743
	for <calsch-archive@odin.ietf.org>; Tue, 10 Oct 2000 11:57:13 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24801
	for ietf-calendar-bks; Tue, 10 Oct 2000 08:30:16 -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 IAA24777;
	Tue, 10 Oct 2000 08:30:13 -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 LAA26760;
	Tue, 10 Oct 2000 11:37:05 -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 LAA18002;
	Tue, 10 Oct 2000 11:34:08 -0400 (EDT)
To: Eric Busboom <eric@softwarestudio.org>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Proposed Text for RFC2445 Issue #15: Recurrence Rules
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF2950A97D.7E34A99B-ON85256974.00555034@lotus.com>
Date: Tue, 10 Oct 2000 11:33:41 -0400
X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Release 5.0.5 |September 22, 2000) at
 10/10/2000 11:33:44 AM,
	Serialize complete at 10/10/2000 11:33:44 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0055857F85256974_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 0055857F85256974_=
Content-Type: text/plain; charset="us-ascii"

Eric:
This reference to proposed restriction is written as a quandary rather 
than a proposal. I think that it needs some work prior to issuing it as a 
change proposal.
In addition, shouldn't each one be taken separately? Or at least number 
them so that we can reference the associates comments to the correct 
corresponding item.
-- Frank
--=_alternative 0055857F85256974_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 face="Courier New">Eric:</font>
<p><font size=3 face="Courier New">This reference to proposed restriction is written as a quandary rather than a proposal. I think that it needs some work prior to issuing it as a change proposal.</font>
<p><font size=3 face="Courier New">In addition, shouldn't each one be taken separately? Or at least number them so that we can reference the associates comments to the correct corresponding item.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 0055857F85256974_=--


From owner-ietf-calendar@mail.imc.org  Thu Oct 12 14:31:31 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03754
	for <calsch-archive@odin.ietf.org>; Thu, 12 Oct 2000 14:31:30 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA11348
	for ietf-calendar-bks; Thu, 12 Oct 2000 11:04:56 -0700 (PDT)
Received: from jupiter.wwweiss.de (jupiter.wwweiss.de [194.25.217.99])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11343
	for <ietf-calendar@imc.org>; Thu, 12 Oct 2000 11:04:54 -0700 (PDT)
Received: from ra.ibn.de [193.159.5.120] by wwweiss.de [194.25.217.98]
	with SMTP (MDaemon.v3.0.3.R)
	for <ietf-calendar@imc.org>; Thu, 12 Oct 2000 20:09:14 +0200
Received: from ibn.de (root@ra.ibn.de [192.168.5.100])
	by ra.ibn.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA04071
	for <ietf-calendar@imc.org>; Thu, 12 Oct 2000 20:05:17 +0200
Message-ID: <39E5FD5D.1070F7B8@ibn.de>
Date: Thu, 12 Oct 2000 20:05:17 +0200
From: Martin Neimeier <nei@ibn.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF-Calendar-Mailinglist <ietf-calendar@imc.org>
Subject: Typo in RFC2445
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: ietf-calendar@imc.org
X-Return-Path: nei@ibn.de
X-MDRcpt-To: ietf-calendar@imc.org
X-MDRemoteIP: 193.159.5.120
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hello,

after sending the examples of rfc 2445 through a parser I found the following:

Chapter 5 iCalendar Object Examples (on Page 136)

ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com

Now my question:
Is the above parameter ROLE for an ORGANIZER-Property allowed (i don't find anything about it) or is
it
simple a typo (cut'n'paste-error).

cu
Martin

-- 
UNIX was never designed to keep people from doing stupid things, because
that policy would also keep them from doing clever things.   (Doug Gwyn)
--
Martin Neimeier / Ingenieur-Buero Neimeier / Schwarzach / Germany
mailto:nei@ibn.de / http://www.ibn.de (under heavy reconstruction) / Tel:+49(6262)912344 /
Fax:+49(6262)912347



From owner-ietf-calendar@mail.imc.org  Thu Oct 12 15:42: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 PAA04824
	for <calsch-archive@odin.ietf.org>; Thu, 12 Oct 2000 15:42:01 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12780
	for ietf-calendar-bks; Thu, 12 Oct 2000 12:19:32 -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 MAA12776;
	Thu, 12 Oct 2000 12:19:30 -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 PAA22767;
	Thu, 12 Oct 2000 15:26:34 -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 PAA25244;
	Thu, 12 Oct 2000 15:23:38 -0400 (EDT)
To: Martin Neimeier <nei@ibn.de>
Cc: IETF-Calendar-Mailinglist <ietf-calendar@imc.org>,
        owner-ietf-calendar@mail.imc.org
Subject: Typo in RFC2445
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OFF9746AF5.419DBC5C-ON85256976.006A80D1@lotus.com>
Date: Thu, 12 Oct 2000 15:23:11 -0400
X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Release 5.0.5 |September 22, 2000) at
 10/12/2000 03:23:13 PM,
	Serialize complete at 10/12/2000 03:23:13 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006A87E585256976_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 006A87E585256976_=
Content-Type: text/plain; charset="us-ascii"

This appears to be a typo. Thanks!
--=_alternative 006A87E585256976_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 face="Courier New">This appears to be a typo. Thanks!</font>
--=_alternative 006A87E585256976_=--


From owner-ietf-calendar@mail.imc.org  Sun Oct 15 03:28: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 DAA03284
	for <calsch-archive@odin.ietf.org>; Sun, 15 Oct 2000 03:28:14 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA16155
	for ietf-calendar-bks; Sat, 14 Oct 2000 23:55:24 -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 XAA16151
	for <ietf-calendar@imc.org>; Sat, 14 Oct 2000 23:55:22 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA22015
	for ietf-calendar@imc.org; Sun, 15 Oct 2000 00:00:03 -0700 (PDT)
Date: Sun, 15 Oct 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200010150700.AAA22015@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: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=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?					<variable>
      Can the server decide not to do this?	Y
  
 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 W-9 CAP MOVE method. Issues with VCARs.	Y
     [see note in CAP 7.2.1.5]
 
 W-10 CAP Text mandatory in all response	N
      codes
 
 W-11 CAP Text optional in response codes	Y
      (some response codes may have 
       mandatory data that follows)
       
 W-12 CAP Should parts of response code be	Y
      separated by ';'
      
 W-13 CAP Store Schema				Y
 
 W-14 CAP VEVENT Schema				Y
 
 W-15 CAP VTODO Schema				Y
 
 W-16 CAP VJOURNAL Schema			Y
 
 W-17 CAP VCAR Schema				Y

 W-18 CAP UPN definition, including anonymous	Y
      user and how UPN's are used in LDAP and
      certificates.
 
 W-19 CAP Group definitions, dynamic and	Y
      static and how groups are used in VCARs.
      Policy definitions, in a VCAR format.

 W-20 Associating UPN values with CREATED	N
      and LAST-MODIFIED properties.

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			Y in process

 W-23 CAP Calendar property to allow/disallow	N
      overlapped booking OPAQUE entries?

 W-24 CAP Calendar CHARSET property issues	Y

 W-25 Remove MUST from UID in 4.8.4.7		Y

 W-26 Write/Submit information draft/rfc	Y

 W-27 How a query can specify if the recurrence	Y
      rules are to be expanded by the CS.

 W-28 Cal-Props - PATH				N
      (CAP-00 - 12.2)
      Will there need to be one?		N
      Optional?					N

 W-29 Import/Export				Y - sync only

 W-30 Transport protocol name (transport vs	Y
      application layer)

 W-31 NOOP command?				Y

 W-32 NOOP advisory only?			Y

 W-33 Should DISCONNECT be called QUIT?		U

 W-34 Format following error codes. Are		Y
      they well defined? If not they
      need to be machine determinable. 

 W-35 Move DNS and SLP to seperate draft?	Y

------------------------------------------------------------------------------

 The following are a list of action items for the draft editors:
 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------
	
 C-1 Remove unused definitions				N

 C-2 Fix up changes in authentication		Alex	Y
     text as commented on the list		Paul

 C-3 Text for 2.7 [Finding CAP Servers]		Doug	D
 
 C-4 VCAR examples				Doug?	Y
 
 C-5 PUBLISH text					Y
 
 C-6 REQUEST text					Y
 
 C-7 REPLY text						Y

 C-8 ADD text						Y
 
 C-9 CANCEL text 					Y
 
 C-10 REFRESH text					Y
 
 C-11 COUNTER text					Y
 
 C-12 DECLINECOUNTER Text				Y

 C-13 Post CAP-00.txt					Y

 C-14 Redo state diagram to include STARTTLS		Y
      and IDENTIFY command.

 C-15 Document the 'CALMASTER' calendar property	Y

 C-16 (2.11)  Query Schema				Y

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties			Y

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS				D

	Format? Text needs to be written.

 C-20 (13.) Security Considerations			Y

	See editors note - more text.

 C-21 Resubmit REQUIREMENTS draft.			Y

 C-22 Document MAXSIZE and MAXRESULT			N

 C-23 Document METHOD is stored in CS database		N
       Only one 'CREATE' per UID.
       Multple non-CREATE per UID.

 C-24 Fix the RESPONSE's to be consistant.		N
      and multiple components, one for each TARGET.

------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:
 (iCal, iTIP, iMIP)

 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------

 I-1 MIME alternate/related			Frank	?
     MUST be supported.

 I-2 Remove ordering of properties and		Frank	?
     parameters in draft.

 I-3 S/MIME and RFC1847.			U
     [CAP] 2.2.3

 I-4 Add ALARMID to VALARM!


 I-5 iTIP error. VJOURNAL should be
     0 (not 0+) for CANCEL


------------------------------------------------------------------------------


Updates should be sent to mailto:ietf-calendar@imc.org or to myself
mailto:Doug.Royer@Software.COM

--------------------------------------------------------------------------
Work: Doug.Royer@Software.com              Home    801 Woodside Rd #14-244
      530 E. Montecito St.                 Office: Redwood City, CA 94061
      Santa Barbara, CA 93103
      805-957-1790 x541                    Personal Email: Doug@Royer.com

Tuesday discussion:

DONE
Section 2.4.3 - editor note:
	Change with new paragraph;  Groups may be in a directory with its
	own ACL model and CAP should use the directory service to expand a
	UPN subject to the directory service access control model
	for the authenticated entity.  

DONE
Section 2.4.4.1 - editor note:
	Your access is a  union of all your grants minus a union of all
	your denies.  (We still need to discuss  ordering - allow or not.
	We may not want to fool with it).

DONE
Section 2.4.4.2 - editor note:
	We need an example (Steve/Doug) - Paul needs to read this note an example).

Section 2.6
	CALID - need to define that relative CALID must be consistent with
	the scheme specific part of URI as defined in RFC xxx. - Steve

Section 2.9
	Will be discussed earlier in draft - remove altogether.

Section 7.1.3
	Need to get IANA registration

Section 7.1.3
	Delete editors note about blank on examples.  Need to add an
	unsuccessful login.  Delete all lines except the line that starts with
	"The following...." - (* Who will do this example)

DONE
Section 7.2.1.1.1
	Get rid of whole paragraph (pargraph above).  If you want to
	generate unique relative CALids, use the GENERATE UID command
	and use the result as the relative CALid.  (we need to make
	sure that the results are characters that are compatible
	with our definition of calids)

Section 7.2.1.3.
	The result needs to be consistent with CALID character rules
	(i.e. no spaces). The example needs one more line with a dot.
	Steve will do this.

DONE
Section 7.2.1.5
	This issue goes away because we are not doing heirarchial.
	Remove editors note

Section 7.2.1.7
	Add an example of a partial result - we want to get something that
	matches some things, and on the ones you don't have access, you don't
	have rights to some of the components. George will write up something. 

Section 7.2.2
	Need restriction tables.  Some are CAP - for the rest of them
	use iTIP tables (Steve/Doug) we all need to review the text

DONE
Section 7.2.3.2
	Pull editors note - fix applied

Section 8.0
	Response codes.  Need to make sure response codes in all drafts - iCal,
	iMip and iTip and examples. Error numbers need to be the same.  Put
	text about error codes in comments below the examples (so that
	people don't look at them as being required in their text).  Pat
	will look at the codes.	

Section 11.0
	DTN, DTSTAMP, etc are implementations that may need to be considered.
	Restrictions tables may resolve these issues. 

Section 12.0
	Leave as is until we get people to agree.  On version shipped after
	last call, this is what we are going to enhance this section. It
	does not make sense to do this until working group last call.
	Updates to iCalendar need to be written and will not be submitted
	to IANA until last call to WG. Doug

Section 13.0
	This section is not ready for prime time. Need Paul Hill.
	Need an editors note.

Section 14.0
	Needs to be reformatted - Doug will make sure it is consistent.
	George will do 14

DONE
Section 15.1.1.
	Steve - additions or changes to the CAP schema (replaces Define
	the Entity).  Word entity needs to be removed and replaced throughout
	the document).

Section 15.1.4
	Submit entity for approval - John submitted to list.  Need to find.
	Get John's text and add back into CAP draft.  John submitted as a
	separate draft document. Use the MIME appeal verbage with John's
	additional text. Point WG at John's draft and say it should be
	included in the draft.  We need to also submit to April Marine as well.

DONE
Section 16.0
	Remove reference to vCard

- - - - - - 
Assignment list:

Section 2.4.4.2 - VCAR example  (Steve/Doug)
Sectoin 2.6 - Steve will research
Section 7.1.3 - IANA registration (Pat)
Section 7.1.3 - example of unsuccessful login (Who)
Section 7.2.1.1. - look at Calid characters (Doug)
Section 7.2.1.3 - example line (Steve)
Section 7.2.1.7 - George will write some verbage and we need to add an example of partial results (Steve/Doug)
Section 7.2.2. - Restriction tables (Steve/Doug)
Section 8.0 - look at consistency of Response code in all drafts (Pat)
Section 12.0 - needs work. Check for consistency - Doug
Section 13.0 - Paul Hill
Section 14.0 - George
Section 15.1.1 - replace text (Pat)
Section 15.1.4 - add John's text to doc and put on list to look at proposal.
 - - - - -

Work on Restriction table

Editor note: Remove references to VDATA (mistake)


Editor note:
GENERATE UID is not a method.  It's wrong in section 7.1.2.3
Ditto with NOOP - Section 7.2.1.6



From owner-ietf-calendar@mail.imc.org  Sun Oct 15 04:54:40 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07103
	for <calsch-archive@odin.ietf.org>; Sun, 15 Oct 2000 04:54:39 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id BAA19666
	for ietf-calendar-bks; Sun, 15 Oct 2000 01:24:56 -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 BAA19659
	for <ietf-calendar@imc.org>; Sun, 15 Oct 2000 01:24:52 -0700 (PDT)
Received: from [192.168.1.19] (ssh.cisco.com [171.69.10.34])
	by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id BAA07826;
	Sun, 15 Oct 2000 01:25:02 -0700 (PDT)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p05001989b60f19dcba6e@[192.168.1.19]>
In-Reply-To: <OFF9746AF5.419DBC5C-ON85256976.006A80D1@lotus.com>
References: <OFF9746AF5.419DBC5C-ON85256976.006A80D1@lotus.com>
Date: Sun, 15 Oct 2000 10:24:39 +0200
To: Frank_Dawson@lotus.com, Martin Neimeier <nei@ibn.de>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <paf@cisco.com>
Subject: Re: Typo in RFC2445
Cc: IETF-Calendar-Mailinglist <ietf-calendar@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

At 15.23 -0400 00-10-12, Frank_Dawson@lotus.com wrote:
>This appears to be a typo. Thanks!

Errors can (and should) be reported to the RFC-Editor.

This is a new thing, and the RFC-Editor is planning having a public 
errata page available.

    Patrik


From owner-ietf-calendar@mail.imc.org  Mon Oct 16 14:48:25 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13220
	for <calsch-archive@odin.ietf.org>; Mon, 16 Oct 2000 14:48:24 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21131
	for ietf-calendar-bks; Mon, 16 Oct 2000 11:23:24 -0700 (PDT)
Received: from elysium.uwa.edu.au (root@elysium.uwa.edu.au [130.95.128.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21117
	for <ietf-calendar@imc.org>; Mon, 16 Oct 2000 11:23:10 -0700 (PDT)
Received: from tartarus.uwa.edu.au (mtearle@tartarus.uwa.edu.au [130.95.128.3])
	by elysium.uwa.edu.au (8.10.2/8.10.2) with ESMTP id e9GIRud10243
	for <ietf-calendar@imc.org>; Tue, 17 Oct 2000 02:27:57 +0800 (WST)
Date: Tue, 17 Oct 2000 02:27:56 +0800 (WST)
From: Mark Tearle <mtearle@tearle.com>
X-Sender: mtearle@tartarus.uwa.edu.au
To: ietf-calendar@imc.org
Subject: iCal sighting in the wild
Message-ID: <Pine.LNX.4.20.0010170226460.4210-100000@tartarus.uwa.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Hi

This came through in last weeks Tidbits.

<http://www.microsoft.com/mac/products/office/2001/preview/entourage_preview2.asp#calendar>

I presume the are referring to iCal and iMiP.  Is anyone maintaining
a list of products that have iCal support so far?

Also, isn't an IETF meeting coming up RSN?

Yours
Mark
-- 
Mark Tearle - mark@tearle.com                          "You howl and listen
                                                    Listen and wait for the
                                          Echoes of angels who won't return"




From owner-ietf-calendar@mail.imc.org  Mon Oct 16 15:17: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 PAA13915
	for <calsch-archive@odin.ietf.org>; Mon, 16 Oct 2000 15:17:49 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21976
	for ietf-calendar-bks; Mon, 16 Oct 2000 11:53:27 -0700 (PDT)
Received: from localhost.localdomain (thibault.org [207.8.144.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21972
	for <ietf-calendar@imc.org>; Mon, 16 Oct 2000 11:53:24 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.11.0/8.11.0) with ESMTP id e9GJ0wt29170
	for <ietf-calendar@imc.org>; Mon, 16 Oct 2000 15:00:59 -0400
Message-ID: <39EB5068.AAE2C376@ecal.com>
Date: Mon, 16 Oct 2000 15:00:56 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586)
X-Accept-Language: en, de, es
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: iCal sighting in the wild
References: <Pine.LNX.4.20.0010170226460.4210-100000@tartarus.uwa.edu.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Mark Tearle wrote:

> I presume the are referring to iCal and iMiP.

Not necessarily.  They say "meeting requests can be sent to others over e-mail using the iCal
standard", which could just be sending an attached iCalendar, with no room for a reply (much
as vCalendar has been used in the past).

(This isn't to denegrate Mac Office; even basic iCalendar is useful.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"I said no camels! That's 5 camels! Can't you|
|francis@ecal.com|count?" -- Indiana Jones & TLC               |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Mon Oct 16 15:29:54 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 PAA14229
	for <calsch-archive@odin.ietf.org>; Mon, 16 Oct 2000 15:29:53 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA22100
	for ietf-calendar-bks; Mon, 16 Oct 2000 12:00:22 -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 MAA22092
	for <ietf-calendar@imc.org>; Mon, 16 Oct 2000 12:00:21 -0700 (PDT)
From: pregen@egenconsulting.com
To: Mark Tearle <mtearle@tearle.com>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: iCal sighting in the wild
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: <OFF2E3C99E.8CB0BD25-ON8525697A.0068BC37@com>
Date: Mon, 16 Oct 2000 13:05:05 -0600
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 10/16/2000 03:05:17 PM,
	Serialize complete at 10/16/2000 03:05:17 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0073E5738725697A_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 0073E5738725697A_=
Content-Type: text/plain; charset="us-ascii"

I have been planning on setting up an iCalendar web site with just this 
information.  I hope to have it up and running within a few weeks.  The 
next IETF meeting is December in San Diego.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652




Mark Tearle <mtearle@tearle.com>
Sent by: owner-ietf-calendar@mail.imc.org
10/16/00 12:27 PM

 
        To:     ietf-calendar@imc.org
        cc: 
        Subject:        iCal sighting in the wild

Hi

This came through in last weeks Tidbits.

<http://www.microsoft.com/mac/products/office/2001/preview/entourage_preview2.asp#calendar>

I presume the are referring to iCal and iMiP.  Is anyone maintaining
a list of products that have iCal support so far?

Also, isn't an IETF meeting coming up RSN?

Yours
Mark
-- 
Mark Tearle - mark@tearle.com                          "You howl and 
listen
                                                    Listen and wait for 
the
                                          Echoes of angels who won't 
return"





--=_alternative 0073E5738725697A_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">I have been planning on setting up an iCalendar web site with just this information. &nbsp;I hope to have it up and running within a few weeks. &nbsp;The next IETF meeting is December in San Diego.<br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Mark Tearle &lt;mtearle@tearle.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: owner-ietf-calendar@mail.imc.org</font>
<p><font size=1 face="sans-serif">10/16/00 12:27 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;ietf-calendar@imc.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;iCal sighting in the wild</font></table>
<br>
<br><font size=2><tt>Hi<br>
<br>
This came through in last weeks Tidbits.<br>
<br>
&lt;http://www.microsoft.com/mac/products/office/2001/preview/entourage_preview2.asp#calendar&gt;<br>
<br>
I presume the are referring to iCal and iMiP. &nbsp;Is anyone maintaining<br>
a list of products that have iCal support so far?<br>
<br>
Also, isn't an IETF meeting coming up RSN?<br>
<br>
Yours<br>
Mark<br>
-- <br>
Mark Tearle - mark@tearle.com &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;You howl and listen<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Listen and wait for the<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Echoes of angels who won't return&quot;<br>
<br>
<br>
</tt></font>
<br>
<br>
--=_alternative 0073E5738725697A_=--


From owner-ietf-calendar@mail.imc.org  Mon Oct 16 15:34:56 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14359
	for <calsch-archive@odin.ietf.org>; Mon, 16 Oct 2000 15:34:55 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA22334
	for ietf-calendar-bks; Mon, 16 Oct 2000 12:09:42 -0700 (PDT)
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22330
	for <ietf-calendar@imc.org>; Mon, 16 Oct 2000 12:09:41 -0700 (PDT)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 16 Oct 2000 12:13:22 -0700
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 16 Oct 2000 12:14:43 -0700 (Pacific Daylight Time)
Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 16 Oct 2000 12:14:42 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C037A5.554F1355"
Subject: RE: iCal sighting in the wild
Date: Mon, 16 Oct 2000 12:14:40 -0700
Message-ID: <DE1B1F489EDD6D4C9A0118DC3F6C3E732D2B44@DINO.platinum.corp.microsoft.com>
Thread-Topic: iCal sighting in the wild
Thread-Index: AcA3o1Jijx3EmAPYS1mUhQ82kubvdAAAY9nQ
From: "Naveen Kachroo" <nkachroo@Exchange.Microsoft.com>
To: "John Stracke" <francis@ecal.com>, <ietf-calendar@imc.org>
X-OriginalArrivalTime: 16 Oct 2000 19:14:42.0736 (UTC) FILETIME=[56898B00:01C037A5]
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C037A5.554F1355
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As some of you on the mailing list already know, Exchange 2000 Server
has shipped and supports a large subset of the RFC 2445/2446/2447
standards. We support both REQUEST and REPLY for icalendar and full
interop with Outlook/MAPI clients on the server. Download a copy today
and check it out.

http://www.microsoft.com/exchange/default.htm

-----Original Message-----
From: John Stracke [mailto:francis@ecal.com]
Sent: Monday, October 16, 2000 12:01 PM
To: ietf-calendar@imc.org
Subject: Re: iCal sighting in the wild


Mark Tearle wrote:

> I presume the are referring to iCal and iMiP.

Not necessarily.  They say "meeting requests can be sent to others over
e-mail using the iCal
standard", which could just be sending an attached iCalendar, with no
room for a reply (much
as vCalendar has been used in the past).

(This isn't to denegrate Mac Office; even basic iCalendar is useful.)

--
/=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\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist =
|=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|
|eCal Corp.      |"I said no camels! That's 5 camels! Can't you|
|francis@ecal.com|count?" -- Indiana Jones & TLC               |
\=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/



------_=_NextPart_001_01C037A5.554F1355
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4561.0">
<TITLE>RE: iCal sighting in the wild</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>As some of you on the mailing list already know, =
Exchange 2000 Server has shipped and supports a large subset of the RFC =
2445/2446/2447 standards. We support both REQUEST and REPLY for =
icalendar and full interop with Outlook/MAPI clients on the server. =
Download a copy today and check it out.</FONT></P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://www.microsoft.com/exchange/default.htm">http://www.microso=
ft.com/exchange/default.htm</A></FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: John Stracke [<A =
HREF=3D"mailto:francis@ecal.com">mailto:francis@ecal.com</A>]</FONT>

<BR><FONT SIZE=3D2>Sent: Monday, October 16, 2000 12:01 PM</FONT>

<BR><FONT SIZE=3D2>To: ietf-calendar@imc.org</FONT>

<BR><FONT SIZE=3D2>Subject: Re: iCal sighting in the wild</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mark Tearle wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I presume the are referring to iCal and =
iMiP.</FONT>
</P>

<P><FONT SIZE=3D2>Not necessarily.&nbsp; They say &quot;meeting requests =
can be sent to others over e-mail using the iCal</FONT>

<BR><FONT SIZE=3D2>standard&quot;, which could just be sending an =
attached iCalendar, with no room for a reply (much</FONT>

<BR><FONT SIZE=3D2>as vCalendar has been used in the past).</FONT>
</P>

<P><FONT SIZE=3D2>(This isn't to denegrate Mac Office; even basic =
iCalendar is useful.)</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>

<BR><FONT =
SIZE=3D2>/=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\</FONT>

<BR><FONT SIZE=3D2>|John Stracke&nbsp;&nbsp;&nbsp; | <A =
HREF=3D"http://www.ecal.com">http://www.ecal.com</A> |My opinions are my =
own.|</FONT>

<BR><FONT SIZE=3D2>|Chief Scientist =
|=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|</FONT>

<BR><FONT SIZE=3D2>|eCal Corp.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&quot;I =
said no camels! That's 5 camels! Can't you|</FONT>

<BR><FONT SIZE=3D2>|francis@ecal.com|count?&quot; -- Indiana Jones &amp; =
TLC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; |</FONT>

<BR><FONT =
SIZE=3D2>\=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/</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C037A5.554F1355--


From owner-ietf-calendar@mail.imc.org  Mon Oct 16 15:54:26 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14845
	for <calsch-archive@odin.ietf.org>; Mon, 16 Oct 2000 15:54:26 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA22780
	for ietf-calendar-bks; Mon, 16 Oct 2000 12:20:52 -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 MAA22776
	for <ietf-calendar@imc.org>; Mon, 16 Oct 2000 12:20:51 -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 PAA01744
	for <ietf-calendar@imc.org>; Mon, 16 Oct 2000 15:28:20 -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 PAA12456
	for <ietf-calendar@imc.org>; Mon, 16 Oct 2000 15:25:18 -0400 (EDT)
To: ietf-calendar@imc.org
Subject: Re: Typo in RFC2445
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF0B0E1BF9.8397E295-ON8525697A.006A9A46@lotus.com>
Date: Mon, 16 Oct 2000 15:24:51 -0400
X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Build V506_10102000 |October 10, 2000) at
 10/16/2000 03:24:53 PM,
	Serialize complete at 10/16/2000 03:24:53 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006AAF028525697A_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 006AAF028525697A_=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

----- Forwarded by Frank Dawson/CAM/Lotus on 10/16/2000 03:24 PM -----


Frank Dawson
10/16/2000 03:23 PM


        To:     Patrik F=E4ltstr=F6m <paf@cisco.com>
        cc:=20
        Subject:        Re: Typo in RFC2445

Patrik:
Is there a form, such as an "errata sheet" that we should use for this?
PS...I am moving to Nokia next month. In the interim, I will be moving=20
over to my fdawson@earthlink.net userid.
-- Frank




Patrik F=E4ltstr=F6m <paf@cisco.com>
10/15/2000 04:24 AM

=20
        To:     Frank=5FDawson@lotus.co, Martin Neimeier <nei@ibn.de>
        cc:     IETF-Calendar-Mailinglist <ietf-calendar@imc.org>
        Subject:        Re: Typo in RFC2445


At 15.23 -0400 00-10-12, Frank=5FDawson@lotus.com wrote:
>This appears to be a typo. Thanks!

Errors can (and should) be reported to the RFC-Editor.

This is a new thing, and the RFC-Editor is planning having a public=20
errata page available.

    Patrik




--=_alternative 006AAF028525697A_=
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D1 color=3D#800080 face=3D"sans-serif">----- Forwarded by F=
rank Dawson/CAM/Lotus on 10/16/2000 03:24 PM -----</font>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td>
<td><font size=3D1 face=3D"sans-serif"><b>Frank Dawson</b></font>
<p><font size=3D1 face=3D"sans-serif">10/16/2000 03:23 PM</font>
<br>
<td>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbs=
p; &nbsp; &nbsp; &nbsp;Patrik F=E4ltstr=F6m &lt;paf@cisco.com&gt;</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbs=
p; &nbsp; &nbsp; &nbsp;</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:=
 &nbsp; &nbsp; &nbsp; &nbsp;Re: Typo in RFC2445</font><a href=3DNotes:///85=
25641B0066E614/DABA975B9FB113EB852564B5001283EA/A48F5050205EDB6F85256979002=
E579A>Link</a></table>
<br>
<br><font size=3D3 color=3Dblue face=3D"Courier New">Patrik:</font>
<p><font size=3D3 color=3Dblue face=3D"Courier New">Is there a form, such a=
s an &quot;errata sheet&quot; that we should use for this?</font>
<p><font size=3D3 color=3Dblue face=3D"Courier New">PS...I am moving to Nok=
ia next month. In the interim, I will be moving over to my fdawson@earthlin=
k.net userid.</font>
<p><font size=3D3 color=3Dblue face=3D"Courier New">-- Frank</font>
<p>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td>
<td><font size=3D1 face=3D"sans-serif"><b>Patrik F=E4ltstr=F6m &lt;paf@cisc=
o.com&gt;</b></font>
<p><font size=3D1 face=3D"sans-serif">10/15/2000 04:24 AM</font>
<br>
<td><font size=3D1 face=3D"Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbs=
p; &nbsp; &nbsp; &nbsp;Frank=5FDawson@lotus.co, Martin Neimeier &lt;nei@ibn=
.de&gt;</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbs=
p; &nbsp; &nbsp; &nbsp;IETF-Calendar-Mailinglist &lt;ietf-calendar@imc.org&=
gt;</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:=
 &nbsp; &nbsp; &nbsp; &nbsp;Re: Typo in RFC2445</font></table>
<br>
<br>
<br><font size=3D2 face=3D"Courier New">At 15.23 -0400 00-10-12, Frank=5FDa=
wson@lotus.com wrote:<br>
&gt;This appears to be a typo. Thanks!<br>
<br>
Errors can (and should) be reported to the RFC-Editor.<br>
<br>
This is a new thing, and the RFC-Editor is planning having a public <br>
errata page available.<br>
<br>
 &nbsp; &nbsp;Patrik<br>
</font>
<br>
<br>
<br>
--=_alternative 006AAF028525697A_=--


From owner-ietf-calendar@mail.imc.org  Wed Oct 18 06:04: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 GAA14323
	for <calsch-archive@odin.ietf.org>; Wed, 18 Oct 2000 06:04:32 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id CAA29821
	for ietf-calendar-bks; Wed, 18 Oct 2000 02:42:12 -0700 (PDT)
Received: from elysium.uwa.edu.au (root@elysium.uwa.edu.au [130.95.128.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29800;
	Wed, 18 Oct 2000 02:41:56 -0700 (PDT)
Received: from tartarus.uwa.edu.au (mtearle@tartarus.uwa.edu.au [130.95.128.3])
	by elysium.uwa.edu.au (8.10.2/8.10.2) with ESMTP id e9I9kop24844;
	Wed, 18 Oct 2000 17:46:51 +0800 (WST)
Date: Wed, 18 Oct 2000 17:46:50 +0800 (WST)
From: Mark Tearle <mtearle@tearle.com>
X-Sender: mtearle@tartarus.uwa.edu.au
To: pregen@egenconsulting.com
cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: iCal sighting in the wild
In-Reply-To: <OFF2E3C99E.8CB0BD25-ON8525697A.0068BC37@com>
Message-ID: <Pine.LNX.4.20.0010181744400.10991-100000@tartarus.uwa.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

On Mon, 16 Oct 2000 pregen@egenconsulting.com wrote:

> I have been planning on setting up an iCalendar web site with just this 
> information.  I hope to have it up and running within a few weeks.  The 
> next IETF meeting is December in San Diego.
> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652

What does the CalSched working group need to achieve before then (for the
IETF meeting)?

Yours
Mark
-- 
Mark Tearle - mark@tearle.com                          "You howl and listen
                                                    Listen and wait for the
                                          Echoes of angels who won't return"



From owner-ietf-calendar@mail.imc.org  Wed Oct 18 08:48:29 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18196
	for <calsch-archive@odin.ietf.org>; Wed, 18 Oct 2000 08:48:28 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA07545
	for ietf-calendar-bks; Wed, 18 Oct 2000 05:23:40 -0700 (PDT)
Received: from boss.i.pipebeach.com ([195.7.94.163])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07534
	for <ietf-calendar@imc.org>; Wed, 18 Oct 2000 05:23:37 -0700 (PDT)
Received: from oxe.i.pipebeach.com ([172.17.47.10]) by boss.i.pipebeach.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35)
          with ESMTP id com for <ietf-calendar@imc.org>;
          Wed, 18 Oct 2000 14:28:15 +0200
Received: from gryner ([172.17.47.160]) by oxe.i.pipebeach.com
          (Post.Office MTA v3.1.2 release (PO205-101c)
          ID# 509-47733U100L2S100) with SMTP id AAA496
          for <ietf-calendar@imc.org>; Wed, 18 Oct 2000 14:28:14 +0200
Message-Id: <3.0.6.32.20001018142248.008ff0d0@oxe.i.pipebeach.com>
X-Sender: evco@oxe.i.pipebeach.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Wed, 18 Oct 2000 14:22:48 +0200
To: ietf-calendar@imc.org
From: eva.codina@pipebeach.com (Eva Codina Sanuy)
Subject: CAP and iCalendar ???
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Hi,

If I have understood. iCalendar describes the format for calendaring
information and CAP is an internet protocol to access a calendar store of
iCalendar objects from a Calendar user application.
So, if I want to implement a calendar application I need to implement the
iCalendar objects and I need to implement the CAP.
Do you know if is there any implementation of these ??
Thank you,

Eva



From owner-ietf-calendar@mail.imc.org  Wed Oct 18 12:06: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 MAA22673
	for <calsch-archive@odin.ietf.org>; Wed, 18 Oct 2000 12:06:04 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA12430
	for ietf-calendar-bks; Wed, 18 Oct 2000 08:00:23 -0700 (PDT)
Received: from intermezzo.helixcode.com (IDENT:root@bogie12.slip.yorku.ca [130.63.184.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12425
	for <ietf-calendar@imc.org>; Wed, 18 Oct 2000 08:00:20 -0700 (PDT)
Received: from helixcode.com (IDENT:jpr@localhost.localdomain [127.0.0.1])
	by intermezzo.helixcode.com (8.9.3/8.9.3) with ESMTP id LAA01173;
	Wed, 18 Oct 2000 11:05:33 -0400
Message-ID: <39EDBC3C.42F4F76A@helixcode.com>
Date: Wed, 18 Oct 2000 11:05:32 -0400
From: JP Rosevear <jpr@helixcode.com>
Organization: Helix Code
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Eva Codina Sanuy <eva.codina@pipebeach.com>
CC: ietf-calendar@imc.org
Subject: Re: CAP and iCalendar ???
References: <3.0.6.32.20001018142248.008ff0d0@oxe.i.pipebeach.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Eva Codina Sanuy wrote:
> 
> Hi,
> 
> If I have understood. iCalendar describes the format for calendaring
> information and CAP is an internet protocol to access a calendar store of
> iCalendar objects from a Calendar user application.
> So, if I want to implement a calendar application I need to implement the
> iCalendar objects and I need to implement the CAP.
> Do you know if is there any implementation of these ??

AFAIK you only need to implement CAP for shared calendaring.

As for iCal, I suggest you look at Eric Busboom's excellent libical
package. http://www.softwarestudio.org/libical/index.html

We are using in successfully in our GPL'ed software package Evolution.

-JP
--
=======================================================================
JP Rosevear				jpr@helixcode.com
Helix Code Inc.				http://www.helixcode.com


From owner-ietf-calendar@mail.imc.org  Wed Oct 18 12:06: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 MAA22693
	for <calsch-archive@odin.ietf.org>; Wed, 18 Oct 2000 12:06:10 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA12614
	for ietf-calendar-bks; Wed, 18 Oct 2000 08:07:03 -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 IAA12610
	for <ietf-calendar@imc.org>; Wed, 18 Oct 2000 08:07:02 -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 e9IF0Cs00893
	for <ietf-calendar@imc.org>; Wed, 18 Oct 2000 08:00:12 -0700 (PDT)
Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com
          (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with
          ESMTP id G2MSVG00.PKT; Wed, 18 Oct 2000 08:11:40 -0700 
Message-ID: <39EDBCFA.3A1F77BA@netscape.com>
Date: Wed, 18 Oct 2000 08:08:42 -0700
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Eva Codina Sanuy <eva.codina@pipebeach.com>
CC: ietf-calendar@imc.org
Subject: Re: CAP and iCalendar implementation
References: <3.0.6.32.20001018164327.008fed50@oxe.i.pipebeach.com>
Content-Type: multipart/mixed;
 boundary="------------720ED9CD2DA02F047D6C8523"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.
--------------720ED9CD2DA02F047D6C8523
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Eva,

CAP is still under development, so I doubt that anyone will have a CAP
implementation (it's still a moving target).  Several products do have support
for importing/exporting iCalendar information. There are even a few products
that have support for iTIP / iMIP -- an interoperability protocol that
describes how to publish, invite, and reply to meeting requests and tasks
using iCalendar objects. iPlanet's (Sun/Netscape) Calendar server supports a
large part of iTIP / iMIP. There were some messages on this mailing list
recently where vendors who support iCalendar/iTIP/iMIP mentioned their
products.

-Steve

Eva Codina Sanuy wrote:

> Hi ! I have some questions about implementation.
>
> As I understood iCalendar describe the format for representing calendaring
> information and CAP is an Internet protocol for accessing calendar stores
> of iCalendar objects.
> So, if I want to implement a calendar application, I need to implement the
> icalendar objects and the protocol.
>
> Does anyone know if is there any implementation of CAP and iCalendar
> objects already done ??
>
> Thank you very much.
>
> Eva

--------------720ED9CD2DA02F047D6C8523
Content-Type: text/x-vcard; charset=us-ascii;
 name="sman.vcf"
Content-Description: Card for Steve Mansour
Content-Disposition: attachment;
 filename="sman.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Mansour;Steve
tel;fax:650-937-2103
tel;work:650-937-2378
x-mozilla-html:FALSE
org:Netscape
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043;
x-mozilla-cpt:;-10552
fn:Steve Mansour
end:vcard

--------------720ED9CD2DA02F047D6C8523--



From owner-ietf-calendar@mail.imc.org  Wed Oct 18 12:06:13 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22703
	for <calsch-archive@odin.ietf.org>; Wed, 18 Oct 2000 12:06:12 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA11969
	for ietf-calendar-bks; Wed, 18 Oct 2000 07:44:17 -0700 (PDT)
Received: from boss.i.pipebeach.com ([195.7.94.163])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11964
	for <ietf-calendar@imc.org>; Wed, 18 Oct 2000 07:44:16 -0700 (PDT)
Received: from oxe.i.pipebeach.com ([172.17.47.10]) by boss.i.pipebeach.com
          (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35)
          with ESMTP id com for <ietf-calendar@imc.org>;
          Wed, 18 Oct 2000 16:48:54 +0200
Received: from gryner ([172.17.47.160]) by oxe.i.pipebeach.com
          (Post.Office MTA v3.1.2 release (PO205-101c)
          ID# 509-47733U100L2S100) with SMTP id AAA588
          for <ietf-calendar@imc.org>; Wed, 18 Oct 2000 16:48:54 +0200
Message-Id: <3.0.6.32.20001018164327.008fed50@oxe.i.pipebeach.com>
X-Sender: evco@oxe.i.pipebeach.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Wed, 18 Oct 2000 16:43:27 +0200
To: ietf-calendar@imc.org
From: eva.codina@pipebeach.com (Eva Codina Sanuy)
Subject: CAP and iCalendar implementation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Hi ! I have some questions about implementation.

As I understood iCalendar describe the format for representing calendaring
information and CAP is an Internet protocol for accessing calendar stores
of iCalendar objects.
So, if I want to implement a calendar application, I need to implement the
icalendar objects and the protocol.

Does anyone know if is there any implementation of CAP and iCalendar
objects already done ??

Thank you very much.

Eva



From owner-ietf-calendar@mail.imc.org  Wed Oct 18 12:06: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 MAA22713
	for <calsch-archive@odin.ietf.org>; Wed, 18 Oct 2000 12:06:13 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA12161
	for ietf-calendar-bks; Wed, 18 Oct 2000 07:50: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 HAA12156
	for <ietf-calendar@imc.org>; Wed, 18 Oct 2000 07:50:08 -0700 (PDT)
From: pregen@egenconsulting.com
To: Mark Tearle <mtearle@tearle.com>
Cc: ietf-calendar@imc.org
Subject: Re: iCal sighting in the wild
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: <OFA8369AAC.D11C4872-ON8525697C.0051CED7@com>
Date: Wed, 18 Oct 2000 08:55:16 -0600
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 10/18/2000 10:55:14 AM,
	Serialize complete at 10/18/2000 10:55:14 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005D089F8725697C_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 005D089F8725697C_=
Content-Type: text/plain; charset="us-ascii"

We plan to have another iteration of the Guide to Internet calendaring 
posted as well as updates to iCalendar and the next flavor of the CAP 
draft.  There has been activity recently on command tables that needed to 
be updated/added to CAP.  Also, we will talk about arrangements for the 
next CalConnect which is slated to occur in early 2001.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652




Mark Tearle <mtearle@tearle.com>
10/18/00 03:46 AM

 
        To:     pregen@egenconsulting.com
        cc:     ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
        Subject:        Re: iCal sighting in the wild

On Mon, 16 Oct 2000 pregen@egenconsulting.com wrote:

> I have been planning on setting up an iCalendar web site with just this 
> information.  I hope to have it up and running within a few weeks.  The 
> next IETF meeting is December in San Diego.
> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652

What does the CalSched working group need to achieve before then (for the
IETF meeting)?

Yours
Mark
-- 
Mark Tearle - mark@tearle.com                          "You howl and 
listen
                                                    Listen and wait for 
the
                                          Echoes of angels who won't 
return"




--=_alternative 005D089F8725697C_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">We plan to have another iteration of the Guide to Internet calendaring posted as well as updates to iCalendar and the next flavor of the CAP draft. &nbsp;There has been activity recently on command tables that needed to be updated/added to CAP. &nbsp;Also, we will talk about arrangements for the next CalConnect which is slated to occur in early 2001.<br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Mark Tearle &lt;mtearle@tearle.com&gt;</b></font>
<p><font size=1 face="sans-serif">10/18/00 03:46 AM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;pregen@egenconsulting.com</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: iCal sighting in the wild</font></table>
<br>
<br><font size=2><tt>On Mon, 16 Oct 2000 pregen@egenconsulting.com wrote:<br>
<br>
&gt; I have been planning on setting up an iCalendar web site with just this <br>
&gt; information. &nbsp;I hope to have it up and running within a few weeks. &nbsp;The <br>
&gt; next IETF meeting is December in San Diego.<br>
&gt; ___________________<br>
&gt; Patricia Egen Consulting<br>
&gt; www.egenconsulting.com<br>
&gt; 423-875-2652<br>
<br>
What does the CalSched working group need to achieve before then (for the<br>
IETF meeting)?<br>
<br>
Yours<br>
Mark<br>
-- <br>
Mark Tearle - mark@tearle.com &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;You howl and listen<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Listen and wait for the<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Echoes of angels who won't return&quot;<br>
<br>
</tt></font>
<br>
<br>
--=_alternative 005D089F8725697C_=--


From owner-ietf-calendar@mail.imc.org  Fri Oct 20 12:09: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 MAA07665
	for <calsch-archive@odin.ietf.org>; Fri, 20 Oct 2000 12:09:45 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19305
	for ietf-calendar-bks; Fri, 20 Oct 2000 08:41:35 -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 IAA19300
	for <ietf-calendar@imc.org>; Fri, 20 Oct 2000 08:41:33 -0700 (PDT)
From: pregen@egenconsulting.com
Subject: Agenda for CALSCH at IETF meeting - San Diego
To: ietf-calendar@imc.org
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: <OFD2B41D0B.9E0915E0-ON8525697E.00568E52@com>
Date: Fri, 20 Oct 2000 16:46:41 +0100
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 10/20/2000 11:46:53 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Here's the CALSCH  agenda for the San Diego IETF meeting.  Right now we are
possibly slated for a 2 hour session on Wednesday of the meeting week.

Agenda:

Agenda bashing

Guide to Interoperability draft update
 - inclusion of Timezone data
 - most recent changes
 - additional examples added

iCalendar updates (and iTIP,iRIP,iMIP if necessary)
 - Eric Busboom added as an Editor
 - Bruce Kahn added as Method Reviewer
 - changes (typos fixed, adjustments, etc)

CAP update
 - Command table work
 - Timezone efforts

Plans for Winter CalConnect
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652



From owner-ietf-calendar@mail.imc.org  Sun Oct 22 01:26:57 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03552
	for <calsch-archive@odin.ietf.org>; Sun, 22 Oct 2000 01:26:57 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id WAA08839
	for ietf-calendar-bks; Sat, 21 Oct 2000 22:06:41 -0700 (PDT)
Received: from agony.busboom.org (24-25-196-57.san.rr.com [24.25.196.57])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA08835
	for <ietf-calendar@imc.org>; Sat, 21 Oct 2000 22:06:39 -0700 (PDT)
From: eric@softwarestudio.org
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id WAA17322
	for <ietf-calendar@imc.org>; Sat, 21 Oct 2000 22:12:06 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Sat, 21 Oct 2000 22:12:06 -0700 (PDT)
X-Sender: eric@agony.busboom.org
To: ietf-calendar@imc.org
Subject: Proposed Text for RFC2445 Issue #5
Message-ID: <Pine.LNX.4.21.0010212204140.16932-100000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>



RFC Issue #5 relates to multiple ATTENDEE properties with the same value
but with different parameters, ROLE in particular. 

Frank Dawson proposed changes to RFC2445 in: 
	
	http://www.imc.org/ietf-calendar/mail-archive/msg02423.html

He and Alex Taler discussed the issue, with Alex agreeing with Frank's
proposal at: 

	http://www.imc.org/ietf-calendar/mail-archive/msg02433.html

Does anyone else have input on this issue? If not, I will accept the text
as proposed and close the issue. If it makes you cranky, speak up in the
next two weeks. 

eric. 





From owner-ietf-calendar@mail.imc.org  Sun Oct 22 01: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 BAA04577
	for <calsch-archive@odin.ietf.org>; Sun, 22 Oct 2000 01:28:46 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id VAA08710
	for ietf-calendar-bks; Sat, 21 Oct 2000 21:58:41 -0700 (PDT)
Received: from agony.busboom.org (24-25-196-57.san.rr.com [24.25.196.57])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08706
	for <ietf-calendar@imc.org>; Sat, 21 Oct 2000 21:58:39 -0700 (PDT)
From: eric@softwarestudio.org
Received: from localhost (eric@localhost)
	by agony.busboom.org (8.9.3/8.9.3) with ESMTP id WAA17309
	for <ietf-calendar@imc.org>; Sat, 21 Oct 2000 22:04:06 -0700
X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs
Date: Sat, 21 Oct 2000 22:04:06 -0700 (PDT)
X-Sender: eric@agony.busboom.org
To: ietf-calendar@imc.org
Subject: RFC 2445 Issues List 
Message-ID: <Pine.LNX.4.21.0010212152530.16932-200000@agony.busboom.org>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1463809014-915389563-972190397=:16932"
Content-ID: <Pine.LNX.4.21.0010212154350.16932@agony.busboom.org>
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=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-915389563-972190397=:16932
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0010212154351.16932@agony.busboom.org>


The latest version of the RFC2445 Issues list is available online at: 

	http://softwarestudio.org/iCal/2445Issues.html

An abbreviated version is also attached to this message. 

This list is being kept to track errors and omissions to RFC2445. Please
review the list, and contribute to it by responding to the mail I send out
regarding the issues. If the issue is not listed as a typo, we need your
input to close it out. 

eric. 

---1463809014-915389563-972190397=:16932
Content-Type: TEXT/PLAIN; NAME="Issues.txt"
Content-ID: <Pine.LNX.4.21.0010212153170.16932@agony.busboom.org>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME="Issues.txt"
Content-Transfer-Encoding: BASE64

UkZDMjQ0NSBJc3N1ZXMgTGlzdA0KDQpUaGlzIGlzIGEgc3VtbWFyeSB2ZXJz
aW9uIG9mIHRoZSBSRkMyNDQ1IGlzc3VlcyBsaXN0LiBQbGVhc2Ugc2VlIHRo
ZQ0KaHRtbCB2ZXJzaW9uICggZmlsZTovLy9ob21lL2VyaWMvZG9jdW1lbnRz
L2lDYWwvSXNzdWVzLmh0bWwgKSBmb3INCmNvbXBsZXRlIGRldGFpbHMuDQoN
Cg0KMCAgRGlzcG9zaXRpb24gVHlwZSAgIFN1bW1hcnkNCjEgIFJlamVjdGVk
IElDUiAgICBTcGVjaWZ5IEZpbGUgbmFtZSBpbiBBVFRBQ0g/DQoyICBSZWpl
Y3RlZCBJQ1IgICAgQllEQVkgdGVybWlub2xvZ3kgaXMgQ29uZnVzaW5nLiAN
CjMgIERpc2N1c3MgIEVSUiAgICBEQVRFIERUU1RBUlQgYW5kIFJFQ1VSUkVO
Q0UtSUQNCjQgIE9wZW4gICAgIFR5cG8gICBPcmRlcmluZyBvZiBQYXJhbWV0
ZXJzIGluIEFCTkYNCjUgIERpc2N1c3MgIEVSUiAgICBNdWx0aXBsZSBBVFRF
TkRFRSB3aXRoIFNhbWUgVmFsdWUNCjYgIE9wZW4gICAgIElDUiAgICBNaXhl
ZCBEQVRFIGFuZCBEQVRFLVRJTUUNCjcgIE9wZW4gICAgIElDUiAgICBJbmNv
bnNpc3RlbmNleSBpbiBVSUQgcHJvcA0KOCAgUmVqZWN0ZWQgSUNSICAgIFNw
ZWNpZnkgRmlsZSBuYW1lIGluIEFUVEFDSD8NCjkgIE9wZW4gICAgIEVSUiAg
ICBXZWVrbnVtYmVyIGluZGVwZW5kZW50IG9mIHN0YXJ0IG9mIHdlZWs/DQox
MCBPcGVuICAgICBUeXBvICAgQ29uZmxpY3QgaW4gTXVsdGlwbGUgb2NjdXJy
ZW5jZSBvZiBERVNDUklQVElPTg0KMTEgT3BlbiAgICAgVHlwbyAgIE5lZWQg
Q1JMRiBpbiBUUklHR0VSIHNwZWMNCjEyIE9wZW4gICAgIFR5cG8gICBUeXBv
IGluIDQuOC4xLjcNCjEzIE9wZW4gICAgIEVSUiAgICBQVUJMSVNIICYgTm8g
T3JnYW5pemVyIGluIE5vbi1ncm91cCBzY2hlZHVsZWQNCgkJICAgbWVldGlu
Z3MNCjE0IE9wZW4gICAgIFR5cG8gICBGaXggZXJyb3JzIGluIGV4YW1wbGVz
DQoxNSBEaXNjdXNzICBJQ1IgICAgUmVzdHJpY3Rpb25zIG9uIFJFQ1VSIHJ1
bGVzDQoxNiBPcGVuICAgICBSZWplY3RlZCAgV2h5IGlzIFVOVElMIG9ubHkg
VVRDPw0KMTcgT3BlbiAgICAgQ1IgICAgIENoYW5nZXMgdG8gUkVRVUVTVC1T
VEFUVVMNCjE4IE9wZW4gICAgIENSICAgICBOZXcgVFJBTlNQIFZhbHVlcyBm
b3IgQ0FQDQoxOSBPcGVuICAgICBDUiAgICAgTmV3IEdFT19CT1VORFMgcHJv
cGVydHkNCjIwIE9wZW4gICAgIENSICAgICBBZGQgTmV3IENBUCBjb21wb25l
bnRzIHRvIHNwZWMNCjIxIE9wZW4gICAgIFR5cG8gICA0LjIuMTggIFNlbnQg
QnkgZXhhbXBsZTogdXNlID0gaW5zdGVhZCBvZiA6DQoyMiBPcGVuICAgICBJ
Q1IgICAgIEFCTkYgZG9lc24ndCBjdXJyZW50bHkgYWxsb3cgcmVnaXN0ZXJl
ZCBleHRlbnNpb25zDQoyMyBPcGVuICAgICBJQ1IgICAgRGlzYWxsb3cgUkVD
VVJSRU5DRS1JRCBvZiBEQVRFIGZvciA+MSBvY2N1cmVuY2VzIHBlcg0KCQkg
ICBkYXkNCjI0IE9wZW4gICAgIFR5cG8gICBQYWdlIDE0LCBzZWN0aW9uIDQu
MSwgeC10b2tlbiB0byB4LW5hbWUNCjI1IE9wZW4gICAgIFR5cG8gICBQYWdl
IDIxLCBzZWN0aW9uIDQuMi40LCB1c2VzIHRvIHVzZXJzDQoyNiBPcGVuICAg
ICBUeXBvICAgUGFnZSAyMiwgc2VjdGlvbiA0LjIuNiwgdmFsdWVzIHRvIHZh
bHVlDQoyNyBPcGVuICAgICBUeXBvICAgUGFnZSAyMiwgc2VjdGlvbiA0LjIu
NiwgTVVTVCBlYWNoIGJlIHNwZWNpZmllZCB0bw0KCQkgICBNVVNUIGJlIHNw
ZWNpZmllZA0KMjggT3BlbiAgICAgVHlwbyAgIFBhZ2UgMjIsIHNlY3Rpb24g
NC4yLjYsIFRoZSBpbmRpdmlkdWFsIFVSSSB0byBUaGUNCgkJICAgVVJJDQoy
OSBPcGVuICAgICBUeXBvICAgUGFnZSA0NSwgc2VjdGlvbiA0LjMuMTEsIEVT
Q0FQRUQtQ0hBUiA9ICB0bw0KCQkgICBFU0NBUEVELUNIQVIgPSAoDQozMCBP
cGVuICAgICBUeXBvICAgUGFnZSA0Niwgc2VjdGlvbiA0LjMuMTEsIC8gJXgz
Qy01QiB0byAvICV4M0MtNUIgLw0KMzEgT3BlbiAgICAgVHlwbyAgIFBhZ2Ug
NTIsIHNlY3Rpb24gNC42LCBmcmVlYnVzeWMgLyB0byBmcmVlYnVzeWMNCjMy
IE9wZW4gICAgIFR5cG8gICBQYWdlIDg0LCBzZWN0aW9uIDQuOC4xLjcsIEYx
MjMsIHRvIEYxMjNcLA0KMzMgT3BlbiAgICAgVHlwbyAgIFBhZ2UgODgsIHNl
Y3Rpb24gNC44LjEuMTEsIHN0YXRwYXJhbV0gdG8gc3RhdHBhcmFtDQozNCBP
cGVuICAgICBUeXBvICAgUGFnZSAxMTAsIHNlY3Rpb24gNC44LjQuNSwgY2Fu
Y2VsZWQgdG8gY2FuY2VsbGVkIGZvcg0KCQkgICBjb25zaXN0ZW5jeQ0KMzUg
T3BlbiAgICAgVHlwbyAgIFBhZ2UgMTEwLCBzZWN0aW9uIDQuOC40LjUsIFty
ZWxwYXJhbV0gdG8gcmVscGFyYW0NCjM2IE9wZW4gICAgIFR5cG8gICBQYWdl
IDExMCwgc2VjdGlvbiA0LjguNC41LCB4cGFybSB0byB4cGFyYW0NCjM3IE9w
ZW4gICAgIFR5cG8gICBQYWdlIDEyOCwgc2VjdGlvbiA0LjguNi4zLCAvIHRy
aWdhYnMpIHRvIC8gdHJpZ2FicykNCgkJICAgQ1JMRg0KMzggT3BlbiAgICAg
VHlwbyAgIFBhZ2UgMTM4LCBzZWN0aW9uIDUsIHRleHQvY2FsZW5kYXIgdG8N
CgkJICAgdGV4dC9jYWxlbmRhcjtNRVRIT0Q9eHl6O0NPTVBPTkVOVA0KCQkg
ICA9VkVWRU5UDQozOSBPcGVuICAgICBUeXBvICAgUGFnZSAxMzgsIHNlY3Rp
b24gNSwgVFJJR0dFUjoxOTk4MDQwM1QxMjAwMDAgdG8NCgkJICAgVFJJR0dF
UjoxOTk4MDQwM1QxMjAwMDBaDQo0MCBPcGVuICAgICBUeXBvICAgUGFnZSAx
NDMsIHNlY3Rpb24gNy4yLjQsIC4uaXMgYXBwb2ludGVkIHRvIHRoZS4uIHRv
DQoJCSAgIC4uaXMgYXBwb2ludGVkIGJ5IHRoZS4uDQo0MSBPcGVuICAgICBU
eXBvICAgQWRqdXN0IEFCTkYgdG8gYWNjb21tb2RhdGUgZXh0ZW5zaW9uDQo0
MiBPcGVuICAgICBUeXBvICAgVHlwb3MgaW4gZXhhbXBsZXMNCg==
---1463809014-915389563-972190397=:16932--


From owner-ietf-calendar@mail.imc.org  Sun Oct 22 03:27:29 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04624
	for <calsch-archive@odin.ietf.org>; Sun, 22 Oct 2000 03:27:28 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA11303
	for ietf-calendar-bks; Sat, 21 Oct 2000 23:54:39 -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 XAA11299
	for <ietf-calendar@imc.org>; Sat, 21 Oct 2000 23:54:37 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA28891
	for ietf-calendar@imc.org; Sun, 22 Oct 2000 00:00:03 -0700 (PDT)
Date: Sun, 22 Oct 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200010220700.AAA28891@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: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=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?					<variable>
      Can the server decide not to do this?	Y
  
 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 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  Thu Oct 26 13:12: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 NAA24841
	for <calsch-archive@odin.ietf.org>; Thu, 26 Oct 2000 13:12:05 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA05963
	for ietf-calendar-bks; Thu, 26 Oct 2000 09:46:56 -0700 (PDT)
Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05958
	for <ietf-calendar@imc.org>; Thu, 26 Oct 2000 09:46:49 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: Agenda for San Diego meeting
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFF30E014D.B2982294-ON85256984.005C9CD7@egenconsulting.com>
Date: Thu, 26 Oct 2000 17:52:27 +0100
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September
 22, 2000) at 10/26/2000 12:52:45 PM,
	Serialize complete at 10/26/2000 12:52:45 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00414CD680256984_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 00414CD680256984_=
Content-Type: text/plain; charset="us-ascii"

Here's is our scheduled day and time for CALSCH in San Diego.

WEDNESDAY, December 13, 2000
0900-1130 Morning Sessions

APP     calsch          Calendaring and Scheduling WG

___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
--=_alternative 00414CD680256984_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Here's is our scheduled day and time for CALSCH in San Diego.</font>
<br>
<br><font size=2><tt>WEDNESDAY, December 13, 2000<br>
0900-1130 Morning Sessions<br>
<br>
APP &nbsp; &nbsp; calsch &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Calendaring and Scheduling WG<br>
</tt></font><font size=2 face="sans-serif"><br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
--=_alternative 00414CD680256984_=--


From owner-ietf-calendar@mail.imc.org  Fri Oct 27 12:10:22 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12148
	for <calsch-archive@odin.ietf.org>; Fri, 27 Oct 2000 12:10:22 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16534
	for ietf-calendar-bks; Fri, 27 Oct 2000 08:43:15 -0700 (PDT)
Received: from jupiter.wwweiss.de (jupiter.wwweiss.de [194.25.217.99])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16530
	for <ietf-calendar@imc.org>; Fri, 27 Oct 2000 08:43:11 -0700 (PDT)
Received: from ra.ibn.de [62.227.160.218] by wwweiss.de [194.25.217.98]
	with SMTP (MDaemon.v3.0.3.R)
	for <ietf-calendar@imc.org>; Fri, 27 Oct 2000 17:48:52 +0200
Received: from ibn.de (root@ra.ibn.de [192.168.5.100])
	by ra.ibn.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA16920
	for <ietf-calendar@imc.org>; Fri, 27 Oct 2000 17:42:42 +0200
Message-ID: <39F9A272.5E169257@ibn.de>
Date: Fri, 27 Oct 2000 17:42:42 +0200
From: Martin Neimeier <nei@ibn.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF-Calendar-Mailinglist <ietf-calendar@imc.org>
Subject: Questions
Content-Type: multipart/mixed;
 boundary="------------25330FBEBDAE6C9A4DBE32D6"
X-MDaemon-Deliver-To: ietf-calendar@imc.org
X-Return-Path: nei@ibn.de
X-MDRcpt-To: ietf-calendar@imc.org
X-MDRemoteIP: 62.227.160.218
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.
--------------25330FBEBDAE6C9A4DBE32D6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

while developing a calendar-store with a CAP-Interface for korganizer, 
i found the following questions:

1. Are VTIMEZONE-components bound to specific calendar or to the calendar-store ?

2. Which VTIMEZONE-components must exist on bootstrap, I found only one: GMT, more ?

3. Whats the meaning of the properties maxresults and maxresultsize of a VQUERY-component ?
   If they are real Properties of VQUERY-component the chapter 5.1.1 should be changed as follows 
   to keep consistent.

   search	    = "BEGIN:VQUERY" CRLF
		       [expand]	[maxresults] [maxsize] querycomp
		       "END:VQUERY" CRLF

   expand	    = "EXPAND" ":" ( "TRUE" / "FALSE")
		      #	If not specified, the default is EXPAND:FALSE .

   comp-name	    = "VEVENT" / "VTODO" / "VJOURNAL" /	"VTIMEZONE"
		      /	"VALARM" / "VFREEBUSY" / "VCAR"	/ iana-name / x-name

>>>   maxresults    = "MAXRESULTS" ":" integer
>>>                   #If not specified, the default is unlimited result-sets          
>>>   maxsize	    = "MAXRESULTSIZE" ":" integer
>>>                   #if not specified, the default is unlimited result-size

4. What properties are allowed for a VCOMMAND-component ? 
   I found the properties CMDID and TARGET ? Are there more ?
   
5. Which Component-Types can be neested in a VCOMMAND-component ?
   I found only VCalendar-components. More ?
   

cu
Martin Neimeier

-- 
UNIX was never designed to keep people from doing stupid things, because
that policy would also keep them from doing clever things.   (Doug Gwyn)
--
Martin Neimeier / Ingenieur-Buero Neimeier / Schwarzach / Germany
mailto:nei@ibn.de / http://www.ibn.de (under heavy reconstruction) / Tel:+49(6262)912344 /
Fax:+49(6262)912347
--------------25330FBEBDAE6C9A4DBE32D6
Content-Type: text/x-vcard; charset=us-ascii;
 name="nei.vcf"
Content-Description: Card for Martin Neimeier
Content-Disposition: attachment;
 filename="nei.vcf"
X-MIME-Autoconverted: from 8bit to quoted-printable by ra.ibn.de id RAA16920
Content-Transfer-Encoding: quoted-printable

begin:vcard=20
n:Neimeier;Martin
tel;cell:+49 (172) 7445912
tel;fax:+49 (6262) 912347
tel;work:+49 (6262) 912344
x-mozilla-html:FALSE
org:Ingenieur-B=FCro Neimeier
adr:;;Vogelsang 3;Schwarzach;BW;74869;Germany
version:2.1
email;internet:nei@ibn.de
x-mozilla-cpt:;0
fn:Martin Neimeier
end:vcard

--------------25330FBEBDAE6C9A4DBE32D6--




From owner-ietf-calendar@mail.imc.org  Sun Oct 29 02:27:05 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 CAA07485
	for <calsch-archive@odin.ietf.org>; Sun, 29 Oct 2000 02:27:04 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA19739
	for ietf-calendar-bks; Sat, 28 Oct 2000 23:54:13 -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 XAA19728
	for <ietf-calendar@imc.org>; Sat, 28 Oct 2000 23:54:11 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA05858
	for ietf-calendar@imc.org; Sun, 29 Oct 2000 00:00:03 -0700 (PDT)
Date: Sun, 29 Oct 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200010290700.AAA05858@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: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=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?					<variable>
      Can the server decide not to do this?	Y
  
 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 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 Oct 30 07:40: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 HAA05466
	for <calsch-archive@odin.ietf.org>; Mon, 30 Oct 2000 07:40:08 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA26448
	for ietf-calendar-bks; Mon, 30 Oct 2000 04:15:45 -0800 (PST)
Received: from jupiter.wwweiss.de (jupiter.wwweiss.de [194.25.217.99])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26440
	for <ietf-calendar@imc.org>; Mon, 30 Oct 2000 04:15:43 -0800 (PST)
Received: from ra.ibn.de [193.159.4.238] by wwweiss.de [194.25.217.98]
	with SMTP (MDaemon.v3.0.3.R)
	for <ietf-calendar@imc.org>; Mon, 30 Oct 2000 13:21:37 +0100
Received: from ibn.de (root@ra.ibn.de [192.168.5.100])
	by ra.ibn.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA26038
	for <ietf-calendar@imc.org>; Mon, 30 Oct 2000 13:16:56 +0100
Message-ID: <39FD66B8.54879DB8@ibn.de>
Date: Mon, 30 Oct 2000 13:16:56 +0100
From: Martin Neimeier <nei@ibn.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF-Calendar-Mailinglist <ietf-calendar@imc.org>
Subject: VALARMs and VEVENTs ?
Content-Type: multipart/mixed;
 boundary="------------D0346D877D6CE1F316E1EC29"
X-MDaemon-Deliver-To: ietf-calendar@imc.org
X-Return-Path: nei@ibn.de
X-MDRcpt-To: ietf-calendar@imc.org
X-MDRemoteIP: 193.159.4.238
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.
--------------D0346D877D6CE1F316E1EC29
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

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

Sample:

BEGIN:VEVENT
DTSTART;VALUE=DATE:20001212
SUMMARY:Birthday of paul
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;RELATIVE=START;VALUE=DURATION:-PT5H
END:VALARM
END:VEVENT

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

cu
Martin
-- 
UNIX was never designed to keep people from doing stupid things, because
that policy would also keep them from doing clever things.   (Doug Gwyn)
--
Martin Neimeier / Ingenieur-Buero Neimeier / Schwarzach / Germany
mailto:nei@ibn.de / http://www.ibn.de (under heavy reconstruction) / Tel:+49(6262)912344 /
Fax:+49(6262)912347
--------------D0346D877D6CE1F316E1EC29
Content-Type: text/x-vcard; charset=us-ascii;
 name="nei.vcf"
Content-Description: Card for Martin Neimeier
Content-Disposition: attachment;
 filename="nei.vcf"
X-MIME-Autoconverted: from 8bit to quoted-printable by ra.ibn.de id NAA26038
Content-Transfer-Encoding: quoted-printable

begin:vcard=20
n:Neimeier;Martin
tel;cell:+49 (172) 7445912
tel;fax:+49 (6262) 912347
tel;work:+49 (6262) 912344
x-mozilla-html:FALSE
org:Ingenieur-B=FCro Neimeier
adr:;;Vogelsang 3;Schwarzach;BW;74869;Germany
version:2.1
email;internet:nei@ibn.de
x-mozilla-cpt:;0
fn:Martin Neimeier
end:vcard

--------------D0346D877D6CE1F316E1EC29--




From owner-ietf-calendar@mail.imc.org  Tue Oct 31 11:18: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 LAA01508
	for <calsch-archive@odin.ietf.org>; Tue, 31 Oct 2000 11:18:27 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA07948
	for ietf-calendar-bks; Tue, 31 Oct 2000 07:52:19 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07939
	for <ietf-calendar@imc.org>; Tue, 31 Oct 2000 07:52:15 -0800 (PST)
From: Bruce_Kahn@iris.com
To: ietf-calendar@imc.org
Subject: RFC 2446 Example errors
X-Mailer: Lotus Notes Build V60_10292000 October 29, 2000
Message-ID: <OFDA87044A.7C3E5082-ON85256989.00574887@iris.com>
Date: Tue, 31 Oct 2000 10:58:12 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at
 10/31/2000 11:03:51 AM,
	Serialize complete at 10/31/2000 11:03:51 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0057E9D385256989_="
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 0057E9D385256989_=
Content-Type: text/plain; charset="us-ascii"

While re-re-reading the RFCs for some examples to show folks I noticed 
that the iTIP examples are munged in some cases.  I found the examples ~pp 
85/86 read in part:


   RDATE:19980311T160000Z
   RDATE:19980315T180000Z
   Error! Bookmark not defined.
   ORGANIZER:Mailto:A@example.com
[Snip]
   END:VEVENT

   BEGIN:VEVENT
   Error! Bookmark not defined.
   SEQUENCE:2
   RECURRENCE-ID:19980311T160000Z
   Error! Bookmark not defined.
   ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined.
   ATTENDEE;Error! Bookmark not defined.
   SUMMARY:Review Accounts

Im assuming these got munged in some kind of .DOC -> .TXT conversion or 
export that the original authors did (and we all missed 'em during last 
call).  Will the current RFC 2446 Errata maintainer / updater please put 
this on the list of corrections...

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 0057E9D385256989_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">While re-re-reading the RFCs for some examples to show folks I noticed that the iTIP examples are munged in some cases. &nbsp;I found the examples ~pp 85/86 read in part:</font>
<br>
<br>
<br><font size=2><tt>&nbsp; &nbsp;RDATE:19980311T160000Z<br>
 &nbsp; RDATE:19980315T180000Z<br>
<b> &nbsp; Error! Bookmark not defined.</b><br>
 &nbsp; ORGANIZER:Mailto:A@example.com<br>
[Snip]</tt></font>
<br><font size=2><tt>&nbsp; &nbsp;END:VEVENT<br>
<br>
 &nbsp; BEGIN:VEVENT<br>
<b> &nbsp; Error! Bookmark not defined.</b><br>
 &nbsp; SEQUENCE:2<br>
 &nbsp; RECURRENCE-ID:19980311T160000Z<br>
<b> &nbsp; Error! Bookmark not defined.</b><br>
<b> &nbsp; ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined.<br>
 &nbsp; ATTENDEE;Error! Bookmark not defined.</b><br>
 &nbsp; SUMMARY:Review Accounts</tt></font>
<br>
<br><font size=2 face="sans-serif">Im assuming these got munged in some kind of .DOC -&gt; .TXT conversion or export that the original authors did (and we all missed 'em during last call). &nbsp;Will the current RFC 2446 Errata maintainer / updater please put this on the list of corrections...</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">===========================================================================<br>
Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br>
Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br>
Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br>
Standard disclaimers apply, even where prohibited by law...</font>
--=_alternative 0057E9D385256989_=--


From owner-ietf-calendar@mail.imc.org  Tue Oct 31 11:55: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 LAA15053
	for <calsch-archive@odin.ietf.org>; Tue, 31 Oct 2000 11:55:54 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA11589
	for ietf-calendar-bks; Tue, 31 Oct 2000 08:31:14 -0800 (PST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11565
	for <ietf-calendar@imc.org>; Tue, 31 Oct 2000 08:31:08 -0800 (PST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.10.0/8.10.0) with ESMTP id e9VGP0s08904
	for <ietf-calendar@imc.org>; Tue, 31 Oct 2000 08:25:00 -0800 (PST)
Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com
          (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with
          ESMTP id G3AZHG00.80B; Tue, 31 Oct 2000 08:36:52 -0800 
Message-ID: <39FEF681.1F12E87B@netscape.com>
Date: Tue, 31 Oct 2000 08:42:41 -0800
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: iTIP updates
Content-Type: multipart/mixed;
 boundary="------------C9C11DCE33595D05B5ED4E04"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.
--------------C9C11DCE33595D05B5ED4E04
Content-Type: multipart/alternative;
 boundary="------------C1C6D1F0926AB2E1E15C978B"


--------------C1C6D1F0926AB2E1E15C978B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All,

Here are the list of iTIP updates.  Somebody made a suggestion for #2
(I think it was George Babics) about an additional use for the
ATTCOUNTER parameter -- there was some other situation where we needed
to determine who was doing an action -- I think it had to do with
delegation.  But I didn't add it to this list. Whoever it was please
reply so we can review it and put it in if it makes sense.

Also, if you are aware of any other problems in iTIP/iMIP, now is a real
good time to send them to the group or to me.  I'll have an updated
draft submitted in time for the San Diego meeting.

-Steve
  ------------------------------------------------------------------------

1. Overloading iTIP REQUEST:

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

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

2. Identify sender of iTIP COUNTER:

     Problem: You can't identify which Attendee a COUNTER message
     came from because all of the Attendees will appear in the
     component.

     Proposal 1: Restrict the COUNTER message so that it can only
     specify the ORGANIZER and countering ATTENDEE.

     Note: You can still forward (party crashing, remember? :-) or
     delegate a REQUEST to change participants. However, only the
     ORGANIZER can remove a participant. The down side to this
     approach is that you can't change the Attendees. This removes
     functionality. The up side is that it requires no changes to
     iCalendar.

     Proposal 2: Add a new parameter to the ATTENDEE property:
     ATTCOUNTER. It can only be specified (a) when the component
     method is COUNTER and (b) for the one Attendee who issued the
     COUNTER.

     Note: The good news is that no functionality is lost -- you
     can suggest a different attendee list. The down side is that
     we have to update iCalendar with a new parameter.

     The group concensus for solving this problem is Proposal 2.

3. Adding/deleting ATTENDEEs

     Problem: If the Organizer adds or deletes an ATTENDEE, do they
     really have to send the reschedule to all of the other
     ATTENDEEs? The iTIP specification is not clear on this point.

     Proposal: No, the Organizer can send the REQUEST w/the new
     ATTENDEE info to just the new ATTENDEE. It is up to the CUA.
     It is an implementation dependent issue if the SEQUENCE number
     needs to be incremented when you add/delete an ATTENDEE.
     iCalendar does not require an updated SEQUENCE number if a new
     ATTENDEE is added so this won't break iCalendar as it stands
     today.

4. Intolerant iMIP receivers.

     Problem: MIP specifies numerous MIME encapsulations for
     iCal/iTIP msgs. It doesn't require that an implementation MUST
     be able to receive each of them. This is leading to interop
     problems.

     Proposal: A conforming iMIP implementation MUST be able to
     receive each of the MIME encapsulations shown in the iMIP
     examples. It does not have to GENERATE them, but it must be
     able to RECEIVE them.

5. Garbage Text

     Problem:  The text "Error! Bookmark not defined." was found as
     a standalone line in a couple of the examples.

     Proposal:  Remove these lines.

--------------C1C6D1F0926AB2E1E15C978B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi All,
<p>Here are the list of iTIP updates.&nbsp; Somebody made a suggestion
for #2&nbsp; (I think it was George Babics) about an additional use for
the ATTCOUNTER parameter -- there was some other situation where we needed
to determine who was doing an action -- I think it had to do with delegation.&nbsp;
But I didn't add it to this list. Whoever it was please reply so we can
review it and put it in if it makes sense.
<p>Also, if you are aware of any other problems in iTIP/iMIP, now is a
real good time to send them to the group or to me.&nbsp; I'll have an updated
draft submitted in time for the San Diego meeting.
<p>-Steve
<br>
<hr WIDTH="100%">
<p>1. Overloading iTIP REQUEST:
<blockquote>Problem: Currently, the REQUEST method is used for invite,
reschedule, update, confirm, reply to refresh. A reschedule and/or update
are semantically different than a confirm or a reply to REFRESH.
<p>Proposal: Add a new method: CONFIRM. It would be used to (a) reply to
a REFRESH and (b) notify participants of any changes to ATTENDEE or ORGANIZER.
All other "reschedule" or "update" changes MUST use REQUEST method.</blockquote>

<p><br>2. Identify sender of iTIP COUNTER:
<blockquote>Problem: You can't identify which Attendee a COUNTER message
came from because all of the Attendees will appear in the component.
<p>Proposal 1: Restrict the COUNTER message so that it can only specify
the ORGANIZER and countering ATTENDEE.
<p>Note: You can still forward (party crashing, remember? :-) or delegate
a REQUEST to change participants. However, only the ORGANIZER can remove
a participant. The down side to this approach is that you can't change
the Attendees. This removes functionality. The up side is that it requires
no changes to iCalendar.
<p>Proposal 2: Add a new parameter to the ATTENDEE property: ATTCOUNTER.
It can only be specified (a) when the component method is COUNTER and (b)
for the one Attendee who issued the COUNTER.
<p>Note: The good news is that no functionality is lost -- you can suggest
a different attendee list. The down side is that we have to update iCalendar
with a new parameter.
<p>The group concensus for solving this problem is Proposal 2.</blockquote>

<p><br>3. Adding/deleting ATTENDEEs
<blockquote>Problem: If the Organizer adds or deletes an ATTENDEE, do they
really have to send the reschedule to all of the other ATTENDEEs? The iTIP
specification is not clear on this point.
<p>Proposal: No, the Organizer can send the REQUEST w/the new ATTENDEE
info to just the new ATTENDEE. It is up to the CUA. It is an implementation
dependent issue if the SEQUENCE number needs to be incremented when you
add/delete an ATTENDEE. iCalendar does not require an updated SEQUENCE
number if a new ATTENDEE is added so this won't break iCalendar as it stands
today.</blockquote>

<p><br>4. Intolerant iMIP receivers.
<blockquote>Problem: MIP specifies numerous MIME encapsulations for iCal/iTIP
msgs. It doesn't require that an implementation MUST be able to receive
each of them. This is leading to interop problems.
<p>Proposal: A conforming iMIP implementation MUST be able to receive each
of the MIME encapsulations shown in the iMIP examples. It does not have
to GENERATE them, but it must be able to RECEIVE them.</blockquote>
5. Garbage Text
<blockquote>Problem:&nbsp; The text "Error! Bookmark not defined." was
found as a standalone line in a couple of the examples.
<p>Proposal:&nbsp; Remove these lines.</blockquote>
</html>

--------------C1C6D1F0926AB2E1E15C978B--

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

--------------C9C11DCE33595D05B5ED4E04--



From owner-ietf-calendar@mail.imc.org  Tue Oct 31 12:36: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 MAA01397
	for <calsch-archive@odin.ietf.org>; Tue, 31 Oct 2000 12:36:37 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA15408
	for ietf-calendar-bks; Tue, 31 Oct 2000 09:04:06 -0800 (PST)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA15404
	for <ietf-calendar@imc.org>; Tue, 31 Oct 2000 09:04:04 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA22779; Tue, 31 Oct 00 12:11:18 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id MAA19748;
	Tue, 31 Oct 2000 12:10:12 -0500 (EST)
Received: from [18.18.1.172] (MAUI.MIT.EDU [18.18.1.172])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id MAA00711;
	Tue, 31 Oct 2000 12:10:11 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p04320402b624ac87e489@[18.18.1.172]>
In-Reply-To: <OFDA87044A.7C3E5082-ON85256989.00574887@iris.com>
References: <OFDA87044A.7C3E5082-ON85256989.00574887@iris.com>
Date: Tue, 31 Oct 2000 12:10:03 -0500
To: Bruce_Kahn@iris.com
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: RFC 2446 Example errors
Cc: ietf-calendar@imc.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

At 10:58 AM -0500 10/31/00, Bruce_Kahn@iris.com wrote:
>While re-re-reading the RFCs for some examples to show folks I 
>noticed that the iTIP examples are munged in some cases.  I found 
>the examples ~pp 85/86 read in part:

Bruce's note reminds me that several folks were going to send me 
sample iCal objects that they had used in testing, for inclusion in 
the Guide document.

So far, I don't have any examples...  :-)

I'm sure someone out there is doing development, and pushing objects 
at code they've written.  Please send me sample objects if this 
includes you.  I *promise* to remove any individual or 
vendor-specific references.

Thanks!

-Bob