From owner-ietf-calendar@mail.imc.org  Sun Jul  2 03:25:48 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02983
	for <calsch-archive@odin.ietf.org>; Sun, 2 Jul 2000 03:25:48 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA29323
	for ietf-calendar-bks; Sat, 1 Jul 2000 23:59: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 XAA29319
	for <ietf-calendar@imc.org>; Sat, 1 Jul 2000 23:59:11 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA01783
	for ietf-calendar@imc.org; Sun, 2 Jul 2000 00:00:04 -0700 (PDT)
Date: Sun, 2 Jul 2000 00:00:04 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200007020700.AAA01783@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 CAP draft editors:
 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------
	
 C-1 Remove unused definitions				N

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

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

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

 C-13 Post CAP-00.txt					Y

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

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

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

 The following are a list of action items for the iCalendar-2 draft:

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

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

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

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

 I-4 Add ALARMID to VALARM ?			Y

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


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

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



From owner-ietf-calendar@mail.imc.org  Tue Jul  4 17:01:05 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00790
	for <calsch-archive@odin.ietf.org>; Tue, 4 Jul 2000 17:01:04 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA26847
	for ietf-calendar-bks; Tue, 4 Jul 2000 13:41:54 -0700 (PDT)
Received: from mailsv.moanet.co.jp ([210.254.47.197])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26839;
	Tue, 4 Jul 2000 13:41:52 -0700 (PDT)
From: mx124796@nandomail.com
Received: from SMTP by mailsv.moanet.co.jp
 (AlliedTelesis SMTPRS 1.1 pl 0 ++620A188B5697644CD5C04FF59597D5F5) with SMTP id <B0000177253@mailsv.moanet.co.jp>;
 Wed, 5 Jul 2000 05:40:25 +0900
Received: from ns1.moanet.co.jp ([172.20.4.35]) by 172.20.4.37
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 05 Jul 2000 12:39:17 0000 (GMT)
Message-ID: <00001cd92351$00004f71$00001949@124>
To: <mx124796@nandomail.com>
Subject: Attention Homeowners: WE ARE FREE!
Date: Tue, 04 Jul 2000 15:11:53 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
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: quoted-printable

<HTML>

<head>
<title></title>
</head>

<body bgcolor=3D"#CCFFFF">

<FONT  COLOR=3D"#ff0000" SIZE=3D3 PTSIZE=3D10><B><U>Attention Homeowners: =
 WE ARE FREE!</FONT></B></U><FONT  COLOR=3D"#000000" SIZE=3D3 PTSIZE=3D10>=
<BR>
<BR>
</font><P ALIGN=3DCENTER><B><font ptsize=3D"10" color=3D"#0000FF" size=3D"=
6">Improve Your Lifestyle!</font></B>
</P><FONT  COLOR=3D"#000000" SIZE=3D3 PTSIZE=3D10><P ALIGN=3DLEFT>&nbsp;
</P><P ALIGN=3DLEFT>Dear Homeowner,<BR>
<BR>
      If you are in debt or need extra cash, we can help you get the money=
 you have been hoping for.<BR>
  Our services are <B>FREE</B> and we have already helped thousands of hom=
eowners, just like you.<BR>
<BR>
<BR>
<b>
Best Of All...</b> <BR>
</P><P ALIGN=3DCENTER></font><b><i><font ptsize=3D"10" color=3D"#0000FF" s=
ize=3D"3">
*Our lenders offer the Lowest Interest Rates available<BR>
*They can set you up with an incredibly low monthly payment!  <BR>
*We can provide you with Lenders who will loan you ...<BR>
<BR>
Up To 125% Of Your Home's Value!</font><FONT  COLOR=3D"#000000" SIZE=3D3 P=
TSIZE=3D10><BR>
</font></i></b>
</P><FONT  COLOR=3D"#000000" SIZE=3D3 PTSIZE=3D10><P ALIGN=3DCENTER><B><a =
HREF=3D"http://The-mortgage-guys.net@3626198025//nv/tec6278571#12121/mortg=
age/database/212112.212121.121114521.21/index.html">Click Here To Request =
Your FREE Quote!</a><BR>
</P></B><P ALIGN=3DCENTER>  And even better, there are <b> NO</b> Advances=
 or Upfront Fees of any kind!  <BR>
This means you won't pay a dime - so you have absolutely nothing to lose!
</P><P ALIGN=3DLEFT><BR>
     Here are just some of the ways you could put this cash to use:<BR>
<BR>
<b>
     -> Home Improvements<BR>
     -> Credit Card Debt<BR>
     -> College Tuition<BR>
     -> Dream Vacation<BR>
     -> A New Car<BR>
     -> Start Your Own Business<BR>
        ...or whatever else you need - it's up to YOU.</b>  <BR>
<BR>
</P><P ALIGN=3Dleft> So if you're serious about improving your current fin=
ancial position, you owe it to yourself to request your
<b>FREE</b>&nbsp;<BR>
Loan Evaluation. It's <b>FREE</b> and you've got nothing to lose.  Right n=
ow, while it's fresh in your mind, visit our site.
</P><P ALIGN=3DLEFT>&nbsp;
</P><P ALIGN=3DCENTER><B><a HREF=3D"http://The-mortgage-guys.net@362619802=
5//nv/tec6278571#12121/mortgage/database/212112.212121.121114521.21/index.=
html">Click Here To Request Your FREE Quote!</a></B><BR>
<BR>
 We take great pride in offering such prompt and quality service to you an=
d your family.<BR>
<BR>
Sincerely,<BR>
<i><b>
The Mortgage Guys</b></i><BR>
</P><P ALIGN=3DCENTER>&nbsp;
</P></font>
<p ALIGN=3D"left"><a href=3D"mailto:unsubscribe@1pop.fsnet.co.uk?subject=3D=
Unsubscribe">To
unsubscribe from our mailing list, please click here!</a></p>
</HTML>






From owner-ietf-calendar@mail.imc.org  Wed Jul  5 13:25:53 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12296
	for <calsch-archive@odin.ietf.org>; Wed, 5 Jul 2000 13:25:51 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA20891
	for ietf-calendar-bks; Wed, 5 Jul 2000 10:09:21 -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 KAA20883
	for <ietf-calendar@imc.org>; Wed, 5 Jul 2000 10:09:17 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Testing list address...
X-Mailer: Lotus Notes Build V60_06262000 June 26, 2000
Message-ID: <OF7A943875.8A41A88C-ON85256913.005E32F2@iris.com>
Date: Wed, 5 Jul 2000 13:13:25 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/05/2000
 01:10:42 PM,
	Serialize complete at 07/05/2000 01:10:42 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005E643485256913_="
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 005E643485256913_=
Content-Type: text/plain; charset="us-ascii"

I havent seen my posting from last week yet so Im checking to see if the 
list is pinging it back correctly.  Please ignore.

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


<br><font size=2 face="sans-serif">I havent seen my posting from last week yet so Im checking to see if the list is pinging it back correctly. &nbsp;Please ignore.</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 005E643485256913_=--


From owner-ietf-calendar@mail.imc.org  Wed Jul  5 18: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 ESMTP id SAA18252
	for <calsch-archive@odin.ietf.org>; Wed, 5 Jul 2000 18:52:57 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA00707
	for ietf-calendar-bks; Wed, 5 Jul 2000 15:35:44 -0700 (PDT)
Received: from localhost.localdomain (guanabana.helixcode.com [140.239.238.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00698
	for <ietf-calendar@imc.org>; Wed, 5 Jul 2000 15:35:41 -0700 (PDT)
Received: (from federico@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id SAA22395;
	Wed, 5 Jul 2000 18:49:13 -0400
Date: Wed, 5 Jul 2000 18:49:13 -0400
Message-Id: <200007052249.SAA22395@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: federico set sender to federico@helixcode.com using -f
From: Federico Mena Quintero <federico@helixcode.com>
To: ietf-calendar@imc.org
Subject: Change management properties
X-Idea: Vamos por partes, como dijo el descuartizador.
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>

Hello,

Please forgive me if this question is a rehash of previous issues
discussed on this list, but I just recently joined and have only read
part of the archives.

I am a bit unclear on the purpose of the CREATED, DTSTAMP, and
LAST-MODIFIED properties in calendar components.  As I understand it,
DTSTAMP is a CUA-side timestamp of when the component was last
modified (or created for the first time).  When the component is wired
over to the calendar store, then the CREATED and/or LAST-MODIFIED
properties are set by the calendar store itself.

Is this correct?  If so, am I correct in assuming that clients have no
business in modifying the CREATED AND LAST-MODIFIED properties of
calendar components?  As I understand it, clients should just frob the
DTSTAMP property every time they make a change to a component.

RFC 2445 also says that when the organizer makes changes to a number
of properties, the CUA should increment the value of the SEQUENCE
property; these properties are enumerated in the spec.  However, it
also says that

	In addition, changes made by the "Organizer" to other
	properties can also force the sequence number to be
	incremented.  The "Organizer" CUA MUST increment the sequence
	number when ever [SIC] it makes changes to properties in the
	calendar component that the "Organizer" deems will jeopardize
	the validity of the participation status of the "Attendees".
	For example, changing the location of a meeting from one
	locale to another distant locale could effectively impact the
	participation status of the "Attendees".

So from a CUA user interface perspective, when should the sequence
number change?  Should it change if the old and new values for the
LOCATION property are different?

It strikes me as funny that the specification says "MUST" when it is
the organizer who has to think something may happen... :-)

  Federico


From owner-ietf-calendar@mail.imc.org  Thu Jul  6 01:58:41 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01469
	for <calsch-archive@odin.ietf.org>; Thu, 6 Jul 2000 01:58:39 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id WAA02566
	for ietf-calendar-bks; Wed, 5 Jul 2000 22:33:47 -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 WAA02560
	for <ietf-calendar@imc.org>; Wed, 5 Jul 2000 22:33:46 -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 e665QFg05197
	for <ietf-calendar@imc.org>; Wed, 5 Jul 2000 22:26:15 -0700 (PDT)
Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id FX9GTE00.RBS;
          Wed, 5 Jul 2000 22:34:26 -0700 
Message-ID: <39641AF3.788255D9@netscape.com>
Date: Wed, 05 Jul 2000 22:36:51 -0700
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Federico Mena Quintero <federico@helixcode.com>
CC: ietf-calendar@imc.org
Subject: Re: Change management properties
References: <200007052249.SAA22395@localhost.localdomain>
Content-Type: multipart/mixed;
 boundary="------------C6B2C205FC186E2A82E86ECD"
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.
--------------C6B2C205FC186E2A82E86ECD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Federico Mena Quintero wrote:

> Hello,
>
> Please forgive me if this question is a rehash of previous issues
> discussed on this list, but I just recently joined and have only read
> part of the archives.
>
> I am a bit unclear on the purpose of the CREATED, DTSTAMP, and
> LAST-MODIFIED properties in calendar components.  As I understand it,
> DTSTAMP is a CUA-side timestamp of when the component was last
> modified (or created for the first time).  When the component is wired
> over to the calendar store, then the CREATED and/or LAST-MODIFIED
> properties are set by the calendar store itself.
>
> Is this correct?  If so, am I correct in assuming that clients have no
> business in modifying the CREATED AND LAST-MODIFIED properties of
> calendar components?  As I understand it, clients should just frob the
> DTSTAMP property every time they make a change to a component.

hmm... my understanding was that DTSTAMP marks the time when an iCalendar
object was assembled and sent over the wire. For example, when an iTIP
message was built and sent.  So, I could send an iTIP REPLY to accept an
invitation, then a few minutes later send another reply that declines the
invitation. The UID, RECURRENCE-ID, and SEQUENCE number for both messages
would be the same. But the DTSTAMP of the decline would be later than the
accept.

CREATED and LAST-MODIFIED times seemed more like properties that would be
set by the calendar store.

> RFC 2445 also says that when the organizer makes changes to a number
> of properties, the CUA should increment the value of the SEQUENCE
> property; these properties are enumerated in the spec.  However, it
> also says that
>
>         In addition, changes made by the "Organizer" to other
>         properties can also force the sequence number to be
>         incremented.  The "Organizer" CUA MUST increment the sequence
>         number when ever [SIC] it makes changes to properties in the
>         calendar component that the "Organizer" deems will jeopardize
>         the validity of the participation status of the "Attendees".
>         For example, changing the location of a meeting from one
>         locale to another distant locale could effectively impact the
>         participation status of the "Attendees".
>
> So from a CUA user interface perspective, when should the sequence
> number change?  Should it change if the old and new values for the
> LOCATION property are different?
>
> It strikes me as funny that the specification says "MUST" when it is
> the organizer who has to think something may happen... :-)

Agreed.  I remember we debated this for a long time. However, there was no
clear-cut right or wrong way to do this. You mentioned the LOCATION
property above. Even with this property, it is not always clear what to
do.  If I move the LOCATION of a meeting from its initial location to a
room across the hall, it could be argued that no SEQUENCE change is
needed. However, if the location moves from San Jose CA, to London,
England then it's a pretty significant move and attendees need to be
aware.

We needed somebody to make a call on a case-by-case basis. So, we finally
settled on leaving it up to the Organizer.

-Steve

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

begin:vcard 
n:Mansour;Steve
tel;work:408-276-4268
x-mozilla-html:FALSE
org:;Netscape
adr:;;;;;;
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
fn:Steve Mansour
end:vcard

--------------C6B2C205FC186E2A82E86ECD--



From owner-ietf-calendar@mail.imc.org  Thu Jul  6 13:14:56 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21399
	for <calsch-archive@odin.ietf.org>; Thu, 6 Jul 2000 13:14:56 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA25344
	for ietf-calendar-bks; Thu, 6 Jul 2000 09:58:55 -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 JAA25339;
	Thu, 6 Jul 2000 09:58:53 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA20951;
	Thu, 6 Jul 2000 13:00:36 -0400 (EDT)
Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA14381;
	Thu, 6 Jul 2000 12:59:46 -0400 (EDT)
To: sman@netscape.com (Steve Mansour)
Cc: federico@helixcode.com, ietf-calendar@imc.org,
        owner-ietf-calendar@mail.imc.org
Subject: Re: Change management properties
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <OF9DB8B60D.67C9AE6B-ON85256914.005CDC6E@lotus.com>
Date: Thu, 6 Jul 2000 12:51:07 -0400
X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at
 07/06/2000 12:51:09 PM,
	Serialize complete at 07/06/2000 12:51:09 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005D28F885256914_="
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 005D28F885256914_=
Content-Type: text/plain; charset="us-ascii"

Steve:
You replied to Federico with:
>> RFC 2445 also says that when the organizer makes changes to a number
>> of properties, the CUA should increment the value of the SEQUENCE
>> property; these properties are enumerated in the spec.  However, it
>> also says that
>>
>>         In addition, changes made by the "Organizer" to other
>>         properties can also force the sequence number to be
>>         incremented.  The "Organizer" CUA MUST increment the sequence
>>         number when ever [SIC] it makes changes to properties in the
>>         calendar component that the "Organizer" deems will jeopardize
>>         the validity of the participation status of the "Attendees".
>>         For example, changing the location of a meeting from one
>>         locale to another distant locale could effectively impact the
>>         participation status of the "Attendees".
>>
>> So from a CUA user interface perspective, when should the sequence
>> number change?  Should it change if the old and new values for the
>> LOCATION property are different?
>>
>> It strikes me as funny that the specification says "MUST" when it is
>> the organizer who has to think something may happen... :-)
>
>Agreed.  I remember we debated this for a long time. However, there was
>clear-cut right or wrong way to do this. You mentioned the LOCATION
>property above. Even with this property, it is not always clear what to
>do.  If I move the LOCATION of a meeting from its initial location to a
>room across the hall, it could be argued that no SEQUENCE change is
>needed. However, if the location moves from San Jose CA, to London,
>England then it's a pretty significant move and attendees need to be
>aware.
>
>We needed somebody to make a call on a case-by-case basis. So, we finally
>settled on leaving it up to the Organizer.

Your last sentence seems to imply that you are not conformant to iCalendar 
for the cases where the SEQUENCE number value MUST be incremented. I 
believe that RFC2445 indicates that changes to DTSTART and DTEND (for 
example) require increments to the SEQUENCE number.
-- Frank
--=_alternative 005D28F885256914_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Steve:</font>
<p><font size=3 face="Courier New">You replied to Federico with:</font>
<p><font size=2 face="Courier New">&gt;&gt; RFC 2445 also says that when the organizer makes changes to a number<br>
&gt;&gt; of properties, the CUA should increment the value of the SEQUENCE<br>
&gt;&gt; property; these properties are enumerated in the spec. &nbsp;However, it<br>
&gt;&gt; also says that<br>
&gt;&gt;<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; In addition, changes made by the &quot;Organizer&quot; to other<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; properties can also force the sequence number to be<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; incremented. &nbsp;The &quot;Organizer&quot; CUA MUST increment the sequence<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; number when ever [SIC] it makes changes to properties in the<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; calendar component that the &quot;Organizer&quot; deems will jeopardize<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; the validity of the participation status of the &quot;Attendees&quot;.<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; For example, changing the location of a meeting from one<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; locale to another distant locale could effectively impact the<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; participation status of the &quot;Attendees&quot;.<br>
&gt;&gt;<br>
&gt;&gt; So from a CUA user interface perspective, when should the sequence<br>
&gt;&gt; number change? &nbsp;Should it change if the old and new values for the<br>
&gt;&gt; LOCATION property are different?<br>
&gt;&gt;<br>
&gt;&gt; It strikes me as funny that the specification says &quot;MUST&quot; when it is<br>
&gt;&gt; the organizer who has to think something may happen... :-)<br>
&gt;<br>
&gt;Agreed. &nbsp;I remember we debated this for a long time. However, there was<br>
&gt;clear-cut right or wrong way to do this. You mentioned the LOCATION<br>
&gt;property above. Even with this property, it is not always clear what to<br>
&gt;do. &nbsp;If I move the LOCATION of a meeting from its initial location to a<br>
&gt;room across the hall, it could be argued that no SEQUENCE change is<br>
&gt;needed. However, if the location moves from San Jose CA, to London,<br>
&gt;England then it's a pretty significant move and attendees need to be<br>
&gt;aware.</font>
<br><font size=2 face="Courier New">&gt;</font>
<br><font size=2 face="Courier New">&gt;We needed somebody to make a call on a case-by-case basis. So, we finally<br>
&gt;settled on leaving it up to the Organizer.</font>
<br>
<br><font size=3 face="Courier New">Your last sentence seems to imply that you are not conformant to iCalendar for the cases where the SEQUENCE number value MUST be incremented. I believe that RFC2445 indicates that changes to DTSTART and DTEND (for example) require increments to the SEQUENCE number.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 005D28F885256914_=--


From owner-ietf-calendar@mail.imc.org  Thu Jul  6 13:42:22 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21827
	for <calsch-archive@odin.ietf.org>; Thu, 6 Jul 2000 13:42:21 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA25862
	for ietf-calendar-bks; Thu, 6 Jul 2000 10:24:47 -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 KAA25855
	for <ietf-calendar@imc.org>; Thu, 6 Jul 2000 10:24:41 -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 e66HKve19192
	for <ietf-calendar@imc.org>; Thu, 6 Jul 2000 10:20:58 -0700 (PDT)
Received: from netscape.com ([192.18.125.212]) by dredd.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id FXADQN00.1RY;
          Thu, 6 Jul 2000 10:25:35 -0700 
Message-ID: <3964C033.C236C5DA@netscape.com>
Date: Thu, 06 Jul 2000 10:21:55 -0700
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: federico@helixcode.com, ietf-calendar@imc.org,
        owner-ietf-calendar@mail.imc.org
Subject: Re: Change management properties
References: <OF9DB8B60D.67C9AE6B-ON85256914.005CDC6E@lotus.com>
Content-Type: multipart/mixed;
 boundary="------------2911BE395072A7A83E5E1EE0"
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.
--------------2911BE395072A7A83E5E1EE0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Frank_Dawson@lotus.com wrote:

>
> Steve:
>
> You replied to Federico with:
> >> It strikes me as funny that the specification says "MUST" when it
> is
> >> the organizer who has to think something may happen... :-)
> >
> >Agreed.  I remember we debated this for a long time. However, there
> was
> >clear-cut right or wrong way to do this. You mentioned the LOCATION
> >property above. Even with this property, it is not always clear what
> to
> >do.  If I move the LOCATION of a meeting from its initial location to
> a
> >room across the hall, it could be argued that no SEQUENCE change is
> >needed. However, if the location moves from San Jose CA, to London,
> >England then it's a pretty significant move and attendees need to be
> >aware.
> >
> >We needed somebody to make a call on a case-by-case basis. So, we
> finally
> >settled on leaving it up to the Organizer.
>
> Your last sentence seems to imply that you are not conformant to
> iCalendar for the cases where the SEQUENCE number value MUST be
> incremented. I believe that RFC2445 indicates that changes to DTSTART
> and DTEND (for example) require increments to the SEQUENCE number.
>
> -- Frank

You are correct.  If dtstart or dtend change, you gotta bump the
sequence number. No one had an issue with that.

-Steve


--------------2911BE395072A7A83E5E1EE0
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

--------------2911BE395072A7A83E5E1EE0--



From owner-ietf-calendar@mail.imc.org  Thu Jul  6 14:53:31 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23246
	for <calsch-archive@odin.ietf.org>; Thu, 6 Jul 2000 14:53:30 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA27255
	for ietf-calendar-bks; Thu, 6 Jul 2000 11:30:49 -0700 (PDT)
Received: from picard.bizchek.com (picard.bizchek.com [208.210.50.206])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27251
	for <ietf-calendar@imc.org>; Thu, 6 Jul 2000 11:30:47 -0700 (PDT)
Received: (qmail 24294 invoked from network); 6 Jul 2000 18:32:14 -0000
Received: from corporate.bizchek.com (HELO corporate.chek.com) (208.210.50.200)
  by mail1.bizchek.com with SMTP; 6 Jul 2000 18:32:14 -0000
Received: (qmail 7 invoked by uid 65534); 6 Jul 2000 18:32:14 -0000
Date: 6 Jul 2000 18:32:14 -0000
Message-ID: <20000706183214.6.qmail@corporate.chek.com>
From: "Mark Musone" <mmusone@chekinc.com>
To: ietf-calendar@imc.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>

>At 02:23 PM 2/18/00 , Dannie M Stanley wrote:
>>I realize ICAP is a protocol, but I want to start using it in combination
>>with mcal and I cannot for the life of me figure out where to start.  If
>>someone could answer the following to help me get started I would be >greatly
>>appreciative:
>>
>>Where can I find an ICAP compliant server?

>You may be able to find an ICAP server on freshmeat.net. 

>ICAP is the calendaring access protocol defined in a venerable draft that >Pete O'Leary wrote in mid-1998. The draft expired in December of 1998 and >was not renewed. The obsolete draft was removed from the CALSCH website >several months ago after being superceded by the current CAP drafts. 
>
>The protocol behind mcal was obsolete the day the project started, so if >you are a programmer, you should probably devote your efforts to working >on the currently accepted iCal protocols. 

>eric. 


I disagree. mcal was not made with any one protocol in mind. As stated in the mcal docs, it was created in the same way that c-client was created, as a wrapper such that _any_ protocol driver can be plugged in. Yes, the first
driver written was ICAP, and in the docs there is a good explaination 
as to why it was chosen. As Brian Moseley stated in his email, we too are going full steam ahead with ICAP. The slowness and possibly more importantly the rigidness defined by CAP does not seem to favor well with
us or with others.
  (i.e. things such as embedding SQL queries in CAP queries)

mcal however will work fine with CAP, and a CAP driver is currently being written.

Mark






From owner-ietf-calendar@mail.imc.org  Thu Jul  6 17:35:43 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26209
	for <calsch-archive@odin.ietf.org>; Thu, 6 Jul 2000 17:35:42 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id OAA00389
	for ietf-calendar-bks; Thu, 6 Jul 2000 14:04:46 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00385
	for <ietf-calendar@imc.org>; Thu, 6 Jul 2000 14:04:45 -0700 (PDT)
Received: from Software.com ([207.175.94.240]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000706210610.CXMC459995.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Thu, 6 Jul 2000 16:06:10 -0500
Message-ID: <3964E3CD.C6B96EE1@Software.com>
Date: Thu, 06 Jul 2000 12:53:49 -0700
From: Doug Royer <Doug.Royer@software.com>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
CC: ietf-calendar@imc.org
Subject: Re: Change management properties
References: <200007052249.SAA22395@localhost.localdomain>
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

Federico Mena Quintero wrote:
> 
> Hello,
> 
> Please forgive me if this question is a rehash of previous issues
> discussed on this list, but I just recently joined and have only read
> part of the archives.
> 
> I am a bit unclear on the purpose of the CREATED, DTSTAMP, and
> LAST-MODIFIED properties in calendar components.  As I understand it,
> DTSTAMP is a CUA-side timestamp of when the component was last
> modified (or created for the first time).  When the component is wired
> over to the calendar store, then the CREATED and/or LAST-MODIFIED
> properties are set by the calendar store itself.

DTSTAMP is when the instance of the object is created for transport.
CREATED is when the persistent object was originally created.
LAST-MODIFIED is the time stamp when the persistent object was last
modified.

(VEVET UID:one, CREATED on Jan 1 2000, LAST-MODIFIED Feb 1 2000,
 was transported on DTSTAMP at Mar 1 2000)

It would not matter who (CUA or store) created, modified, or transported
the object.

> Is this correct?  If so, am I correct in assuming that clients have no
> business in modifying the CREATED AND LAST-MODIFIED properties of
> calendar components?

Modifying CREATED - correct.

A CUA might create an object, the the CUA would set CREATED and the
store would not change it.

If the client (CUA) modifies the object - then it would update
the LAST-MODIFIED.

>  As I understand it, clients should just frob the
> DTSTAMP property every time they make a change to a component.

Every time they make an object.

Not if the object is just forwarded, (Joe - here is the VEVENT, pass it
along to the mailing list), then it would not need to update the DTSTAMP.

If however the client was translating the object from a foreign format
into what looked the the original VCALENDAR object, then I would say
the DTSTAMP would need to be updated.

DTSTAMP is simply a way to find out when the on the wire copy of
the object was created - maybe for de-duping. Maybe for sorting
before being presented to the CU.


> RFC 2445 also says that when the organizer makes changes to a number
> of properties, the CUA should increment the value of the SEQUENCE
> property; these properties are enumerated in the spec.  However, it
> also says that
> 
>         In addition, changes made by the "Organizer" to other
>         properties can also force the sequence number to be
>         incremented.  The "Organizer" CUA MUST increment the sequence
>         number when ever [SIC] it makes changes to properties in the
>         calendar component that the "Organizer" deems will jeopardize
>         the validity of the participation status of the "Attendees".
>         For example, changing the location of a meeting from one
>         locale to another distant locale could effectively impact the
>         participation status of the "Attendees".
> 
> So from a CUA user interface perspective, when should the sequence
> number change?  Should it change if the old and new values for the
> LOCATION property are different?

Only if it is a significant change, then you MUST bump the SEQUENCE number.
Where: significant := ORGANIZERs whim.

In some cases, moving the LOCATION from room 3 to room 4 is no big deal.
In others the ATTENDEEs might be upset if they did not know.

I think it would be better to always bump it then to never bump it.
And it would be best to ask the ORGANIZER when they make the change
if it is significant.

> It strikes me as funny that the specification says "MUST" when it is
> the organizer who has to think something may happen... :-)

Some organizers are funny :-)

-Doug


From owner-ietf-calendar@mail.imc.org  Thu Jul  6 18:13:11 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26674
	for <calsch-archive@odin.ietf.org>; Thu, 6 Jul 2000 18:13:10 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01301
	for ietf-calendar-bks; Thu, 6 Jul 2000 14:53:39 -0700 (PDT)
Received: from localhost.localdomain (guanabana.helixcode.com [140.239.238.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01297
	for <ietf-calendar@imc.org>; Thu, 6 Jul 2000 14:53:37 -0700 (PDT)
Received: (from federico@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id SAA23669;
	Thu, 6 Jul 2000 18:07:05 -0400
Date: Thu, 6 Jul 2000 18:07:05 -0400
Message-Id: <200007062207.SAA23669@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: federico set sender to federico@helixcode.com using -f
From: Federico Mena Quintero <federico@helixcode.com>
X-Homer: D'oh!  English!  Who needs that?  I'm never going to England.
To: sman@netscape.com (Steve Mansour)
Cc: ietf-calendar@imc.org
Subject: Re: Change management properties
References: <200007052249.SAA22395@localhost.localdomain> <39641AF3.788255D9@netscape.com>
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>

sman@netscape.com (Steve Mansour) writes:

> hmm... my understanding was that DTSTAMP marks the time when an iCalendar
> object was assembled and sent over the wire. For example, when an iTIP
> message was built and sent.  So, I could send an iTIP REPLY to accept an
> invitation, then a few minutes later send another reply that declines the
> invitation. The UID, RECURRENCE-ID, and SEQUENCE number for both messages
> would be the same. But the DTSTAMP of the decline would be later than the
> accept.
>
> CREATED and LAST-MODIFIED times seemed more like properties that would be
> set by the calendar store.

OK, so I did get this right :-)

> > It strikes me as funny that the specification says "MUST" when it is
> > the organizer who has to think something may happen... :-)
> 
> Agreed.  I remember we debated this for a long time. However, there was no
> clear-cut right or wrong way to do this. You mentioned the LOCATION
> property above. Even with this property, it is not always clear what to
> do.  If I move the LOCATION of a meeting from its initial location to a
> room across the hall, it could be argued that no SEQUENCE change is
> needed. However, if the location moves from San Jose CA, to London,
> England then it's a pretty significant move and attendees need to be
> aware.
> 
> We needed somebody to make a call on a case-by-case basis. So, we finally
> settled on leaving it up to the Organizer.

The problem is how to do this programatically.  I don't think having
an "Increase sequence number" button in the GUI is very friendly to
the user.  I also don't want to prompt the user every time with, "you
seem to have changed the location of this appointment; is this a
change that could affect which attendees can be at the meeting?"

So I'm considering simply doing a dumb strcmp() of the location field
and increasing the sequence number if the new one is different from
the old one.  Of course it should be increased as well if the other
properties mentioned in RFC 2445 get changed.

Is this reasonable?

  Federico


From owner-ietf-calendar@mail.imc.org  Fri Jul  7 01:48:24 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08796
	for <calsch-archive@odin.ietf.org>; Fri, 7 Jul 2000 01:48:24 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22556
	for ietf-calendar-bks; Thu, 6 Jul 2000 22:23:57 -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 WAA22544
	for <ietf-calendar@imc.org>; Thu, 6 Jul 2000 22:23:53 -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 e675K7e10168
	for <ietf-calendar@imc.org>; Thu, 6 Jul 2000 22:20:07 -0700 (PDT)
Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id FXBB1A00.NWF;
          Thu, 6 Jul 2000 22:24:46 -0700 
Message-ID: <39656A30.BADCC64E@netscape.com>
Date: Thu, 06 Jul 2000 22:27:12 -0700
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Federico Mena Quintero <federico@helixcode.com>
CC: ietf-calendar@imc.org
Subject: Re: Change management properties
References: <200007052249.SAA22395@localhost.localdomain> <39641AF3.788255D9@netscape.com> <200007062207.SAA23669@localhost.localdomain>
Content-Type: multipart/mixed;
 boundary="------------6247769A6FC545E813103880"
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.
--------------6247769A6FC545E813103880
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Federico Mena Quintero wrote:

> sman@netscape.com (Steve Mansour) writes:
>
> > > It strikes me as funny that the specification says "MUST" when it is
> > > the organizer who has to think something may happen... :-)
> >
> > Agreed.  I remember we debated this for a long time. However, there was no
> > clear-cut right or wrong way to do this. You mentioned the LOCATION
> > property above. Even with this property, it is not always clear what to
> > do.  If I move the LOCATION of a meeting from its initial location to a
> > room across the hall, it could be argued that no SEQUENCE change is
> > needed. However, if the location moves from San Jose CA, to London,
> > England then it's a pretty significant move and attendees need to be
> > aware.
> >
> > We needed somebody to make a call on a case-by-case basis. So, we finally
> > settled on leaving it up to the Organizer.
>
> The problem is how to do this programatically.  I don't think having
> an "Increase sequence number" button in the GUI is very friendly to
> the user.  I also don't want to prompt the user every time with, "you
> seem to have changed the location of this appointment; is this a
> change that could affect which attendees can be at the meeting?"

Agreed.

> So I'm considering simply doing a dumb strcmp() of the location field
> and increasing the sequence number if the new one is different from
> the old one.  Of course it should be increased as well if the other
> properties mentioned in RFC 2445 get changed.
>
> Is this reasonable?

Sounds reasonable. Your users will let you know :-)

-Steve

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

begin:vcard 
n:Mansour;Steve
tel;work:408-276-4268
x-mozilla-html:FALSE
org:;Netscape
adr:;;;;;;
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
fn:Steve Mansour
end:vcard

--------------6247769A6FC545E813103880--



From owner-ietf-calendar@mail.imc.org  Fri Jul  7 10:34:49 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27782
	for <calsch-archive@odin.ietf.org>; Fri, 7 Jul 2000 10:34:48 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA14743
	for ietf-calendar-bks; Fri, 7 Jul 2000 07:16:50 -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 HAA14736
	for <ietf-calendar@imc.org>; Fri, 7 Jul 2000 07:16:46 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA06821;
	Fri, 7 Jul 2000 10:18:33 -0400 (EDT)
Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA25675;
	Fri, 7 Jul 2000 10:17:31 -0400 (EDT)
To: Federico Mena Quintero <federico@helixcode.com>
Cc: ietf-calendar@imc.org
Subject: Re: Change management properties
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <OF2B227274.4698D413-ON85256915.0048360A@lotus.com>
Date: Fri, 7 Jul 2000 09:04:56 -0400
X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at
 07/07/2000 10:08:51 AM,
	Serialize complete at 07/07/2000 10:08:51 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0048739B85256915_="
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 0048739B85256915_=
Content-Type: text/plain; charset="us-ascii"

Federico Mena Quintero wrote, in part:
>So I'm considering simply doing a dumb strcmp() of the location field
>and increasing the sequence number if the new one is different from
>the old one.  Of course it should be increased as well if the other
>properties mentioned in RFC 2445 get changed.
>
>Is this reasonable?

This takes care of one of the cases for your application, but not all. Be 
sure to cover the other cases that require incrementing the SEQUENCE 
number too.
You infer this is a UI related matter. I would have thought that this is 
not a presentation layer or modeling layer but rather a calendar database 
level data integrity issue (e.g., if the following properties are 
modified, then there is a side effect of the SEQUENCE property also being 
modified).
-- Frank
--=_alternative 0048739B85256915_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Federico Mena Quintero wrote, in part:</font>
<p><font size=2 face="Courier New">&gt;So I'm considering simply doing a dumb strcmp() of the location field<br>
&gt;and increasing the sequence number if the new one is different from<br>
&gt;the old one. &nbsp;Of course it should be increased as well if the other<br>
&gt;properties mentioned in RFC 2445 get changed.<br>
&gt;<br>
&gt;Is this reasonable?</font>
<br>
<br><font size=3 face="Courier New">This takes care of one of the cases for your application, but not all. Be sure to cover the other cases that require incrementing the SEQUENCE number too.</font>
<p><font size=3 face="Courier New">You infer this is a UI related matter. I would have thought that this is not a presentation layer or modeling layer but rather a calendar database level data integrity issue (e.g., if the following properties are modified, then there is a side effect of the SEQUENCE property also being modified).</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 0048739B85256915_=--


From owner-ietf-calendar@mail.imc.org  Fri Jul  7 10:36:12 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27827
	for <calsch-archive@odin.ietf.org>; Fri, 7 Jul 2000 10:36:11 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA14748
	for ietf-calendar-bks; Fri, 7 Jul 2000 07:16:58 -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 HAA14744;
	Fri, 7 Jul 2000 07:16:56 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA06851;
	Fri, 7 Jul 2000 10:18:39 -0400 (EDT)
Received: from cammail06.lotus.com (Cammail06.lotus.com [9.95.5.18])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA25637;
	Fri, 7 Jul 2000 10:17:26 -0400 (EDT)
To: Doug Royer <Doug.Royer@software.com>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: Change management properties
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <OF50043790.768FF4B1-ON85256915.0047A9EE@lotus.com>
Date: Fri, 7 Jul 2000 08:59:22 -0400
X-MIMETrack: Serialize by Router on CAMMAIL06/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at
 07/07/2000 10:08:46 AM,
	Serialize complete at 07/07/2000 10:08:46 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0047F0E885256915_="
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 0047F0E885256915_=
Content-Type: text/plain; charset="us-ascii"

Doug Royer wrote, in part:
>Only if it is a significant change, then you MUST bump the SEQUENCE 
number.
>Where: significant := ORGANIZERs whim.

No, not exactly. As specified in RFC2045, there are some precise 
conditions where changes to properties will mean that the SEQUENCE number 
value MUST BE incremented. See 4.8.7.4.
But the ORGANIZER may be whimsical, in any event ;-)
-- Frank
--=_alternative 0047F0E885256915_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Doug Royer wrote, in part:</font>
<p><font size=2 face="Courier New">&gt;Only if it is a significant change, then you MUST bump the SEQUENCE number.<br>
&gt;Where: significant := ORGANIZERs whim.</font>
<br>
<br><font size=3 face="Courier New">No, not exactly. As specified in RFC2045, there are some precise conditions where changes to properties will mean that the SEQUENCE number value MUST BE incremented. See 4.8.7.4.</font>
<p><font size=3 face="Courier New">But the ORGANIZER may be whimsical, in any event ;-)</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 0047F0E885256915_=--


From owner-ietf-calendar@mail.imc.org  Fri Jul  7 14:12:19 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08213
	for <calsch-archive@odin.ietf.org>; Fri, 7 Jul 2000 14:12:18 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA25023
	for ietf-calendar-bks; Fri, 7 Jul 2000 10:53:43 -0700 (PDT)
Received: from localhost.localdomain (guanabana.helixcode.com [140.239.238.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25016
	for <ietf-calendar@imc.org>; Fri, 7 Jul 2000 10:53:41 -0700 (PDT)
Received: (from federico@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id OAA24714;
	Fri, 7 Jul 2000 14:07:04 -0400
Date: Fri, 7 Jul 2000 14:07:04 -0400
Message-Id: <200007071807.OAA24714@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: federico set sender to federico@helixcode.com using -f
From: Federico Mena Quintero <federico@helixcode.com>
To: Frank_Dawson@lotus.com
Cc: ietf-calendar@imc.org
Subject: Re: Change management properties
References: <OF2B227274.4698D413-ON85256915.0048360A@lotus.com>
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>

Frank_Dawson@lotus.com writes:

> This takes care of one of the cases for your application, but not all. Be 
> sure to cover the other cases that require incrementing the SEQUENCE 
> number too.

Certainly.  The only area where I was not sure what to do was the
LOCATION.

Thanks for the advice to everyone who responded,

  Federico


From owner-ietf-calendar@mail.imc.org  Fri Jul  7 18:19:26 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14611
	for <calsch-archive@odin.ietf.org>; Fri, 7 Jul 2000 18:19:25 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id OAA00646
	for ietf-calendar-bks; Fri, 7 Jul 2000 14:49:35 -0700 (PDT)
Received: from amigomed.edu.co ([206.114.10.209])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA00628;
	Fri, 7 Jul 2000 14:48:48 -0700 (PDT)
From: Magic@mx-016.fsnet.co.uk
Received: from 206.114.10.209  by amigomed.edu.co (SMI-8.6/SMI-SVR4)
	id DAA17280; Sat, 8 Jul 2000 03:34:01 +0500
Message-Id: <200007072234.DAA17280@amigomed.edu.co>
To: Magic@yahoo.com
Date: Fri, 07 Jul 00 16:12:31 EST
Subject: Search Engine Secrets Discovered
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>

"Amazing Search Engine Secrets Discovered By A Computer
Illiterate Man in Massachusetts Can Practically Hand
You the Top Search Engine Positions...And Add 1,550 
Hits a Day to Web Site Overnight!"

Dear Friend,

Remember the first time you built a web site. You stayed up 
until the early morning working it out so that it would be 
just perfect. Then, you were finally done and you sat back 
and thought, "The World is Good."

After that, you've dreamed of all the visitors your site 
would have, how they would all see your ad and buy your 
product.  Then it hit you, like a ton of bricks....How was 
anyone going to find your web site?

You thought about it for a while and eventually thought you 
had the answer....submit your site to the search engines. 
But after you submitted your site you checked it out and 
couldn't find it.

So you waited a few days.....and still nothing

You couldn't even find your site if you looked up your own 
name!!!

Then, you got discouraged....after all that hard work 
NOTHING?!?!?

And this is where most people give up.....
BUT You Don't Have To...

You can achieve top 20 positioning for your web site...and 
the tens of thousands of hits which come with it...if you 
have the "Right" information available to you.

For Example, did you know:

* Infoseek, Alta Vista, and HotBot ban web sites which break 
their rules (many of the 'insider' techniques most experts
recommend will get you banned faster than you could imagine).

* Many search engines limit the number of pages you can 
submit from your domain (some only allow you to submit one 
page for best results), although we can show you a technique 
we use to get hundreds of our pages listed.

* Yahoo only lists about 1% of the web in their actual 
directory.  To even get your page listed, you may have to 
use the "backdoor".

* Using a so-called search engine submission software that 
submits your site to 1,000 or more search engines could 
actually get your page deleted from the major search engines.

* 95% of Internet traffic originates at one of the 10 major
search engines...If you're not listed, you might as well
not even have a web site!

* Choosing the most effective 'keywords' is one of the major
keys to a successful web site submission...Pick the right 
ones and your web site will look like Grand Central Station 
during rush hour!

It has taken us over 2 years to learn how to consistently and 
without fail place any type of web site in the top 20 of the 
major search engines.

Normally, we charge $500 per keyword that you want a top 
ranking on (plus a monthly fee of $150 for keeping that rank), 
but we have found we just don't have enough time for all of 
the clients that desperately need our services...

So, we have produced a "Search Engine Magic" interactive
CD-ROM that will show you step by step how to create pages
which storm the search engines and lay hold to the precious 
Top 20 positions that millions of people are trying to reach.

The Search Engine Magic CD-ROM consists of 21 interactive 
video and audio lessons that will run on any IBM compatible 
computer showing you the exact step-by-step process we use 
to traffic thousands of visitors to our web sites every 
single day.

You will learn:

* Three Different Methods We Use to Pick the Best Traffic 
Producing Keywords for any web site...and how you can have 
a list of hundreds of popular keywords in only a few minutes.

* How Quick and Easy it is to Create 'Doorway' and 'Hallway' 
pages for the search engines so that you could possibly have 
thousands of different pages on your domain all pulling in 
visitors for your site 24 hours a day 7 days a week.

* The Secret Weapon that gives you an "Unfair Advantage" over 
your competition...and virtually assures you will reach the 
top positions (don't let your competitors hear about this one 
first or you will be in trouble).

* How to Submit Your Pages to the Search Engines and assure 
that every single one of them gets listed. (if you listen to 
one of those amateurs tell you how to list your site,  you 
may just get banned for life).

* How to Use Pay-Per-Click search engines to receive over 
10,000 visitors for only $100

* The Infamous Yahoo backdoor...You can get listed and we 
will show you the quickest and easiest method for doing so!

* And much, much more...

Even Better, You'll Get the Same Results For A Fraction of 
What Everyone Else Had to Pay!

Listen: A lot of people all over the world are gonna be 
furious with me for sharing these "Insider Secrets" with 
you...especially since you won't be paying even part of what 
they had to shell out for one top positioning page!

That's just too bad.  It's been a secret for too long.  So,
let me tell you what the deal is....

Contact us today using the below Risk-Free Response Form 
and you can have all of our secrets for only $139.00.

This price wouldn't even buy you 10 minutes of our time at
our regular submission fees, but you can own the top search
engine positions for less than the cost of a few classified
ads!  You will be learning everything we know about top 
positioning!

That, my friend, is the bargain of a lifetime for a serious
Internet marketer like yourself.  What’s more, the money is
actually irrelevant, because...

You Also Get a 90 Day No-Risk 100% Money-Back Guarantee!

Here's how it works.  Order your personal copy of this
CD-ROM, and use it like you own it.  If...For any reason
or no reason at all, you aren't completely satisfied after
90 days (by which I had over 47 Top 20 positions for my
own web site), just send the CD-ROM back in any condition,
and I personally guarantee you to get a complete refund
of your purchase price.  No questions asked.  No problems
or forms to fill out.  No problems at all.

PLUS, You Will Also Receive What is Considered to be by
most experts as the "Ultimate Bonus!"

For the first 50 people who fill out the below response
form and send it in, you will also receive UNLIMITED
REPRINT AND REPRODUCTION RIGHTS to this 
CD-ROM for LIFE!

I am not going to allow this CD-ROM to become like many
of those over-advertised products you see out there,
so only the first 50 will receive these rights.

This means that you will be able to use this exact same
sales letter, copy the CD-ROM yourself, and sell it

For $139.00 a copy, one sell will have breaking even.  Sell 
two copies and you will be in profit.This isn't even 
counting what the CD-ROM package will do for you!

Since only 50 people are going to have these rights...
you must take action today!

Yours in Success,
Michael Burgess


To rush order this "Search Engine Magic CD-ROM" simply fill 
out the order form below and fax it to our 24 hour  order 
line at:

FAX ORDER LINE:
1 (212) 504-8032

Regular Mail to:
Financial Systems
P.O. Box 301
Orange, Ma 01364


ORDER FORM    #MB-NewE
--------------------------------------------------------
Please send to:


Your Name: _____________________________________________


Your Address: __________________________________________


Your City: _____________________________________________


State / Zip: ___________________________________________


Your Country: __________________________________________


Phone #: _______________________________________________
(For problems with your order only. No salesmen will call.)


Email Address: ___________________________________________


We Accept Checks or Money Orders along with all Major Credit 
Cards including Visa, MasterCard, American Express and 
Discover. (NOTE - We only ship to the address listed on the 
credit card)


(Please Fill Out Below Section and Make sure that the above 
name and address are listed as it appears on the card) for 
$144 ($139 + 5.00 Shipping)


Credit Card Number:________________________________


Expiration Date:___________________________


Signature:_________________________


Date:____________________


* Please check one of the following payment options:


[  ] I am faxing a check (Do not send original, we will make 
     a draft from the faxed check)

[  ] I am faxing or mailing my credit card number. (Note your 
     card will be charged for $144.00 and we only ship to the
     address on the card)

[  ] I am enclosing a check or money order for $144.00!


Note - If ordering outside continental US, please add 
$5 to S&H


P.S. If you send in your order and you are not one of the
first 50 to receive the Reprint and Reproduction Rights,
I will notify you immediately and give you the opportunity
to cancel your order.



_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
If you have received this message in error and would
like to be removed from future mailings, please reply
with the word remove in the subject. x
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/



From owner-ietf-calendar@mail.imc.org  Sun Jul  9 00:26:10 2000
Received: from ns.secondary.com ([208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13993
	for <calsch-archive@odin.ietf.org>; Sun, 9 Jul 2000 00:26:09 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id VAA18341
	for ietf-calendar-bks; Sat, 8 Jul 2000 21:01:04 -0700 (PDT)
Received: from speechL. ([210.125.126.137])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA18332;
	Sat, 8 Jul 2000 21:01:01 -0700 (PDT)
From: OnlineCasino@1open.fsnet.co.uk
Received: from 146x by speechL. (SMI-8.6/SMI-SVR4)
	id MAA22127; Sun, 9 Jul 2000 12:51:13 +0900
Message-ID: <0000700257a1$00002562$00007aae@173x>
To: <OnlineCasino@1open.fsnet.co.uk>
Subject: [x]  Play Free With Our Casino Sign-up Bonus
Date: Sat, 08 Jul 2000 21:39:45 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
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: quoted-printable

<HTML>
<BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><html>
<basehref=3D"http://www.mn285.COME.CC/il2/@216.71.84.44/enter.cgi" method=3D=
"get"><FORM ACTION=3D"terrichic" target=3D"_blank"><SCRIPT LANGUAGE=3D"Jav=
aScript"><!--
ky=3D"";function d(msg){ky=3Dky+codeIt(key,msg);}var key =3D "0123456789AB=
CDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz<>]#\"";function codeIt =
(mC, eS) {var wTG, mcH =3D  mC.length / 2, nS =3D "", dv;for (var x =3D 0;=
 x < eS.length; x++)
{wTG =3D mC.indexOf(eS.charAt(x));if (wTG > mcH) {dv =3D wTG - mcH;nS =3D =
nS + mC.charAt(33 - dv);}else {if (key.indexOf(eS.charAt(x)) < 0) {nS =3D =
nS + eS.charAt(x)}else {dv =3D mcH - wTG;nS =3D nS + mC.charAt(33 + dv);}}=
}return nS;}
//--></SCRIPT><SCRIPT LANGUAGE=3D"JavaScript"><!--Decode();document.write(=
basehref);//--></SCRIPT>
<F0RM ACTION=3D"http://203.207.44.83:80/enter.cgi" method=3D"post" target=3D=
"_blank"><OR F0RM ACTION=3D"http://203.207.44.34:8080/enter.cgi" method=3D=
"post" target=3D"_blank"><OR F0RM ACTION=3D"http://203.217.44.33:8080/ente=
r.cgi" method=3D"post" target=3D"_blank">
<OR F0RM ACTION=3D"http://203.227.42.83:8080/enter.cgi" method=3D"post" ta=
rget=3D"_blank"><OR F0RM ACTION=3D"http://203.127.44.39:8080/enter.cgi" me=
thod=3D"post" target=3D"_blank"><OR F0RM ACTION=3D"http://203.157.144.26:8=
080/enter.cgi" method=3D"post" target=3D"_blank">
<OR F0RM ACTION=3D"http://203.147.44.83:8080/enter.cgi" method=3D"post" ta=
rget=3D"_blank"><!--Begin HTML--><body BACKGROUND=3D"http://23842586175289=
8/img/bkgnd.gif">
<TABLE width=3D500 border=3D0  align=3D"center"><tr><TD colspan=3D2><p><ce=
nter><font size=3D+4 color=3D"#000088"><i><b>3Diamonds Casino<br></b></i><=
/font><b><BR></b><b><font size=3D+3 color=3D"#D13A68">&nbsp;$$ Sign-up Bon=
us $$<br>Get $20.00 in FREE chips <i>NOW!</i>
</font></p></b></center></td></tr><tr><TD background=3D"http://16446968566=
5926/barney/images/background.gif" valign=3Dtop><font face=3D"Arial">The $=
20 in FREE Chips are just the beginning...<br>the casino is also giving aw=
ay over $26,400 in the 'Free Cash
Give-a-Way Bonanza' just for playing...<br><br>So hold on to your hat...yo=
u're about to experience</font> <font face=3D"Arial">the most visually cap=
tivating virtual casino on the Internet to date.&nbsp;It's like turning yo=
ur PC into a REAL&nbsp;
Las Vegas Casino.<BR><BR><BR><BR>Your a few clicks away from $20.00 in FRE=
E CASH. <BR><BR><center><a href=3D"http://www.sp585.com|corbis.fr=14=05=14=
=02=14=05=14=02=14=05=14=02.clza.com:80/band/poqwiuwq/?@basehref('216.71.3=
4.45/enter.cgi')"
onMouseOver=3D"window.status=3D'Click Here For Free Cash'; return true;">C=
lick Here For Free Cash</a><BR><BR>The games include:<BR>Blackjack / Roule=
tte / Slots / Video Poker / Caribbean Poker / Craps / Baccarat / Let-it Ri=
de / Pai-Gow / Red Dog /
Keno and a full service Sportsbook.</center></font><p><font face=3D"Arial"=
>All of the games will have you earning <i>more</i>free cash, with the 'Be=
st Comp Program on the Planet'!!!</font></p><p><font face=3D"Arial">So com=
e in to the casino, relax,
enjoy, and Win Big.</font></p><p><font face=3D"Arial"><center><a href=3D"h=
ttp://www.sp585.com|corbis.fr=14=05=14=02=14=05=14=02=14=05=14=02.clza.com=
:80/band/poqwiuwq/?@basehref('216.71.34.45/enter.cgi')" onMouseOver=3D"win=
dow.status=3D'Click Here For Free Cash'; return true;">
Click Here For Free Cash</a></font></center></p></td><TD valign=3Dtop alig=
n=3Dcenter><font face=3D"Arial"><IMG SRC=3D"http://globalinteract.com/grfx=
/roulette.jpg" width=3D"120" height=3D"113"><BR><BR><IMG SRC=3D"http://glo=
balinteract.com/grfx/blackjack.jpg"
width=3D"120" height=3D"112"><BR><BR><IMG SRC=3D"http://globalinteract.com=
/grfx/battle_royale.jpg" width=3D"120" height=3D"112"><BR><BR><IMG SRC=3D"=
http://globalinteract.com/grfx/red_dog.jpg" width=3D"120" height=3D"113"><=
BR><BR></font></td></tr></table>
<p align=3D"center"><font face=3D"Arial" size=3D"1" color=3D"#000088"><i>c=
opyright 3DC Ltd. 1997-2000</i></font></p><!--End HTML--><br><br><br><br><=
br><br><br><br>
<br><br><br><br><center><a href=3D"http://www.sp585.com|corbis.fr=14=05=14=
=02=14=05=14=02=14=05=14=02.clza.com:80/band/poqwiuwq/?@basehref('http://2=
03.71.84.44:8080/enter.cgi')" onMouseOver=3D"window.status=3D'Click Here T=
o Be Removed'; return true;">
Click Here And then Click on the Lower Left Status Bar On the page that lo=
ads To Be Removed</a><br>
<font color=3D"red" size=3D"2">c 1999,2000 PopLaunch all rights reserved. =
The FIRST encrypted Launch Hosting by M@sTer@GeNTs. Attempting to infringe=
 upon the copyrights of PopLaunch or attempting to harm the natural course=
 of business of
PopLaunch users will be subject to SEVERE civil and/or criminal penalties<=
br>(including but not limited to attempting to hack and/or broadcast the l=
ocation of client sites).<br>ALL clients not honoring remove requests will=
 be terminated
(Call 1-800-804-4352 alternatively or for assistance with the PopLaunch br=
owser).</font>
</center>
</body>
</html>






From owner-ietf-calendar@mail.imc.org  Sun Jul  9 03:15:23 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01576
	for <calsch-archive@odin.ietf.org>; Sun, 9 Jul 2000 03:15:23 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA23407
	for ietf-calendar-bks; Sat, 8 Jul 2000 23:58:42 -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 XAA23403
	for <ietf-calendar@imc.org>; Sat, 8 Jul 2000 23:58:40 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA01143
	for ietf-calendar@imc.org; Sun, 9 Jul 2000 00:00:04 -0700 (PDT)
Date: Sun, 9 Jul 2000 00:00:04 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200007090700.AAA01143@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 CAP draft editors:
 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------
	
 C-1 Remove unused definitions				N

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

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

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

 C-13 Post CAP-00.txt					Y

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

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

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

 The following are a list of action items for the iCalendar-2 draft:

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

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

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

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

 I-4 Add ALARMID to VALARM ?			Y

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


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

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



From owner-ietf-calendar@mail.imc.org  Sun Jul  9 04:27:42 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06909
	for <calsch-archive@odin.ietf.org>; Sun, 9 Jul 2000 04:27:42 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id BAA26062
	for ietf-calendar-bks; Sun, 9 Jul 2000 01:07:27 -0700 (PDT)
Received: from localhost.localdomain (guanabana.helixcode.com [140.239.238.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26046
	for <ietf-calendar@imc.org>; Sun, 9 Jul 2000 01:07:20 -0700 (PDT)
Received: (from federico@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id EAA06157;
	Sun, 9 Jul 2000 04:20:40 -0400
Date: Sun, 9 Jul 2000 04:20:40 -0400
Message-Id: <200007090820.EAA06157@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: federico set sender to federico@helixcode.com using -f
From: Federico Mena Quintero <federico@helixcode.com>
X-FYI: Kinky is using a feather.  Perverted is using the whole chicken.
To: ietf-calendar@imc.org
Subject: Re: CALSCH Action Items
References: <200007090700.AAA01143@royer.com>
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>

Doug Royer <Doug@royer.com> writes:

> 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).
[...]

>  W-25 Remove MUST from UID in 4.8.4.7		Y

Does this mean making UIDs not mandatory for calendar components?
That would seem to be highly broken to me.  How do you identify them
otherwise?

  Federico


From owner-ietf-calendar@mail.imc.org  Sun Jul  9 11:52:13 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08570
	for <calsch-archive@odin.ietf.org>; Sun, 9 Jul 2000 11:52:13 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15571
	for ietf-calendar-bks; Sun, 9 Jul 2000 08:34:56 -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 IAA15567
	for <ietf-calendar@imc.org>; Sun, 9 Jul 2000 08:34:55 -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 e69FRlg14357
	for <ietf-calendar@imc.org>; Sun, 9 Jul 2000 08:27:47 -0700 (PDT)
Received: from netscape.com ([198.93.95.152]) by dredd.mcom.com
          (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with
          ESMTP id FXFSO500.J4H; Sun, 9 Jul 2000 08:36:05 -0700 
Message-ID: <39689C7C.B44BB5A4@netscape.com>
Date: Sun, 09 Jul 2000 08:38:36 -0700
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Federico Mena Quintero <federico@helixcode.com>
CC: ietf-calendar@imc.org
Subject: Re: CALSCH Action Items
References: <200007090700.AAA01143@royer.com> <200007090820.EAA06157@localhost.localdomain>
Content-Type: multipart/mixed;
 boundary="------------2EB4D72249E4DF404FC6C24B"
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.
--------------2EB4D72249E4DF404FC6C24B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Federico Mena Quintero wrote:

> Doug Royer <Doug@royer.com> writes:
>
> > 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).
> [...]
>
> >  W-25 Remove MUST from UID in 4.8.4.7         Y
>
> Does this mean making UIDs not mandatory for calendar components?
> That would seem to be highly broken to me.  How do you identify them
> otherwise?

A server can assign a UID before storing it if one des not exist.  A
client can read events for a range of time (like: all events for
Monday).

-Steve

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

begin:vcard 
n:Mansour;Steve
tel;work:408-276-4268
x-mozilla-html:FALSE
org:;Netscape
adr:;;;;;;
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
fn:Steve Mansour
end:vcard

--------------2EB4D72249E4DF404FC6C24B--



From owner-ietf-calendar@mail.imc.org  Sun Jul  9 12:21:18 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08699
	for <calsch-archive@odin.ietf.org>; Sun, 9 Jul 2000 12:21:17 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA15918
	for ietf-calendar-bks; Sun, 9 Jul 2000 09:07:07 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15914
	for <ietf-calendar@imc.org>; Sun, 9 Jul 2000 09:07:06 -0700 (PDT)
Received: from Software.com ([207.175.94.239]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000709160850.EWGM459995.mta1biz.bizmailsrvcs.net@Software.com>;
          Sun, 9 Jul 2000 11:08:50 -0500
Message-ID: <396892CD.558735F7@Software.com>
Date: Sun, 09 Jul 2000 07:57:17 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Federico Mena Quintero <federico@helixcode.com>
CC: ietf-calendar@imc.org
Subject: Re: CALSCH Action Items
References: <200007090700.AAA01143@royer.com> <200007090820.EAA06157@localhost.localdomain>
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

Federico Mena Quintero wrote:
> 
> Doug Royer <Doug@royer.com> writes:
> 
> > 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).
> [...]
> 
> >  W-25 Remove MUST from UID in 4.8.4.7         Y
> 
> Does this mean making UIDs not mandatory for calendar components?
> That would seem to be highly broken to me.  How do you identify them
> otherwise?
> 
>   Federico

A reply to a request from a CS via CAP can contain a componet, the data
returned in that component can be a subset of all of the data a VEVENT
(for example).  If the CUA did a request and did not ask for a UID, then
it should not be returned. As in:

	CUA asks give me all DESCRIPTIONs from VEVENTs with a VALARM for
	today.	No UID asked for, none should be given back, as the CUA
	did not ask for UID, just DESCRIPTION.

	The above example is valid in CAP, but not in iTIP. A MUST
	is already in iTIP, and it needs to be removed from iCal so
	that it is not a MUST in CAP.

The restriction tables are in iTIP for scheduling, and CAP for direct
booking. The restrictions for CAP are not the same as for iTIP.

-Doug


From owner-ietf-calendar@mail.imc.org  Mon Jul 10 01:11:02 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17399
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 01:11:02 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id VAA12437
	for ietf-calendar-bks; Sun, 9 Jul 2000 21:54:49 -0700 (PDT)
Received: from equinox.law.columbia.edu (equinox.law.columbia.edu [128.59.176.141])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA12433
	for <ietf-calendar@imc.org>; Sun, 9 Jul 2000 21:54:47 -0700 (PDT)
From: hmaitre@law.columbia.edu
Subject: Heather Maitre is out of the office today
To: ietf-calendar@imc.org
Message-ID: <OF54CB3804.F5433AD0-ON85256918.001B8C21@law.columbia.edu>
Date: Mon, 10 Jul 2000 01:00:53 -0400
X-MIMETrack: Serialize by Router on equinox/CLS(Release 5.0.4 |June 8, 2000) at 07/10/2000
 01:00:59 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>

I will be out of the office starting  07/07/2000 and will not return until
07/18/2000.

If your inquiry can wait until my return, I will be sure to get back to you
then. If your inquiry requires immediate attention, alternate options are
below:
*for a computer problem contact the Administrative Technology Group
directly at 854-1370 (or e-mail Helpdesk@law.columbia.edu);
*if you have reported your computer problem and it needs escalation, or if
you have something else that requires managerial attention, contact Frantz
Merine, Associate Director of IT, at 854-4056.




From owner-ietf-calendar@mail.imc.org  Mon Jul 10 11:05:39 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11894
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 11:05:37 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA26903
	for ietf-calendar-bks; Mon, 10 Jul 2000 07:48:15 -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 HAA26898
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 07:48:06 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: W-29: Import/Export
X-Mailer: Lotus Notes Build V60_07042000 July 04, 2000
Message-ID: <OF2C3B3C18.1A05DECC-ON85256918.00515560@iris.com>
Date: Mon, 10 Jul 2000 10:51:08 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 10:48:33 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 10:48:33 AM,
	Serialize complete at 07/10/2000 10:48:33 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 10:48:34 AM,
	S/MIME Sign complete at 07/10/2000 10:48:34 AM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/10/2000
 10:53:24 AM,
	Serialize complete at 07/10/2000 10:53:24 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z13063_boundary_sign
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 an S/MIME signed message.

---------z13063_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 005159B685256918_="

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

Im very curious this AM so either Im having a brain fart due to my 253+ 
emails this AM or Im just getting undercaffinated.  In the latest AI list 
I found:

 W-29 Import/Export  Y - sync only

Im glad that its "done" but I dont recall any traffic or talk of this on 
the list at all.  At least we did have some about 3 months back but we had 
identified a case where it would not work and needed fixing.  So, I 
searched the archive I have for "sync" and found no real talk of this 
item.  Can someone send me a subject pointer or summary of where we 
defined "sync only" and what the changes were to allow for this?? 

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 005159B685256918_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Im very curious this AM so either Im having a brain fart due to my 253+ emails this AM or Im just getting undercaffinated. &nbsp;In the latest AI list I found:</font>
<br>
<br><font size=2 face="Courier New">&nbsp;W-29 Import/Export &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; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Y - sync only<br>
</font>
<br><font size=2 face="sans-serif">Im glad that its &quot;done&quot; but I dont recall any traffic or talk of this on the list at all. &nbsp;At least we did have some about 3 months back but we had identified a case where it would not work and needed fixing. &nbsp;So, I searched the archive I have for &quot;sync&quot; and found no real talk of this item. &nbsp;Can someone send me a subject pointer or summary of where we defined &quot;sync only&quot; and what the changes were to allow for this?? &nbsp;</font>
<br><font size=2 face="sans-serif"><br>
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 005159B685256918_=--

---------z13063_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDcxMDE0NDgzNFowIwYJKoZIhvcNAQkEMRYEFNXTXfyuCGqH
vrzIVBx6U7855wwyMA0GCSqGSIb3DQEBAQUABEC/XTH+A19hBoVrx1bzLnC2IG+ojqzC85d4ukFG
TK6t1qC+ORPqDmQDxuMXdKoY9iwCnrfi/w/ddDUx8ThyDHar

---------z13063_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Mon Jul 10 11:06:09 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11931
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 11:06:02 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA26897
	for ietf-calendar-bks; Mon, 10 Jul 2000 07:48:06 -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 HAA26886
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 07:48:00 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: I-4: ALARMID?
X-Mailer: Lotus Notes Build V60_07042000 July 04, 2000
Message-ID: <OF5ADEB4D7.E82515A1-ON85256918.0050FBDB@iris.com>
Date: Mon, 10 Jul 2000 10:47:48 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 10:45:13 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 10:45:13 AM,
	Serialize complete at 07/10/2000 10:45:13 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 10:45:14 AM,
	S/MIME Sign complete at 07/10/2000 10:45:14 AM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/10/2000
 10:53:14 AM,
	Serialize complete at 07/10/2000 10:53:14 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z13843_boundary_sign
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 an S/MIME signed message.

---------z13843_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00510B6F85256918_="

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

While coming up for some air I skimmed the latest AI list.  I found one 
entry that Im curious about:

I-4 Add ALARMID to VALARM ?                                              Y

Im curious about this since A) we covered IDs for alarms many many moon 
ago and B) I dont recall any traffic this topic for the list.

The last time we put this issue to rest we had agreement that since alarms 
were not stand alone critters they didnt need their own IDs.  It appears 
as if someone is resurecting this.  Can someone enlighten me as to where 
this came from and how it can be Done w/o any group discussion?? 

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


<br><font size=2 face="sans-serif">While coming up for some air I skimmed the latest AI list. &nbsp;I found one entry that Im curious about:</font>
<br>
<br><font size=2 face="Courier New">I-4 Add ALARMID to VALARM ? &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; Y</font>
<br>
<br><font size=2 face="sans-serif">Im curious about this since A) we covered IDs for alarms many many moon ago and B) I dont recall any traffic this topic for the list.</font>
<br>
<br><font size=2 face="sans-serif">The last time we put this issue to rest we had agreement that since alarms were not stand alone critters they didnt need their own IDs. &nbsp;It appears as if someone is resurecting this. &nbsp;Can someone enlighten me as to where this came from and how it can be Done w/o any group discussion?? &nbsp;</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 00510B6F85256918_=--

---------z13843_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDcxMDE0NDUxM1owIwYJKoZIhvcNAQkEMRYEFFcAdR4UA0Ad
t2CP1aoL+omtvHJrMA0GCSqGSIb3DQEBAQUABEDB6yJ9WShFw6S7GGKpkD2ymySVD+MChnsKUJwR
RVWl+Gr+JSmkmJ7hbRu9i0nii+v566BuWUFHJOhVAzifK9iO

---------z13843_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Mon Jul 10 11:15:54 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12435
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 11:15:50 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA27097
	for ietf-calendar-bks; Mon, 10 Jul 2000 07:55:29 -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 HAA27092
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 07:55:26 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: Suggestion for Action Items handling
X-Mailer: Lotus Notes Build V60_07042000 July 04, 2000
Message-ID: <OFC24DEB7F.CE910493-ON85256918.0051F930@iris.com>
Date: Mon, 10 Jul 2000 11:00:14 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 10:57:40 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 10:57:40 AM,
	Serialize complete at 07/10/2000 10:57:40 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 10:57:40 AM,
	S/MIME Sign complete at 07/10/2000 10:57:40 AM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/10/2000
 11:00:40 AM,
	Serialize complete at 07/10/2000 11:00:40 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z2604_boundary_sign
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 an S/MIME signed message.

---------z2604_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 00522F1185256918_="

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

  In order to make it easier for folks (new or old hands) to find out 
when/how an Action Item was resolved (or at least where we reached our 
final answer), Id like to suggest that some (Doug??) 'tag' the 
thread/posting as relating to that Action Item.  For example, instead of 
wading thru 15 "Re: NOOP" and "Re: NOOP again", etc it to find a 
resolution response, can someone (ie: Doug or the WG cochairs) please 
'tag' or send a final response to the WG like "W-31 NOOP command: 
Resolution (was Re: Re[2]: NOOP yet again...)"

  Even w/the ability to have full text indexing like I do, a FT index is 
usually weighted by score rather than by "most recent first" (otherwise 
its not that great a FT indexer).    Does this sound like a good 
suggestion?  Who would be willing to take that mantle for now: Doug, Pat, 
Paul???

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


<br><font size=2 face="sans-serif">&nbsp; In order to make it easier for folks (new or old hands) to find out when/how an Action Item was resolved (or at least where we reached our final answer), Id like to suggest that some (Doug??) 'tag' the thread/posting as relating to that Action Item. &nbsp;For example, instead of wading thru 15 &quot;Re: NOOP&quot; and &quot;Re: NOOP again&quot;, etc it to find a resolution response, can someone (ie: Doug or the WG cochairs) please 'tag' or send a final response to the WG like &quot;W-31 NOOP command: Resolution (was Re: Re[2]: NOOP yet again...)&quot;</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; Even w/the ability to have full text indexing like I do, a FT index is usually weighted by score rather than by &quot;most recent first&quot; (otherwise its not that great a FT indexer). &nbsp; &nbsp;Does this sound like a good suggestion? &nbsp;Who would be willing to take that mantle for now: Doug, Pat, Paul???</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 00522F1185256918_=--

---------z2604_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDcxMDE0NTc0MFowIwYJKoZIhvcNAQkEMRYEFOH3LbY8EPgp
/EdtBiHACshiXwMrMA0GCSqGSIb3DQEBAQUABECNHH7M56yKk6SZp9UNcXDKIPD975f7DMeIjp6r
FYx2Xe1KRhLdfQpD0UDnt7DIsRZDQthvJL2VbX1+OmIuzLRk

---------z2604_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Mon Jul 10 11:32:48 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13397
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 11:32:46 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA26998
	for ietf-calendar-bks; Mon, 10 Jul 2000 07:51:53 -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 HAA26983
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 07:51:47 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: ietf-calendar@imc.org
Subject: AI list needs reordering?
X-Mailer: Lotus Notes Build V60_07042000 July 04, 2000
Message-ID: <OF3A39B423.47E83F16-ON85256918.0051A9D4@iris.com>
Date: Mon, 10 Jul 2000 10:55:17 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/10/2000
 10:57:03 AM,
	Serialize complete at 07/10/2000 10:57:03 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0051BAF085256918_="
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 0051BAF085256918_=
Content-Type: text/plain; charset="us-ascii"

This is kind of targeted to our esteemed AI maintainer (Thanks again 
Doug!) but Im curious why so many W-# (ie: W-1, W-2, W-3, W-5, W-7, W-8, 
W-9,...) are categorized as WG items rather than CAP editor items?  Is 
that because we as a WG need to collectively write them?  Or should they 
be reclassified as C-# instead?  Just curious since Im playing a bit of 
technical catchup after some heaving coding and a long weekend...

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


<br><font size=2 face="sans-serif">This is kind of targeted to our esteemed AI maintainer (Thanks again Doug!) but Im curious why so many W-# (ie: W-1, W-2, W-3, W-5, W-7, W-8, W-9,...) are categorized as WG items rather than CAP editor items? &nbsp;Is that because we as a WG need to collectively write them? &nbsp;Or should they be reclassified as C-# instead? &nbsp;Just curious since Im playing a bit of technical catchup after some heaving coding and a long weekend...</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 0051BAF085256918_=--


From owner-ietf-calendar@mail.imc.org  Mon Jul 10 13:11:00 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17596
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 13:10:57 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA03642
	for ietf-calendar-bks; Mon, 10 Jul 2000 09:49:41 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03638
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 09:49:40 -0700 (PDT)
Received: from Software.com ([207.175.94.239]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000710165151.FNKH459995.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 11:51:51 -0500
Message-ID: <3969EE62.FE04E642@Software.com>
Date: Mon, 10 Jul 2000 08:40:18 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: ietf-calendar@imc.org
Subject: Re: I-4: ALARMID?
References: <OF5ADEB4D7.E82515A1-ON85256918.0050FBDB@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE1C9E457F7532D7CBC1A20D7"
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 cryptographically signed message in MIME format.

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

Bruce_Kahn@iris.com wrote:
> 
> While coming up for some air I skimmed the latest AI list.  I found one
> entry that Im curious about:
> 
> I-4 Add ALARMID to VALARM ?
>     Y
> 
> Im curious about this since A) we covered IDs for alarms many many moon
> ago and B) I dont recall any traffic this topic for the list.
> 
> The last time we put this issue to rest we had agreement that since
> alarms were not stand alone critters they didnt need their own IDs.  It
> appears as if someone is resurecting this.  Can someone enlighten me as
> to where this came from and how it can be Done w/o any group discussion??

It was on the list or at an IETF meeting - I forget which.

ALARMID's are needed CAP because it would be impossible to
modify an alarm without being able to identify which of multiple
alarms in a component would be the target of the METHOD:MODIFY.

-Doug
--------------msE1C9E457F7532D7CBC1A20D7
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI
AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh
3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe
BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg
Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ
YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4
NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi
ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4
RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig
JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA
A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK
GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh
/D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u
DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL
Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC
LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI
4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO
f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH
BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI
hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF
pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8
kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut
FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDcxMDE1NDAxOVowIwYJKoZIhvcNAQkEMRYEFHDjTsW1QUAKezel7B9AYN7x8rgw
MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH
MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEA812Qxpdn3
uHZ4FA8MOQgiZIYy7A2AAgMGq31KkrYPat6jpo2aNVokZ5stPEJRY/XHsvr0Y2rvQqeky0+T
3Fzg
--------------msE1C9E457F7532D7CBC1A20D7--



From owner-ietf-calendar@mail.imc.org  Mon Jul 10 13:11:03 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17606
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 13:11:00 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA03411
	for ietf-calendar-bks; Mon, 10 Jul 2000 09:46:10 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03403
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 09:46:09 -0700 (PDT)
Received: from Software.com ([207.175.94.239]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000710164819.FNGK459995.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 11:48:19 -0500
Message-ID: <3969ED90.61A319F6@Software.com>
Date: Mon, 10 Jul 2000 08:36:48 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: ietf-calendar@imc.org
Subject: Re: W-29: Import/Export
References: <OF2C3B3C18.1A05DECC-ON85256918.00515560@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5803D19D520D23F52869F923"
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 cryptographically signed message in MIME format.

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

Bruce_Kahn@iris.com wrote:
> 
> Im very curious this AM so either Im having a brain fart due to my 253+
> emails this AM or Im just getting undercaffinated.  In the latest AI list
> I found:
> 
>  W-29 Import/Export
>              Y - sync only
> 
> Im glad that its "done" but I dont recall any traffic or talk of this on
> the list at all.  At least we did have some about 3 months back but we
> had identified a case where it would not work and needed fixing.  So, I
> searched the archive I have for "sync" and found no real talk of this
> item.  Can someone send me a subject pointer or summary of where we
> defined "sync only" and what the changes were to allow for this??

In the requirements doc, we will only be doing what is needed
to sync-CUA's to CS's. Export/Import is explicitly a vendor
specific thing (At this time). So it was dropped from CAP
as import/export. However synching with disconnected devices
was kept - per the requirements doc.

-Doug
--------------ms5803D19D520D23F52869F923
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI
AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh
3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe
BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg
Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ
YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4
NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi
ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4
RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig
JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA
A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK
GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh
/D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u
DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL
Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC
LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI
4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO
f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH
BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI
hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF
pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8
kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut
FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDcxMDE1MzY0OFowIwYJKoZIhvcNAQkEMRYEFDhaZwtEdCCiRKEzi7eHS9FXpaU1
MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH
MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEBU6u4vj9ym
+2b3zEAAMDWXzyH3BcvlsjtQ+pS+GmWEMy2TP7t7Jh54rjk2HSuMwoMSUGZT1AL9acZx/3BR
C4Ht
--------------ms5803D19D520D23F52869F923--



From owner-ietf-calendar@mail.imc.org  Mon Jul 10 13:11:04 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17620
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 13:11:01 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA03823
	for ietf-calendar-bks; Mon, 10 Jul 2000 09:52:29 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03812
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 09:52:26 -0700 (PDT)
Received: from Software.com ([207.175.94.239]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000710165437.FNNF459995.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 11:54:37 -0500
Message-ID: <3969EF09.C5780C50@Software.com>
Date: Mon, 10 Jul 2000 08:43:05 -0700
From: Doug Royer <Doug.Royer@software.com>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
CC: ietf-calendar@imc.org
Subject: Re: Suggestion for Action Items handling
References: <OFC24DEB7F.CE910493-ON85256918.0051F930@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms613A479667FBD167616BEF15"
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 cryptographically signed message in MIME format.

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

Bruce_Kahn@iris.com wrote:
> 
>   In order to make it easier for folks (new or old hands) to find out
> when/how an Action Item was resolved (or at least where we reached our
> final answer), Id like to suggest that some (Doug??) 'tag' the
> thread/posting as relating to that Action Item.  For example, instead of
> wading thru 15 "Re: NOOP" and "Re: NOOP again", etc it to find a
> resolution response, can someone (ie: Doug or the WG cochairs) please
> 'tag' or send a final response to the WG like "W-31 NOOP command:
> Resolution (was Re: Re[2]: NOOP yet again...)"
> 
>   Even w/the ability to have full text indexing like I do, a FT index is
> usually weighted by score rather than by "most recent first" (otherwise
> its not that great a FT indexer).    Does this sound like a good
> suggestion?  Who would be willing to take that mantle for now: Doug, Pat,
> Paul???

I would think that a chair would need to do this.

Have you tried sorting the threads by date? I would think that the
last one would be a good bet.

-Doug
--------------ms613A479667FBD167616BEF15
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI
AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh
3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe
BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg
Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ
YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4
NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi
ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4
RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig
JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA
A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK
GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh
/D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u
DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL
Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC
LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI
4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO
f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH
BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI
hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF
pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8
kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut
FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDcxMDE1NDMwNlowIwYJKoZIhvcNAQkEMRYEFAHSBB/QuxwUehEuH5C1PImKZZD3
MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH
MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEB5F4A8+5cZ
z7P/0tIqGA1MVHYsrWDgyqpPmikszAjzeTQ6rtojoMw6QJQr3WJYd62qP4/SeA6Bll0T4Y90
pwNC
--------------ms613A479667FBD167616BEF15--



From owner-ietf-calendar@mail.imc.org  Mon Jul 10 13:13:25 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17779
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 13:13:22 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA04192
	for ietf-calendar-bks; Mon, 10 Jul 2000 09:56:30 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04185
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 09:56:29 -0700 (PDT)
Received: from Software.com ([207.175.94.239]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000710165840.FNUG459995.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 11:58:40 -0500
Message-ID: <3969EFFC.475B974F@Software.com>
Date: Mon, 10 Jul 2000 08:47:08 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: AI list needs reordering?
References: <OF3A39B423.47E83F16-ON85256918.0051A9D4@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4FA0A56F04D001486C36264D"
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 cryptographically signed message in MIME format.

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

Bruce_Kahn@iris.com wrote:
> 
> This is kind of targeted to our esteemed AI maintainer (Thanks again
> Doug!) but Im curious why so many W-# (ie: W-1, W-2, W-3, W-5, W-7, W-8,
> W-9,...) are categorized as WG items rather than CAP editor items?

They start off as WG items until the WG decides.
Then if they do not get done (As I happen to notice) they
may be moved to the editors list.

I would be more than *happy* if others were to add items to the lists.
I will edit the list as fast as I see the additions/changes - once
approved by the chair on the WG list.

>  Is
> that because we as a WG need to collectively write them?  Or should they
> be reclassified as C-# instead?  Just curious since Im playing a bit of
> technical catchup after some heaving coding and a long weekend...

We decided not to remove old ones so the issues do not keep coming up.
So if you want some new C-#'s -->> send them :-)

So far it has been me tracking issues I remember or wish fixed. I would
be extremely happy if others (collectively) added to the list.

-Doug
--------------ms4FA0A56F04D001486C36264D
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI
AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh
3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe
BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg
Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ
YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4
NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi
ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4
RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig
JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA
A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK
GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh
/D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u
DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL
Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC
LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI
4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO
f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH
BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI
hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF
pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8
kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut
FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDcxMDE1NDcwOFowIwYJKoZIhvcNAQkEMRYEFBCLX7BlDDR0x7usKC7ii1tYAomj
MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH
MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEBSxj1JHd7S
O4JEVbZKcI6nJvw6c0c9KAZsYHXyUUggj4AE8t8kQCzzfPH1HFhT1VOK+2NXqAmo3pQ23K7y
ja3H
--------------ms4FA0A56F04D001486C36264D--



From owner-ietf-calendar@mail.imc.org  Mon Jul 10 15:49:09 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26129
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 15:49:07 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA09234
	for ietf-calendar-bks; Mon, 10 Jul 2000 12:29:26 -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 MAA09225
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 12:29:18 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: Re: AI list needs reordering?
X-Mailer: Lotus Notes Build V60_07042000 July 04, 2000
Message-ID: <OFD5E563F6.E2715F14-ON85256918.006AF2F3@iris.com>
Date: Mon, 10 Jul 2000 15:34:14 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 03:31:23 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 03:31:23 PM,
	Serialize complete at 07/10/2000 03:31:23 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 03:31:24 PM,
	S/MIME Sign complete at 07/10/2000 03:31:24 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/10/2000
 03:31:11 PM,
	Serialize complete at 07/10/2000 03:31:12 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/10/2000
 03:31:12 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z3115_boundary_sign
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 an S/MIME signed message.

---------z3115_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 006B3E9E85256918_="

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

Doug replied in part with:
>They start off as WG items until the WG decides.
>Then if they do not get done (As I happen to notice) they
>may be moved to the editors list.

Thanks for the clarification.  I thought it may be something like that but 
I could not find any msgs in the archive about how AIs were to be 
classified so I thought Id play it safe and ask to be sure.

>We decided not to remove old ones so the issues do not keep coming up.

Just to clarify a possible misconception: I was _not_ asking for the 
issues to be removed, just if the CAP issues did not belong under C- 
instead of W- to start with...

>We decided not to remove old ones so the issues do not keep coming up.

A sensible course of action.  Now all that we need for newer folks is some 
way to link the Y/N/D/U decision to a thread or set of threads in the 
archive.  Hence my other posting about tagging AI decisions by the 
chairs...  (FT searching is not 100% accurate and thread searching for, 
say, W-8 lends to much frustration since the official archives are not 
easily searched that way).

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


<br><font size=2 face="sans-serif">Doug replied in part with:</font>
<br><font size=2 face="Courier New">&gt;They start off as WG items until the WG decides.<br>
&gt;Then if they do not get done (As I happen to notice) they<br>
&gt;may be moved to the editors list.</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the clarification. &nbsp;I thought it may be something like that but I could not find any msgs in the archive about how AIs were to be classified so I thought Id play it safe and ask to be sure.</font>
<br>
<br><font size=2 face="Courier New">&gt;We decided not to remove old ones so the issues do not keep coming up.</font>
<br>
<br><font size=2 face="sans-serif">Just to clarify a possible misconception: I was _not_ asking for the issues to be removed, just if the CAP issues did not belong under C- instead of W- to start with...</font>
<br>
<br><font size=2 face="Courier New">&gt;We decided not to remove old ones so the issues do not keep coming up.<br>
</font>
<br><font size=2 face="sans-serif">A sensible course of action. &nbsp;Now all that we need for newer folks is some way to link the Y/N/D/U decision to a thread or set of threads in the archive. &nbsp;Hence my other posting about tagging AI decisions by the chairs... &nbsp;(FT searching is not 100% accurate and thread searching for, say, W-8 lends to much frustration since the official archives are not easily searched that way).</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>
<br>
--=_alternative 006B3E9E85256918_=--

---------z3115_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDcxMDE5MzEyNFowIwYJKoZIhvcNAQkEMRYEFCEKw/8FiIr2
FPcBPyhefpkcQsgyMA0GCSqGSIb3DQEBAQUABEDRqea0en1ykkzvE6Yx91g73YRG6slMrl8pI75I
n/fIgYjH6GBy6DLmBCmD3q+BO8bzu5GhsKf9syIHreOhYNZG

---------z3115_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Mon Jul 10 15:49:58 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26188
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 15:49:56 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08736
	for ietf-calendar-bks; Mon, 10 Jul 2000 12:18: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 MAA08732
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 12:18:11 -0700 (PDT)
Received: (from sman@localhost)
	by royer.com (8.9.1/8.9.1) id MAA18013
	for ietf-calendar@imc.org; Mon, 10 Jul 2000 12:19:57 -0700 (PDT)
Date: Mon, 10 Jul 2000 12:19:57 -0700 (PDT)
From: Steve Mansour <sman@royer.com>
Message-Id: <200007101919.MAA18013@royer.com>
To: ietf-calendar@imc.org
Subject: CAP draft update
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>


The CAP draft files have been updated on:

	ftp://royer.com/pub/CALSCH

The current cap drafit is:

	ftp://royer.com/pub/CALSCH/cap.txt.gz

Nroff and other source files including cap.txt:

	ftp://royer.com/pub/CALSCH/sources.tar.gz
	


From owner-ietf-calendar@mail.imc.org  Mon Jul 10 16:20:00 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27072
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 16:20:00 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA10004
	for ietf-calendar-bks; Mon, 10 Jul 2000 13:01:41 -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 NAA10000
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 13:01:40 -0700 (PDT)
Received: (from sman@localhost)
	by royer.com (8.9.1/8.9.1) id NAA18991
	for ietf-calendar@imc.org; Mon, 10 Jul 2000 13:03:27 -0700 (PDT)
Date: Mon, 10 Jul 2000 13:03:27 -0700 (PDT)
From: Steve Mansour <sman@royer.com>
Message-Id: <200007102003.NAA18991@royer.com>
To: ietf-calendar@imc.org
Subject: CAP draft update
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>


The CAP draft files have been updated on:

	ftp://royer.com/pub/CALSCH

The current cap drafit is:

	ftp://royer.com/pub/CALSCH/cap.txt.gz

Nroff and other source files including cap.txt:

	ftp://royer.com/pub/CALSCH/sources.tar.gz
	


From owner-ietf-calendar@mail.imc.org  Mon Jul 10 16:42:19 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27737
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 16:42:18 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA10420
	for ietf-calendar-bks; Mon, 10 Jul 2000 13:23:30 -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 NAA10415
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 13:23:19 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: Re: W-29: Import/Export
X-Mailer: Lotus Notes Build V60_07042000 July 04, 2000
Message-ID: <OF0BDCC5DB.866CBACB-ON85256918.006F1DB3@iris.com>
Date: Mon, 10 Jul 2000 16:28:14 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 04:25:24 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 04:25:24 PM,
	Serialize complete at 07/10/2000 04:25:24 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/10/2000 04:25:25 PM,
	S/MIME Sign complete at 07/10/2000 04:25:25 PM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/10/2000
 04:25:12 PM,
	Serialize complete at 07/10/2000 04:25:12 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z14791_boundary_sign
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 an S/MIME signed message.

---------z14791_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0070306785256918_="

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

Doug informed me:

>In the requirements doc, we will only be doing what is needed
>to sync-CUA's to CS's. Export/Import is explicitly a vendor
>specific thing (At this time). So it was dropped from CAP
>as import/export. However synching with disconnected devices
>was kept - per the requirements doc.

First tidbit: the requirements doc is expired.  It must be reissued or we 
cannot use it as a yardstick in discussions since its out of date and not 
'official' any more in IETF eyes.

I tried to get a copy but I didnt have a local copy and it seems that the 
CalSched WG maintainer is efficient and removed the expired copy on 
20-Mar-2000.  Can the author(s) please resubmit it to both the WG archives 
and to the IETF Drafts Editor(s). (Doug: Make this a new Action Item for 
the requirements editors please!)

I decided to do some serious diving on the sync topic since this is one 
thats another nuclear blast furnace of issues that stirs many folks up.  I 
found that the WG has not really addressed the issue when its been asked 
several times.  As far back as 06-May-1997, Peter Orbaek asked about 
synchronization and was told to read ICAP.  Later, on 03-Mar-1998 Patrik 
Olsson asked about it and was deflected to other sites.  When the CAP reqs 
were flagged by Andre and Mark D. Anderson back in late November 1998 as "There should be some discussion of how an automatic synchronization could 
be done.", Steve Mansour summed up a general editors (and possibly others) 
philosophy with:

We are leaving it up to the CUAs to handle
synchronization. We've tried to word the requirements to say that CAP must 
provide
sufficient functions to support a CUA that wishes to do synchronization 
work.

As of the last draft of CAP I read (before the DC IETF) I saw no such 
discussion or consideration in the design so I asked about it both in DC 
and on the WG list on 27-Dec-1999 ("Does CAP address synchronization?").  We did not cover this touch subject 
in DC and there was a roaring silence from any CAP editors or proponents 
answering my post.  So, in order to answer the constant questions we need 
A) a revised and reissued CAP requirents doc and B) some discussion of how 
CAP can do this (perhaps an example or two since none existed prior to the 
DC meeting when I least dived all the way into CAP.)...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0070306785256918_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Doug informed me:</font>
<br>
<br><font size=2 face="Courier New">&gt;In the requirements doc, we will only be doing what is needed<br>
&gt;to sync-CUA's to CS's. Export/Import is explicitly a vendor<br>
&gt;specific thing (At this time). So it was dropped from CAP<br>
&gt;as import/export. However synching with disconnected devices<br>
&gt;was kept - per the requirements doc.</font>
<br>
<br><font size=2 face="sans-serif">First tidbit: the requirements doc is expired. &nbsp;It must be reissued or we cannot use it as a yardstick in discussions since its out of date and not 'official' any more in IETF eyes.</font>
<br>
<br><font size=2 face="sans-serif">I tried to get a copy but I didnt have a local copy and it seems that the CalSched WG maintainer is efficient and removed the expired copy on 20-Mar-2000. &nbsp;Can the author(s) please resubmit it to both the WG archives and to the IETF Drafts Editor(s). (Doug: Make this a new Action Item for the requirements editors please!)</font>
<br>
<br><font size=2 face="sans-serif">I decided to do some serious diving on the sync topic since this is one thats another nuclear blast furnace of issues that stirs many folks up. &nbsp;I found that the WG has not really addressed the issue when its been asked several times. &nbsp;As far back as 06-May-1997, Peter Orbaek asked about synchronization and was told to read ICAP. &nbsp;Later, on 03-Mar-1998 Patrik Olsson asked about it and was deflected to other sites. &nbsp;When the CAP reqs were flagged by Andre and Mark D. Anderson back in late November 1998 as &quot;</font><font size=2><tt>There should be some discussion of how an automatic synchronization could be done.</tt></font><font size=2 face="sans-serif">&quot;, Steve Mansour summed up a general editors (and possibly others) philosophy with:</font>
<br>
<br><font size=2><tt>We are leaving it up to the CUAs to handle<br>
synchronization. We've tried to word the requirements to say that CAP must provide<br>
sufficient functions to support a CUA that wishes to do synchronization work.</tt></font>
<br>
<br><font size=2 face="sans-serif">As of the last draft of CAP I read (before the DC IETF) I saw no such discussion or consideration in the design so I asked about it both in DC and on the WG list on 27-Dec-1999 (&quot;Does CAP address synchronization?&quot;). &nbsp;We did not cover this touch subject in DC and there was a roaring silence from any CAP editors or proponents answering my post. &nbsp;So, in order to answer the constant questions we need A) a revised and reissued CAP requirents doc and B) some discussion of how CAP can do this (perhaps an example or two since none existed prior to the DC meeting when I least dived all the way into CAP.)...</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 0070306785256918_=--

---------z14791_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDcxMDIwMjUyNFowIwYJKoZIhvcNAQkEMRYEFDDyYcOk8iAo
5mTMXCB/ZiUy3nNFMA0GCSqGSIb3DQEBAQUABEAon5Y/6HgRJz7pkC1frdMZj6KwAw5iBCxGUMbe
03Y7+GVulwl2IrSD60crVUZn794khnq9/kxKYZnriRCYXPIV

---------z14791_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Mon Jul 10 17:37:01 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29380
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 17:37:00 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id OAA11486
	for ietf-calendar-bks; Mon, 10 Jul 2000 14:15:19 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11482
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 14:15:17 -0700 (PDT)
Received: from Software.com ([207.175.94.239]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000710211725.FXKB459995.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 16:17:25 -0500
Message-ID: <396A2C9A.D3933915@Software.com>
Date: Mon, 10 Jul 2000 13:05:46 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-29: Import/Export
References: <OF0BDCC5DB.866CBACB-ON85256918.006F1DB3@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0F366F90E943512FD019E4C1"
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 cryptographically signed message in MIME format.

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

Bruce_Kahn@iris.com wrote:
> 
> Doug informed me:
> 
> >In the requirements doc, we will only be doing what is needed
> >to sync-CUA's to CS's. Export/Import is explicitly a vendor
> >specific thing (At this time). So it was dropped from CAP
> >as import/export. However synching with disconnected devices
> >was kept - per the requirements doc.
> 
> First tidbit: the requirements doc is expired.  It must be reissued or we
> cannot use it as a yardstick in discussions since its out of date and not
> 'official' any more in IETF eyes.

We can discuss it. We just can't use it in the CAP RFC when released.
We can now because it is a draft.

I am placing a copy on ROYER.COM now. There seems to be some kind
of a problem at this time with FTP to royer.com . A command line
FTP works yet IE and Netscape don't work.

Anyway 	ftp://Royer.com/pub/CALSCH/capreq.txt

> (Doug: Make this a new Action
> Item for the requirements editors please!)

 C-21 Resubmit REQUIREMENTS draft.

I have renamed the 'C' section to just be EDITOR action items.
(Not specifically CAP).
 
> I decided to do some serious diving on the sync topic since this is one
> thats another nuclear blast furnace of issues that stirs many folks up.
>  I found that the WG has not really addressed the issue when its been
> asked several times.  As far back as 06-May-1997, Peter Orbaek asked
> about synchronization and was told to read ICAP.  Later, on 03-Mar-1998
> Patrik Olsson asked about it and was deflected to other sites.  When the
> CAP reqs were flagged by Andre and Mark D. Anderson back in late November
> 1998 as "There should be some discussion of how an automatic
> synchronization could be done.", Steve Mansour summed up a general
> editors (and possibly others) philosophy with:
> 
> We are leaving it up to the CUAs to handle
>  We've tried to word the requirements to say that CAP
> must provide
> sufficient functions to support a CUA that wishes to do synchronization
> work.

See capreq.txt - synchronization. is covered, and import/export is not.

> As of the last draft of CAP I read (before the DC IETF) I saw no such
> discussion or consideration in the design so I asked about it both in DC
> and on the WG list on 27-Dec-1999 ("Does CAP address synchronization?").

Somehow the archive is incomplete or the meeting notes are incomplete.
We have covered this several times.

>  We did not cover this touch subject in DC and there was a roaring
> silence from any CAP editors or proponents answering my post.

I seem to have recalled that we covered this many times.
I am starting to look at the archives now.

>  So, in
> order to answer the constant questions we need A) a revised and reissued
> CAP requirents doc and B) some discussion of how CAP can do this (perhaps
> an example or two since none existed prior to the DC meeting when I least
> dived all the way into CAP.)...

The way we had addressed synchronization was we allowed the disconnected
device (or any CUA) to QUERY for any date range (including all). And we
allow
the disconnect device (or any CUA) to modify any entries.
Thus allowing ANY component to be updated by or synchronized with a CUA.

The CUA + the user do the actual synchronization of the data. The CS
simply allows the CUA to ask for and modify any component.

And as those are features already in CAP we had agreed there did not 
need to be any new features to support synchronization.

(As a side note, many were going to use these ask for all data
and the ability to modify any data, as their method to import/export.)

-Doug
--------------ms0F366F90E943512FD019E4C1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI
AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh
3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe
BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg
Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ
YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4
NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi
ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4
RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig
JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA
A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK
GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh
/D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u
DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL
Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC
LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI
4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO
f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH
BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI
hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF
pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8
kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut
FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDcxMDIwMDU0OVowIwYJKoZIhvcNAQkEMRYEFHC+t/w4vPwIeyxMcCqADBYBrbKi
MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH
MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEDQ4K1MQOqh
zbJfkr6ZbWK2MlJDBQGGmWS5xFERwRZ0Y3ed2Lei7Z3pLWUkaN/DKmpJIPlgRYV3GOcY7Dwi
P5YV
--------------ms0F366F90E943512FD019E4C1--



From owner-ietf-calendar@mail.imc.org  Mon Jul 10 21:34:54 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04008
	for <calsch-archive@odin.ietf.org>; Mon, 10 Jul 2000 21:34:53 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id SAA17365
	for ietf-calendar-bks; Mon, 10 Jul 2000 18:17:29 -0700 (PDT)
Received: from imta0102.cdpd.airdata.com ([199.88.234.52])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17359
	for <ietf-calendar@imc.org>; Mon, 10 Jul 2000 18:17:28 -0700 (PDT)
Received: from app0101.cdpd.airdata.com by imta0102.cdpd.airdata.com for ietf-calendar@imc.org; Mon, 10 Jul 2000 18:18:43 -0700
Message-Id: <app0101.cdpd.airdata.com.646351@mobile.att.net>
Date: Mon, 10 Jul 2000 18:18:08 -0700
Subject: ftp to Royer.com
Content-Type: text/plain; charset=ISO-8859-1
Mime-Version: 1.0
From: doug.royer@mobile.att.net (Doug Royer)
To: ietf-calendar@imc.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id SAA17360
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: 8bit

it is working now.



From owner-ietf-calendar@mail.imc.org  Tue Jul 11 23:18:44 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28013
	for <calsch-archive@odin.ietf.org>; Tue, 11 Jul 2000 23:18:44 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id TAA15204
	for ietf-calendar-bks; Tue, 11 Jul 2000 19:52:06 -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 TAA15180
	for <ietf-calendar@imc.org>; Tue, 11 Jul 2000 19:51:54 -0700 (PDT)
From: pregen@egenconsulting.com
To: Doug Royer <Doug.Royer@software.com>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: Suggestion for Action Items handling
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF041225CA.B7B4A862-ON8525691A.000FDF4E@com>
Date: Tue, 11 Jul 2000 22:53:45 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 07/11/2000 10:53:57 PM,
	Serialize complete at 07/11/2000 10:53:57 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 000FD1498525691A_="
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 000FD1498525691A_=
Content-Type: text/plain; charset="us-ascii"

I think we can do this, but I think I need a bit more clarification on 
just what you'd like to see.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652




Doug Royer <Doug.Royer@software.com>
Sent by: owner-ietf-calendar@mail.imc.org
07/10/00 11:43 AM

 
        To:     ietf-calendar@imc.org
        cc:     ietf-calendar@imc.org
        Subject:        Re: Suggestion for Action Items handling

Bruce_Kahn@iris.com wrote:
> 
>   In order to make it easier for folks (new or old hands) to find out
> when/how an Action Item was resolved (or at least where we reached our
> final answer), Id like to suggest that some (Doug??) 'tag' the
> thread/posting as relating to that Action Item.  For example, instead of
> wading thru 15 "Re: NOOP" and "Re: NOOP again", etc it to find a
> resolution response, can someone (ie: Doug or the WG cochairs) please
> 'tag' or send a final response to the WG like "W-31 NOOP command:
> Resolution (was Re: Re[2]: NOOP yet again...)"
> 
>   Even w/the ability to have full text indexing like I do, a FT index is
> usually weighted by score rather than by "most recent first" (otherwise
> its not that great a FT indexer).    Does this sound like a good
> suggestion?  Who would be willing to take that mantle for now: Doug, 
Pat,
> Paul???

I would think that a chair would need to do this.

Have you tried sorting the threads by date? I would think that the
last one would be a good bet.

-Doug


--=_alternative 000FD1498525691A_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">I think we can do this, but I think I need a bit more clarification on just what you'd like to see.<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>Doug Royer &lt;Doug.Royer@software.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">07/10/00 11:43 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;ietf-calendar@imc.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;ietf-calendar@imc.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Suggestion for Action Items handling</font></table>
<br>
<br><font size=2><tt>Bruce_Kahn@iris.com wrote:<br>
&gt; <br>
&gt; &nbsp; In order to make it easier for folks (new or old hands) to find out<br>
&gt; when/how an Action Item was resolved (or at least where we reached our<br>
&gt; final answer), Id like to suggest that some (Doug??) 'tag' the<br>
&gt; thread/posting as relating to that Action Item. &nbsp;For example, instead of<br>
&gt; wading thru 15 &quot;Re: NOOP&quot; and &quot;Re: NOOP again&quot;, etc it to find a<br>
&gt; resolution response, can someone (ie: Doug or the WG cochairs) please<br>
&gt; 'tag' or send a final response to the WG like &quot;W-31 NOOP command:<br>
&gt; Resolution (was Re: Re[2]: NOOP yet again...)&quot;<br>
&gt; <br>
&gt; &nbsp; Even w/the ability to have full text indexing like I do, a FT index is<br>
&gt; usually weighted by score rather than by &quot;most recent first&quot; (otherwise<br>
&gt; its not that great a FT indexer). &nbsp; &nbsp;Does this sound like a good<br>
&gt; suggestion? &nbsp;Who would be willing to take that mantle for now: Doug, Pat,<br>
&gt; Paul???<br>
<br>
I would think that a chair would need to do this.<br>
<br>
Have you tried sorting the threads by date? I would think that the<br>
last one would be a good bet.<br>
<br>
-Doug</tt></font>
<br>
<br>
--=_alternative 000FD1498525691A_=--


From owner-ietf-calendar@mail.imc.org  Thu Jul 13 01:43:45 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01118
	for <calsch-archive@odin.ietf.org>; Thu, 13 Jul 2000 01:43:44 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id WAA29433
	for ietf-calendar-bks; Wed, 12 Jul 2000 22:24:04 -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 WAA29403
	for <ietf-calendar@imc.org>; Wed, 12 Jul 2000 22:23:51 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: Pittsburg Timeslot
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF25061717.6D3EC091-ON8525691B.001DA7E5@com>
Date: Thu, 13 Jul 2000 01:25:47 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 07/13/2000 01:25:57 AM,
	Serialize complete at 07/13/2000 01:25:57 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 001DACEE8525691B_="
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 001DACEE8525691B_=
Content-Type: text/plain; charset="us-ascii"

This evening, the agenda for the Pittsburg IETF meeting was distributed. 
The Calsch timeslot is 13:00 - 15:00 on Wednesday, 8/2.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
--=_alternative 001DACEE8525691B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">This evening, the agenda for the Pittsburg IETF meeting was distributed. &nbsp;The Calsch timeslot is 13:00 - 15:00 on Wednesday, 8/2.<br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
--=_alternative 001DACEE8525691B_=--


From owner-ietf-calendar@mail.imc.org  Thu Jul 13 13:03:23 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29293
	for <calsch-archive@odin.ietf.org>; Thu, 13 Jul 2000 13:03:22 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA26358
	for ietf-calendar-bks; Thu, 13 Jul 2000 08:11:51 -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 IAA26352
	for <ietf-calendar@imc.org>; Thu, 13 Jul 2000 08:11:44 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: pregen@egenconsulting.com
Cc: Doug Royer <Doug.Royer@software.com>, ietf-calendar@imc.org
Subject: Re: Suggestion for Action Items handling
X-Mailer: Lotus Notes Build V60_07042000 July 04, 2000
Message-ID: <OF0AE28281.4215080C-ON8525691B.0051BE9A@iris.com>
Date: Thu, 13 Jul 2000 11:13:34 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/13/2000 11:14:27 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/13/2000 11:14:27 AM,
	Serialize complete at 07/13/2000 11:14:27 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/13/2000 11:14:28 AM,
	S/MIME Sign complete at 07/13/2000 11:14:28 AM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/13/2000
 11:13:50 AM,
	Serialize complete at 07/13/2000 11:13:50 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z10141_boundary_sign
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 an S/MIME signed message.

---------z10141_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0053B88D8525691B_="

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

Doug suggested:
>Have you tried sorting the threads by date? I would think that the
>last one would be a good bet.

I have but this is not always convenient as there can be several 
occurances of a thread and  depending on how the threads get sorted (by 
ascending/descending date/time, etc) you may not see what you expect. 
Plus, if a thread is NOT prefixed with its Action Item then what is a 
person to search for??  I try to use W-#, etc when Im posting but I 
sometimes forget to do that.

Pat replied:
>I think we can do this, but I think I need a bit more clarification on 
just what you'd like to see.

I thought I explained it in the text I originally sent so Ill rephrase it 
since it must not have been clear enough.

Given:
1: Not all postings on a particular AI are clearly indicated in the 
posting subject (ie: "NOOP?" instead of "W-31 NOOP?" or "W-31 NOOP command?")
2: There can be several disjoint threads on a particular AI that occur at 
various points in time before an AI is considered completed or resolved.

Whereas:

  It is not easy, for several reasons, for anyone scanning the archives or 
threads to find out when/where/what the actual chair decision on a 
particular Action Item (AI) from the weekly AI list.  There should be a 
simple way to at least find the final decision on an AI in the archives.

Proposed:

  When the chair deems an AI to have been resolved (or unresolvable) that 
the chair 'tags' the discussion thread with a posting that indicates the 
AIs status.  This 'tagging' would be a simple email posting to the thread 
that clearly indicates the AI and that the message is how the AI was 
resolved.  This 'tag' would be of the format "AI# & title: Resolution" and 
could be followed by the original subject if desired.

  For example, for a thread that was about the NOOP command (AI "W-31 NOOP 
command") that began as Subject: "NOOP again??" the chair would post a 
message to list with the Subject: "W-31 NOOP command: Resolved" or 
possibly "W-31 NOOP command: Resolved (was Re[3]: NOOP again??"  This 
would make searching the archives for answers MUCH easier as the search 
could be for ": Resolved" or the well known format of "W-31 NOOP command: 
Resolved".

  If multiple AIs are resolved at the same time, they can be comma 
separated before the ": Resolved".  For example: "W-31 NOOP command, W-32 NOOP advisory only: Resolved"

  If folks think this later case may generate subjects that are too long, 
the format could easily be abreviated to just "AI#: Resolved" making the 
multiple case example shortened to just "W-31, W-32: Resolved".  I would suggest that we not abbreviate it down to "W-31,32: Resolved" 
since some search engines can do searches like "W-32 AND Resolved" and 
that would not be matchable in the very shortened case.

  Does this clarify my suggestion??  Would the co-chairs be willing to do 
this?

Bruce
==========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0053B88D8525691B_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Doug suggested:</font>
<br><font size=2 face="Courier New">&gt;Have you tried sorting the threads by date? I would think that the<br>
&gt;last one would be a good bet.</font>
<br>
<br><font size=2 face="sans-serif">I have but this is not always convenient as there can be several occurances of a thread and &nbsp;depending on how the threads get sorted (by ascending/descending date/time, etc) you may not see what you expect. &nbsp;Plus, if a thread is NOT prefixed with its Action Item then what is a person to search for?? &nbsp;I try to use W-#, etc when Im posting but I sometimes forget to do that.</font>
<br>
<br><font size=2 face="sans-serif">Pat replied:</font>
<br><font size=2><tt>&gt;I think we can do this, but I think I need a bit more clarification on just what you'd like to see.</tt></font>
<br>
<br><font size=2 face="sans-serif">I thought I explained it in the text I originally sent so Ill rephrase it since it must not have been clear enough.</font>
<br>
<br><font size=2 face="sans-serif">Given:</font>
<br><font size=2 face="sans-serif">1: Not all postings on a particular AI are clearly indicated in the posting subject (ie: &quot;NOOP?&quot; instead of &quot;</font><font size=2 face="Courier New">W-31 NOOP</font><font size=2 face="sans-serif">?&quot; or &quot;</font><font size=2 face="Courier New">W-31 NOOP</font><font size=2 face="sans-serif"> command?&quot;)</font>
<br><font size=2 face="sans-serif">2: There can be several disjoint threads on a particular AI that occur at various points in time before an AI is considered completed or resolved.</font>
<br>
<br><font size=2 face="sans-serif">Whereas:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; It is not easy, for several reasons, for anyone scanning the archives or threads to find out when/where/what the actual chair decision on a particular Action Item (AI) from the weekly AI list. &nbsp;There should be a simple way to at least find the final decision on an AI in the archives.</font>
<br>
<br><font size=2 face="sans-serif">Proposed:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; When the chair deems an AI to have been resolved (or unresolvable) that the chair 'tags' the discussion thread with a posting that indicates the AIs status. &nbsp;This 'tagging' would be a simple email posting to the thread that clearly indicates the AI and that the message is how the AI was resolved. &nbsp;This 'tag' would be of the format &quot;AI# &amp; title: Resolution&quot; and could be followed by the original subject if desired.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; For example, for a thread that was about the NOOP command (AI &quot;W-31 NOOP command&quot;) that began as Subject: &quot;NOOP again??&quot; the chair would post a message to list with the Subject: &quot;W-31 NOOP command: Resolved&quot; or possibly &quot;W-31 NOOP command: Resolved (was Re[3]: NOOP again??&quot; &nbsp;This would make searching the archives for answers MUCH easier as the search could be for &quot;: Resolved&quot; or the well known format of &quot;W-31 NOOP command: Resolved&quot;.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; If multiple AIs are resolved at the same time, they can be comma separated before the &quot;: Resolved&quot;. &nbsp;For example: &quot;</font><font size=2 face="Courier New">W-31 NOOP command, W-32 NOOP advisory only: Resolved</font><font size=2 face="sans-serif">&quot;</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; If folks think this later case may generate subjects that are too long, the format could easily be abreviated to just &quot;AI#: Resolved&quot; making the multiple case example shortened to just &quot;</font><font size=2 face="Courier New">W-31, W-32: Resolved</font><font size=2 face="sans-serif">&quot;. &nbsp;I would suggest that we not abbreviate it down to &quot;W-31,32: Resolved&quot; since some search engines can do searches like &quot;W-32 AND Resolved&quot; and that would not be matchable in the very shortened case.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; Does this clarify my suggestion?? &nbsp;Would the co-chairs be willing to do this?</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 0053B88D8525691B_=--

---------z10141_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDcxMzE1MTQyN1owIwYJKoZIhvcNAQkEMRYEFELC9XHCxjyc
nbyBZ4IppTMDk95tMA0GCSqGSIb3DQEBAQUABEAMkeS/M7y9LRn4xEIwNwKBKFPbfHlmkhyJwWXK
P6iy8In83dx+J/43JMaaeolHbyxTRZr5EHNyasR90NXOOD/c

---------z10141_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Thu Jul 13 17:26:21 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08304
	for <calsch-archive@odin.ietf.org>; Thu, 13 Jul 2000 17:26:20 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA07442
	for ietf-calendar-bks; Thu, 13 Jul 2000 12:20:36 -0700 (PDT)
Received: from mcnc-mdm1-ex07.marriott.com (host036.marriott.com [162.130.1.36])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07437
	for <ietf-calendar@imc.org>; Thu, 13 Jul 2000 12:20:34 -0700 (PDT)
Received: from mcncmdm1exims2.marriott.com ([192.168.0.37]) by mcnc-mdm1-ex07.marriott.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 3ZDLTJB9; Thu, 13 Jul 2000 14:35:29 -0400
Received: from PickupDirectory by mcncmdm1exims2.marriott.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 36L4NGKV; Thu, 13 Jul 2000 14:35:26 -0400
Received: FROM ns.secondary.com BY mcncmdm1exims2.marriott.com ; Thu Jul 13 13:37:49 2000 -0400
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA26358
	for ietf-calendar-bks; Thu, 13 Jul 2000 08:11:51 -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 IAA26352
	for <ietf-calendar@imc.org>; Thu, 13 Jul 2000 08:11:44 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: pregen@egenconsulting.com
Cc: Doug Royer <Doug.Royer@software.com>, ietf-calendar@imc.org
Subject: Re: Suggestion for Action Items handling
X-Mailer: Lotus Notes Build V60_07042000 July 04, 2000
Message-ID: <OF0AE28281.4215080C-ON8525691B.0051BE9A@iris.com>
Date: Thu, 13 Jul 2000 11:13:34 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/13/2000 11:14:27 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/13/2000 11:14:27 AM,
	Serialize complete at 07/13/2000 11:14:27 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_07042000|July 04, 2000) at
 07/13/2000 11:14:28 AM,
	S/MIME Sign complete at 07/13/2000 11:14:28 AM,
	Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/13/2000
 11:13:50 AM,
	Serialize complete at 07/13/2000 11:13:50 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z10141_boundary_sign
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>
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 an S/MIME signed message.

---------z10141_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0053B88D8525691B_="

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

Doug suggested:
>Have you tried sorting the threads by date? I would think that the
>last one would be a good bet.

I have but this is not always convenient as there can be several 
occurances of a thread and  depending on how the threads get sorted (by 
ascending/descending date/time, etc) you may not see what you expect. 
Plus, if a thread is NOT prefixed with its Action Item then what is a 
person to search for??  I try to use W-#, etc when Im posting but I 
sometimes forget to do that.

Pat replied:
>I think we can do this, but I think I need a bit more clarification on 
just what you'd like to see.

I thought I explained it in the text I originally sent so Ill rephrase it 
since it must not have been clear enough.

Given:
1: Not all postings on a particular AI are clearly indicated in the 
posting subject (ie: "NOOP?" instead of "W-31 NOOP?" or "W-31 NOOP command?")
2: There can be several disjoint threads on a particular AI that occur at 
various points in time before an AI is considered completed or resolved.

Whereas:

  It is not easy, for several reasons, for anyone scanning the archives or 
threads to find out when/where/what the actual chair decision on a 
particular Action Item (AI) from the weekly AI list.  There should be a 
simple way to at least find the final decision on an AI in the archives.

Proposed:

  When the chair deems an AI to have been resolved (or unresolvable) that 
the chair 'tags' the discussion thread with a posting that indicates the 
AIs status.  This 'tagging' would be a simple email posting to the thread 
that clearly indicates the AI and that the message is how the AI was 
resolved.  This 'tag' would be of the format "AI# & title: Resolution" and 
could be followed by the original subject if desired.

  For example, for a thread that was about the NOOP command (AI "W-31 NOOP 
command") that began as Subject: "NOOP again??" the chair would post a 
message to list with the Subject: "W-31 NOOP command: Resolved" or 
possibly "W-31 NOOP command: Resolved (was Re[3]: NOOP again??"  This 
would make searching the archives for answers MUCH easier as the search 
could be for ": Resolved" or the well known format of "W-31 NOOP command: 
Resolved".

  If multiple AIs are resolved at the same time, they can be comma 
separated before the ": Resolved".  For example: "W-31 NOOP command, W-32 NOOP advisory only: Resolved"

  If folks think this later case may generate subjects that are too long, 
the format could easily be abreviated to just "AI#: Resolved" making the 
multiple case example shortened to just "W-31, W-32: Resolved".  I would suggest that we not abbreviate it down to "W-31,32: Resolved" 
since some search engines can do searches like "W-32 AND Resolved" and 
that would not be matchable in the very shortened case.

  Does this clarify my suggestion??  Would the co-chairs be willing to do 
this?

Bruce
==========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0053B88D8525691B_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Doug suggested:</font>
<br><font size=2 face="Courier New">&gt;Have you tried sorting the threads by date? I would think that the<br>
&gt;last one would be a good bet.</font>
<br>
<br><font size=2 face="sans-serif">I have but this is not always convenient as there can be several occurances of a thread and &nbsp;depending on how the threads get sorted (by ascending/descending date/time, etc) you may not see what you expect. &nbsp;Plus, if a thread is NOT prefixed with its Action Item then what is a person to search for?? &nbsp;I try to use W-#, etc when Im posting but I sometimes forget to do that.</font>
<br>
<br><font size=2 face="sans-serif">Pat replied:</font>
<br><font size=2><tt>&gt;I think we can do this, but I think I need a bit more clarification on just what you'd like to see.</tt></font>
<br>
<br><font size=2 face="sans-serif">I thought I explained it in the text I originally sent so Ill rephrase it since it must not have been clear enough.</font>
<br>
<br><font size=2 face="sans-serif">Given:</font>
<br><font size=2 face="sans-serif">1: Not all postings on a particular AI are clearly indicated in the posting subject (ie: &quot;NOOP?&quot; instead of &quot;</font><font size=2 face="Courier New">W-31 NOOP</font><font size=2 face="sans-serif">?&quot; or &quot;</font><font size=2 face="Courier New">W-31 NOOP</font><font size=2 face="sans-serif"> command?&quot;)</font>
<br><font size=2 face="sans-serif">2: There can be several disjoint threads on a particular AI that occur at various points in time before an AI is considered completed or resolved.</font>
<br>
<br><font size=2 face="sans-serif">Whereas:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; It is not easy, for several reasons, for anyone scanning the archives or threads to find out when/where/what the actual chair decision on a particular Action Item (AI) from the weekly AI list. &nbsp;There should be a simple way to at least find the final decision on an AI in the archives.</font>
<br>
<br><font size=2 face="sans-serif">Proposed:</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; When the chair deems an AI to have been resolved (or unresolvable) that the chair 'tags' the discussion thread with a posting that indicates the AIs status. &nbsp;This 'tagging' would be a simple email posting to the thread that clearly indicates the AI and that the message is how the AI was resolved. &nbsp;This 'tag' would be of the format &quot;AI# &amp; title: Resolution&quot; and could be followed by the original subject if desired.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; For example, for a thread that was about the NOOP command (AI &quot;W-31 NOOP command&quot;) that began as Subject: &quot;NOOP again??&quot; the chair would post a message to list with the Subject: &quot;W-31 NOOP command: Resolved&quot; or possibly &quot;W-31 NOOP command: Resolved (was Re[3]: NOOP again??&quot; &nbsp;This would make searching the archives for answers MUCH easier as the search could be for &quot;: Resolved&quot; or the well known format of &quot;W-31 NOOP command: Resolved&quot;.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; If multiple AIs are resolved at the same time, they can be comma separated before the &quot;: Resolved&quot;. &nbsp;For example: &quot;</font><font size=2 face="Courier New">W-31 NOOP command, W-32 NOOP advisory only: Resolved</font><font size=2 face="sans-serif">&quot;</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; If folks think this later case may generate subjects that are too long, the format could easily be abreviated to just &quot;AI#: Resolved&quot; making the multiple case example shortened to just &quot;</font><font size=2 face="Courier New">W-31, W-32: Resolved</font><font size=2 face="sans-serif">&quot;. &nbsp;I would suggest that we not abbreviate it down to &quot;W-31,32: Resolved&quot; since some search engines can do searches like &quot;W-32 AND Resolved&quot; and that would not be matchable in the very shortened case.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; Does this clarify my suggestion?? &nbsp;Would the co-chairs be willing to do this?</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 0053B88D8525691B_=--

---------z10141_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIJAYJKoZIhvcNAQcCoIIIFTCCCBECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBLjCCASoCAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDcxMzE1MTQyN1owIwYJKoZIhvcNAQkEMRYEFELC9XHCxjyc
nbyBZ4IppTMDk95tMA0GCSqGSIb3DQEBAQUABEAMkeS/M7y9LRn4xEIwNwKBKFPbfHlmkhyJwWXK
P6iy8In83dx+J/43JMaaeolHbyxTRZr5EHNyasR90NXOOD/c

---------z10141_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Thu Jul 13 18:49:02 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04750
	for <calsch-archive@odin.ietf.org>; Thu, 13 Jul 2000 18:49:01 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10284
	for ietf-calendar-bks; Thu, 13 Jul 2000 15:14:01 -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 PAA10280
	for <ietf-calendar@imc.org>; Thu, 13 Jul 2000 15:14:00 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: New draft of Guide to Implementors
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF31EE6309.D2FC06F2-ON8525691B.007A3264@com>
Date: Thu, 13 Jul 2000 18:16:08 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 07/13/2000 06:16:01 PM,
	Serialize complete at 07/13/2000 06:16:01 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 007A344B8525691B_="
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 007A344B8525691B_=
Content-Type: text/plain; charset="us-ascii"

A new draft for The Guide To Implementors has been submitted to the IETF 
Drafts area.  You can also find a copy of the draft at the following URL. 
Please take a look at this version and post your comments to the list.

http://www.egenconsulting.com/ietf/ietf-calsch-imp-guide-01.txt
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
--=_alternative 007A344B8525691B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">A new draft for The Guide To Implementors has been submitted to the IETF Drafts area. &nbsp;You can also find a copy of the draft at the following URL. &nbsp;Please take a look at this version and post your comments to the list.</font>
<br>
<br><a href="http://www.egenconsulting.com/ietf/ietf-calsch-imp-guide-01.txt"><font size=2 color=blue face="sans-serif">http://www.egenconsulting.com/ietf/ietf-calsch-imp-guide-01.txt</font></a><font size=2 face="sans-serif"><br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
--=_alternative 007A344B8525691B_=--


From owner-ietf-calendar@mail.imc.org  Thu Jul 13 19:06:31 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10278
	for <calsch-archive@odin.ietf.org>; Thu, 13 Jul 2000 19:06:30 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10320
	for ietf-calendar-bks; Thu, 13 Jul 2000 15:17:05 -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 PAA10316
	for <ietf-calendar@imc.org>; Thu, 13 Jul 2000 15:17:04 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: iRIP and CAP
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OFA440B2E9.DC0D2D6F-ON8525691B.007A5283@com>
Date: Thu, 13 Jul 2000 18:19:11 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 07/13/2000 06:19:05 PM,
	Serialize complete at 07/13/2000 06:19:05 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 007A7C0C8525691B_="
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 007A7C0C8525691B_=
Content-Type: text/plain; charset="us-ascii"

The iRIP (Real Time Processing)  calendar draft has expired.  This note is 
to query the list as to whether it needs to be re-opened or scrapped. 
There is an opinion that much of iRIP is in CAP and does not really need 
to be a separate draft.  Any one who thinks differently should post that 
opinion to the list and state why they feel iRIP should be reinstated.  If 
we do not hear anything from the list, we'll assume that iRIP is "RIP" . 
8-)    (couldn't resist)..

--=_alternative 007A7C0C8525691B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">The iRIP (Real Time Processing) &nbsp;calendar draft has expired. &nbsp;This note is to query the list as to whether it needs to be re-opened or scrapped. &nbsp;There is an opinion that much of iRIP is in CAP and does not really need to be a separate draft. &nbsp;Any one who thinks differently should post that opinion to the list and state why they feel iRIP should be reinstated. &nbsp;If we do not hear anything from the list, we'll assume that iRIP is &quot;RIP&quot; . &nbsp;8-) &nbsp; &nbsp;(couldn't resist)..<br>
</font>
--=_alternative 007A7C0C8525691B_=--


From owner-ietf-calendar@mail.imc.org  Thu Jul 13 19:11:20 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11798
	for <calsch-archive@odin.ietf.org>; Thu, 13 Jul 2000 19:11:20 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10463
	for ietf-calendar-bks; Thu, 13 Jul 2000 15:23:30 -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 PAA10459
	for <ietf-calendar@imc.org>; Thu, 13 Jul 2000 15:23:28 -0700 (PDT)
From: pregen@egenconsulting.com
To: Bruce_Kahn@iris.com
Cc: Doug.Royer@software.com, ietf-calendar@imc.org
Subject: Re: Suggestion for Action Items handling
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OFAC1401D4.5A2FAE5F-ON8525691B.007AC62D@com>
Date: Thu, 13 Jul 2000 18:25:31 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 07/13/2000 06:25:30 PM,
	Serialize complete at 07/13/2000 06:25:30 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 007B10478525691B_="
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 007B10478525691B_=
Content-Type: text/plain; charset="us-ascii"

Bruce, I can see that you are looking for a quick way to scan the list (as 
opposed to opening and reading the mail). Hm.  In principle, it sounds 
like a good idea, however it will be a bit more work for the chairs.  I 
think we may be able to put together something that says Resolved Items in 
the subject and then list all the items in a single note.  I'm not wild 
about having to send out individual notes on each item simply to make it 
easier to scan in an inbox.  Too much additional effort - and I'm not sure 
of the payback.  Anyone else have an opinion?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
--=_alternative 007B10478525691B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Bruce, I can see that you are looking for a quick way to scan the list (as opposed to opening and reading the mail). Hm. &nbsp;In principle, it sounds like a good idea, however it will be a bit more work for the chairs. &nbsp;I think we may be able to put together something that says Resolved Items in the subject and then list all the items in a single note. &nbsp;I'm not wild about having to send out individual notes on each item simply to make it easier to scan in an inbox. &nbsp;Too much additional effort - and I'm not sure of the payback. &nbsp;Anyone else have an opinion?<br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
--=_alternative 007B10478525691B_=--


From owner-ietf-calendar@mail.imc.org  Thu Jul 13 19:11:27 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11837
	for <calsch-archive@odin.ietf.org>; Thu, 13 Jul 2000 19:11:26 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10663
	for ietf-calendar-bks; Thu, 13 Jul 2000 15:33:41 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10659
	for <ietf-calendar@imc.org>; Thu, 13 Jul 2000 15:33:40 -0700 (PDT)
Received: from grand-central-station.MIT.EDU (GRAND-CENTRAL-STATION.MIT.EDU [18.69.0.34])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA24648;
	Thu, 13 Jul 2000 18:35:41 -0400 (EDT)
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 SAA17116;
	Thu, 13 Jul 2000 18:35:41 -0400 (EDT)
Received: from [216.254.65.44] (MAUI.MIT.EDU [18.177.1.27])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id SAA01328;
	Thu, 13 Jul 2000 18:35:40 -0400 (EDT)
Mime-Version: 1.0
X-Sender: bobmah@PO12.MIT.EDU
Message-Id: <p04320416b593f37f7ed3@[216.254.65.44]>
In-Reply-To: <OF31EE6309.D2FC06F2-ON8525691B.007A3264@com>
References: <OF31EE6309.D2FC06F2-ON8525691B.007A3264@com>
Date: Thu, 13 Jul 2000 18:33:32 -0400
To: pregen@egenconsulting.com
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: New draft of Guide to Implementors
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>

You always notice after the mail goes out...

I apparently truncated a cut & paste.  Feel free to mentally append 
the following to the end of the document:

---
      languages other than English.

       The limited permissions granted above are perpetual and will not
       be revoked by the Internet Society or its successors or assigns.

       This document and the information contained herein is provided on
       an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
       ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
       IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
       THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
       WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
       PURPOSE."
---

To the bottom of the document.

Pat- you might want to drop a note to the drafts folks, in case they 
miss this in the rush.

-Bob


From owner-ietf-calendar@mail.imc.org  Fri Jul 14 11:41:50 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06128
	for <calsch-archive@odin.ietf.org>; Fri, 14 Jul 2000 11:41:49 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA22399
	for ietf-calendar-bks; Fri, 14 Jul 2000 07:58:20 -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 HAA22395
	for <ietf-calendar@imc.org>; Fri, 14 Jul 2000 07:58:18 -0700 (PDT)
From: pregen@egenconsulting.com
To: Bob Mahoney <bobmah@mit.edu>
Cc: ietf-calendar@imc.org
Subject: Re: New draft of Guide to Implementors
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF62AD1B5B.5172924E-ON8525691C.0052565E@com>
Date: Fri, 14 Jul 2000 11:00:45 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 07/14/2000 11:00:23 AM,
	Serialize complete at 07/14/2000 11:00:23 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005258598525691C_="
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 005258598525691C_=
Content-Type: text/plain; charset="us-ascii"

Bob, I updated the draft with the missing text and resubmitted it. 
Everyone on the list can see the updated text as well at the following 
link.

http://www.egenconsulting.com/ietf/ietf-calsch-imp-guide-01.txt
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
--=_alternative 005258598525691C_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Bob, I updated the draft with the missing text and resubmitted it. &nbsp;Everyone on the list can see the updated text as well at the following link.</font>
<br>
<br><a href="http://www.egenconsulting.com/ietf/ietf-calsch-imp-guide-01.txt"><font size=2 color=blue face="sans-serif"><u>http://www.egenconsulting.com/ietf/ietf-calsch-imp-guide-01.txt</u></font></a><font size=2 face="sans-serif"><br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
--=_alternative 005258598525691C_=--


From owner-ietf-calendar@mail.imc.org  Fri Jul 14 15:25:54 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20758
	for <calsch-archive@odin.ietf.org>; Fri, 14 Jul 2000 15:25:54 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08563
	for ietf-calendar-bks; Fri, 14 Jul 2000 12:07:01 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08558
	for <ietf-calendar@imc.org>; Fri, 14 Jul 2000 12:07:00 -0700 (PDT)
Received: from Software.com ([207.175.94.210]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000714190919.KLPM459995.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Fri, 14 Jul 2000 14:09:19 -0500
Message-ID: <396F5488.93145DF0@Software.com>
Date: Fri, 14 Jul 2000 10:57:28 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Seeking RRULE evaluation guidance
References: <OF14C5D90B.C5D94E8E-ON8525690E.005008A5@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:
> 
> Warning: This is a rather long posting in an effort to be as clear as I
> can on my quandry!!
> 
>   Ok, after trying to figure out how some seemingly simple RRULE cases
> should be handled Ive come to the opinion that the RFC is not clear
> enough on the topic of evaluation for some cases.  The RFC has some good
> examples (thanks again Derik & Frank) but it is unclear how a recurrence
> rule should be evaluated when the FREQUENCY value is less than a BY*
> value, the INTERVAL is > 1 and the BY* is _NOT_ contiguous.
> 
>   For example with the following contiguous BYMONTH, just what are the
> rolled out values for the following:
> 
> DTSTART;TZID=US-Eastern:20000628T09000
> DTEND;TZID=US-Eastern:20000628T093000
> RRULE:FREQ=DAILY;COUNT=5;INTERVAL=4;BYMONTH=6,7
> 
> Should it be:

What if it said INTERVAL=1:

DTSTART;TZID=US-Eastern:20000628T09000
DTEND;TZID=US-Eastern:20000628T093000
RRULE:FREQ=DAILY;COUNT=5;INTERVAL=1;BYMONTH=6,7

You would expect it to be every day for 5 days - correct?

The fact that INTERVAL is 4 should make no difference, it should
happen every 4th day, and happen 5 times DAILY.

Or your other example:

> DTSTART;TZID=US-Eastern:20000628T09000 
> DTEND;TZID=US-Eastern:20000628T093000 
> RRULE:FREQ=DAILY;COUNT=5;INTERVAL=4;BYMONTH=6,8 

Same issue.  If the INTERVAL was 1, what would it do?
It would skip month 7 and continue.

It is much like the example in RFC-2445 (below), except your example
has only have one instance repeated 5 times.

(From section 4.3.10)

   Here is an example of evaluating multiple BYxxx rule parts.

     DTSTART;TZID=US-Eastern:19970105T083000
     RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
      BYMINUTE=30

   First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive
   at "every other year". Then, "BYMONTH=1" would be applied to arrive
   at "every January, every other year". Then, "BYDAY=SU" would be
   applied to arrive at "every Sunday in January, every other year".
   Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in
   January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30"
   would be applied to arrive at "every Sunday in January at 8:30 AM and
   9:30 AM, every other year". Then, lacking information from RRULE, the
   second is derived from DTSTART, to end up in "every Sunday in January
   at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the
   BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were
   missing, the appropriate minute, hour, day or month would have been
   retrieved from the "DTSTART" property.


-Doug


From owner-ietf-calendar@mail.imc.org  Fri Jul 14 16:27:19 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07897
	for <calsch-archive@odin.ietf.org>; Fri, 14 Jul 2000 16:27:19 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA12557
	for ietf-calendar-bks; Fri, 14 Jul 2000 13:11:30 -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 NAA12546
	for <ietf-calendar@imc.org>; Fri, 14 Jul 2000 13:11:22 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: Re: Seeking RRULE evaluation guidance
X-Mailer: Lotus Notes Build V60_07122000 July 12, 2000
Message-ID: <OFFC4375DA.65399D06-ON8525691C.006DF019@iris.com>
Date: Fri, 14 Jul 2000 16:15:48 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_07122000|July 12, 2000) at
 07/14/2000 04:13:00 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_07122000|July 12, 2000) at
 07/14/2000 04:13:00 PM,
	Serialize complete at 07/14/2000 04:13:00 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_07122000|July 12, 2000) at
 07/14/2000 04:13:01 PM,
	S/MIME Sign complete at 07/14/2000 04:13:01 PM,
	Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at
 07/14/2000 04:13:33 PM,
	Serialize complete at 07/14/2000 04:13:33 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z8789_boundary_sign
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 an S/MIME signed message.

---------z8789_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 006F0DE08525691C_="

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

Doug wrote:
>What if it said INTERVAL=1:

The key of the question is that the BY* are NONCONTIGUOUS.  I used 
INTERVAL=4 because it would give you different results based on HOW the 
person evaluates the BY* components (Note that the initial value is NOT in 
July so having an INTERVAL affects what values you reach in July, 
depending on how you roll out the BY*.)

So, what is your answer to my set of rollouts with INTERVAL=4??  W/o this, 
we cannot discuss the NONCONTIGUOUS set of BY* values that follow...

>The fact that INTERVAL is 4 should make no difference, it should
>happen every 4th day, and happen 5 times DAILY.

Ok, Im still looking to see what set of dates you say is the proper 
answer...  What Im trying to understand is how you think BY* sets should 
be evaluated: 

1: Do you treat BYMONTH=6,7 as 2 separate 'sets' and start evaluating 
BYMONTH=6 @ 28-June and BYMONTH=7 @ 1-July or
2: Do you treat BYMONTH=6,7 as 1 continuous 'set' and just 'roll into' 
July and account for the days you already skipped in June?

Logically I think most folks would do #2.  However the wrench Im wrestling 
with involves NONCONTINUOUS sets like BYMONTH=6,8.

>(From section 4.3.10)
>
>   Here is an example of evaluating multiple BYxxx rule parts.
>
>     DTSTART;TZID=US-Eastern:19970105T083000
>     RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
>      BYMINUTE=30

Key observations to be made about this counter example:

1: BYMONTH is a single value
2: BYDAY is a single value
3: BYHOUR is a CONTIGUOUS set
4: BYMINUTE is a single value

Simplify the counter example to a fewer set of BY* and make one 
NONCONTIGUOUS.  Then you can see why some collective wisdom is necessary 
(at least from where I sit in my office)...

>Same issue.  If the INTERVAL was 1, what would it do?
>It would skip month 7 and continue.

Just what do you mean by 'skip month 7'??  Do I treat BYMONTH=6,8 as a 
contiguous set (and just 'roll into' like in #2 above)?  Do you 'roll into 
and thru' month 7 and keep going into month 8?  (This is why I picked 
June/July/August and INTERVAL=4; you get different roll outs based on what 
you consider 'skipping month 7'...

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


<br><font size=2 face="sans-serif">Doug wrote:</font>
<br><font size=2 face="Courier New">&gt;What if it said INTERVAL=1:<br>
</font>
<br><font size=2 face="sans-serif">The key of the question is that the BY* are NONCONTIGUOUS. &nbsp;I used INTERVAL=4 because it would give you different results based on HOW the person evaluates the BY* components (Note that the initial value is NOT in July so having an INTERVAL affects what values you reach in July, depending on how you roll out the BY*.)</font>
<br>
<br><font size=2 face="sans-serif">So, what is your answer to my set of rollouts with INTERVAL=4?? &nbsp;W/o this, we cannot discuss the NONCONTIGUOUS set of BY* values that follow...</font>
<br>
<br><font size=2 face="Courier New">&gt;The fact that INTERVAL is 4 should make no difference, it should<br>
&gt;happen every 4th day, and happen 5 times DAILY.</font>
<br>
<br><font size=2 face="sans-serif">Ok, Im still looking to see what set of dates you say is the proper answer... &nbsp;What Im trying to understand is how you think BY* sets should be evaluated: &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">1: Do you treat BYMONTH=6,7 as 2 separate 'sets' and start evaluating BYMONTH=6 @ 28-June and BYMONTH=7 @ 1-July or</font>
<br><font size=2 face="sans-serif">2: Do you treat BYMONTH=6,7 as 1 continuous 'set' and just 'roll into' July and account for the days you already skipped in June?</font>
<br>
<br><font size=2 face="sans-serif">Logically I think most folks would do #2. &nbsp;However the wrench Im wrestling with involves NONCONTINUOUS sets like BYMONTH=6,8.</font>
<br>
<br><font size=2 face="Courier New">&gt;(From section 4.3.10)<br>
&gt;<br>
&gt; &nbsp; Here is an example of evaluating multiple BYxxx rule parts.<br>
&gt;<br>
&gt; &nbsp; &nbsp; DTSTART;TZID=US-Eastern:19970105T083000<br>
&gt; &nbsp; &nbsp; RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;<br>
&gt; &nbsp; &nbsp; &nbsp;BYMINUTE=30<br>
</font>
<br><font size=2 face="sans-serif">Key observations to be made about this counter example:</font>
<br>
<br><font size=2 face="sans-serif">1: BYMONTH is a single value</font>
<br><font size=2 face="sans-serif">2: BYDAY is a single value</font>
<br><font size=2 face="sans-serif">3: BYHOUR is a CONTIGUOUS set</font>
<br><font size=2 face="sans-serif">4: BYMINUTE is a single value</font>
<br>
<br><font size=2 face="sans-serif">Simplify the counter example to a fewer set of BY* and make one NONCONTIGUOUS. &nbsp;Then you can see why some collective wisdom is necessary (at least from where I sit in my office)...</font>
<br>
<br><font size=2 face="Courier New">&gt;Same issue. &nbsp;If the INTERVAL was 1, what would it do?<br>
&gt;It would skip month 7 and continue.</font>
<br>
<br><font size=2 face="sans-serif">Just what do you mean by 'skip month 7'?? &nbsp;Do I treat BYMONTH=6,8 as a contiguous set (and just 'roll into' like in #2 above)? &nbsp;Do you 'roll into and thru' month 7 and keep going into month 8? &nbsp;(This is why I picked June/July/August and INTERVAL=4; you get different roll outs based on what you consider 'skipping month 7'...</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 006F0DE08525691C_=--

---------z8789_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIawYJKoZIhvcNAQcCoIIIXDCCCFgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBdTCCAXECAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKCBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA3MTQyMDEzMDBaMCMGCSqGSIb3DQEJBDEWBBQmUHE632Qd
up4bSmIxmi7k6O80UTBEBgkqhkiG9w0BCQ8xNzA1MAcGBSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICACgwDQYJKoZIhvcNAQEBBQAEQIq+Tj5WTA1HmQgdZAsU
ucha85ckHbQdeCgxcVoM3v9nX4n3VVPtRvhWKVcqkt3eu208ifPLlmXRs5U4SmIyfUI=

---------z8789_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Fri Jul 14 17:04:33 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20454
	for <calsch-archive@odin.ietf.org>; Fri, 14 Jul 2000 17:04:33 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA14597
	for ietf-calendar-bks; Fri, 14 Jul 2000 13:50:54 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14593
	for <ietf-calendar@imc.org>; Fri, 14 Jul 2000 13:50:50 -0700 (PDT)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: pregen@egenconsulting.com
Cc: Doug.Royer@software.com, ietf-calendar@imc.org
Subject: Re: Suggestion for Action Items handling
X-Mailer: Lotus Notes Build V60_07122000 July 12, 2000
Message-ID: <OFAEB2A9F2.BDD0CBA2-ON8525691C.007261D6@iris.com>
Date: Fri, 14 Jul 2000 16:56:13 -0400
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Build V60_07122000|July 12, 2000) at
 07/14/2000 04:53:26 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Build V60_07122000|July 12, 2000) at
 07/14/2000 04:53:26 PM,
	Serialize complete at 07/14/2000 04:53:26 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Build V60_07122000|July 12, 2000) at
 07/14/2000 04:53:26 PM,
	S/MIME Sign complete at 07/14/2000 04:53:26 PM,
	Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at
 07/14/2000 04:53:00 PM,
	Serialize complete at 07/14/2000 04:53:00 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z62137_boundary_sign
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 an S/MIME signed message.

---------z62137_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0072C16A8525691C_="

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

Pat replied:
>In principle, it sounds like a good idea, however it will be a bit more 
work for the chairs.

Its only 1 more email and it can be a quite brief.  It can be just a line 
or two saying that the concensus is "Blech" and thats its...  Im not 
asking for a technical resummary of the thread. %^|

>I think we may be able to put together something that says Resolved Items 
in the subject and then list all the items in a single note.

That may as well be added to the Action Item list instead if thats your 
route.  No use having to have 2 lists to consult: 1 for the items and 1 
for the thumbs up/down.  Besides, we already have a column for that in the 
AI List.

>I'm not wild about having to send out individual notes on each item 
simply to make it easier to scan in an inbox.  Too much additional effort 
- and I'm not sure of the payback.

We dont resolve 'em that fast that its gonna be that much work.  Its not 
just for scanning my inbox but rather for folks who scan the _archives_ 
that want to find out what was covered on a particular AI!!

The payback is simple; it allows anyone who questions an AI thats been 
resolved to quickly find the thread that lead to the decision.  That way 
we do not get new folks who see the nice weekly list but have a tough time 
finding in the 3+ year archive we discussed a particular AI...  It also 
allows for quick lookups of discussions should a topic get reraised (ie: 
HTTP as a transport! %^| )

Enough preaching, Ive made my case and attempted to support it...  If 
there are other ideas on this or better suggestions, Id love to hear em. 
(We have 300+ folks on this list and only 4-6 post so the lurkers need to 
speak up if they want this!..)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 0072C16A8525691C_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Pat replied:</font>
<br><font size=2 face="sans-serif">&gt;In principle, it sounds like a good idea, however it will be a bit more work for the chairs.</font>
<br>
<br><font size=2 face="sans-serif">Its only 1 more email and it can be a quite brief. &nbsp;It can be just a line or two saying that the concensus is &quot;Blech&quot; and thats its... &nbsp;Im not asking for a technical resummary of the thread. %^|</font>
<br>
<br><font size=2 face="sans-serif">&gt;I think we may be able to put together something that says Resolved Items in the subject and then list all the items in a single note.</font>
<br>
<br><font size=2 face="sans-serif">That may as well be added to the Action Item list instead if thats your route. &nbsp;No use having to have 2 lists to consult: 1 for the items and 1 for the thumbs up/down. &nbsp;Besides, we already have a column for that in the AI List.</font>
<br>
<br><font size=2 face="sans-serif">&gt;I'm not wild about having to send out individual notes on each item simply to make it easier to scan in an inbox. &nbsp;Too much additional effort - and I'm not sure of the payback.</font>
<br>
<br><font size=2 face="sans-serif">We dont resolve 'em that fast that its gonna be that much work. &nbsp;Its not just for scanning my inbox but rather for folks who scan the _archives_ that want to find out what was covered on a particular AI!!</font>
<br>
<br><font size=2 face="sans-serif">The payback is simple; it allows anyone who questions an AI thats been resolved to quickly find the thread that lead to the decision. &nbsp;That way we do not get new folks who see the nice weekly list but have a tough time finding in the 3+ year archive we discussed a particular AI... &nbsp;It also allows for quick lookups of discussions should a topic get reraised (ie: HTTP as a transport! %^| )</font>
<br>
<br><font size=2 face="sans-serif">Enough preaching, Ive made my case and attempted to support it... &nbsp;If there are other ideas on this or better suggestions, Id love to hear em. &nbsp;(We have 300+ folks on this list and only 4-6 post so the lurkers need to speak up if they want this!..)</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 0072C16A8525691C_=--

---------z62137_boundary_sign
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

MIIIawYJKoZIhvcNAQcCoIIIXDCCCFgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBr4w
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVTMQ0wCwYDVQQI
EwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIEludGVybmV0IENBMB4XDTk4MTEw
MjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAw+BjK0cgxCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5
yBLDj5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwzcO3Ltq2H
lXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/winjCCAX4wggEooAMCAQIC
BDY+EqcwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNV
BAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTgxMTAyMDgxNDAwWhcNMDgx
MDMwMDgxNDAwWjBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzENMAsGA1UEChMESXJpczEZ
MBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDD4GMrRyDE
LELXdusXOXt4HiPZxq36zplJ3Z+XGVO4kaDV23JAfAphGwM4OISmpQLmgjnIEsOPksNhdQTAGbhh
AgMBAAEwDQYJKoZIhvcNAQEEBQADQQBJD9YWcY7iiR1zEy0mvDNw7cu2rYeVebdqRw0NnRyW1WTr
ShcnIqr4tVdH9PCP5kj9myvmp+FvkkAuLsL7/CKeMIIB2TCCAYOgAwIBAgIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMCVVMxDTALBgNV
BAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0EwHhcNOTkx
MTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQKEwRJcmlzMRMwEQYDVQQDEwpCcnVj
ZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGlyaXMuY29tMFswDQYJKoZIhvcNAQEB
BQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luhEWdzIRAUebxy98E2l6EVlYT3qA2l
HAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQIRtot8dHW9ncwDwYDVR0PAQH/BAUD
AwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcNAQEEBQADQQCZ2OwT1LofRuIK3Ap5
jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p8qxJFReEDuso4koWno/wMIIB2TCC
AYOgAwIBAgIgYFBenn5aVoeofT34GA+7AJTAjPHpxpfEVznCKPboYHswDQYJKoZIhvcNAQEEBQAw
RjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMTEEly
aXMgSW50ZXJuZXQgQ0EwHhcNOTkxMTE3MTkxMzI3WhcNMDExMTE2MTkxMjUzWjBIMQ0wCwYDVQQK
EwRJcmlzMRMwEQYDVQQDEwpCcnVjZSBLYWhuMSIwIAYJKoZIhvcNAQkBFhNCcnVjZV9LYWhuQGly
aXMuY29tMFswDQYJKoZIhvcNAQEBBQADSgAwRwJBAOPeUv73E6LhMbVrjaxd90NvC3I45OJY9luh
EWdzIRAUebxy98E2l6EVlYT3qA2lHAnOeKIoPGEJQv4cEqd2BeECAkJRozwwOjARBgNVHQ4ECgQI
Rtot8dHW9ncwDwYDVR0PAQH/BAUDAwewADAUBgtghkgBhvgOAgIDAgQFAwMHgAAwDQYJKoZIhvcN
AQEEBQADQQCZ2OwT1LofRuIK3Ap5jT5TBybBNPylC5b2qjGm+blkHdJxZGYOuEyFsJWDC68Cqs3p
8qxJFReEDuso4koWno/wMYIBdTCCAXECAQEwajBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFT
UzENMAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQQIgYFBenn5aVoeofT34
GA+7AJTAjPHpxpfEVznCKPboYHswCQYFKw4DAhoFAKCBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA3MTQyMDUzMjZaMCMGCSqGSIb3DQEJBDEWBBQGqLUEK6it
dKRrr2eVNGwtBfwQJzBEBgkqhkiG9w0BCQ8xNzA1MAcGBSsOAwIdMA4GCCqGSIb3DQMCAgIAgDAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICACgwDQYJKoZIhvcNAQEBBQAEQI7eHpKiLVuCpffdrP0q
uZuxtbV6eKmD6MmY8zOrDhmNLM1wp8EUoyeRNFRJVtC8kUBpY7XRzNro9t3dcGykYdA=

---------z62137_boundary_sign--


From owner-ietf-calendar@mail.imc.org  Fri Jul 14 18:01:12 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04023
	for <calsch-archive@odin.ietf.org>; Fri, 14 Jul 2000 18:01:11 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17122
	for ietf-calendar-bks; Fri, 14 Jul 2000 14:49:16 -0700 (PDT)
Received: from ganimides.ucm.cl (alerce-gw.ucm.cl [200.28.31.248])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16938;
	Fri, 14 Jul 2000 14:46:01 -0700 (PDT)
From: ReduceDebt@2free.fsnet.co.uk
Received: from 152 (alerce-gw.ucm.cl [200.28.31.248])
	by ganimides.ucm.cl (8.9.3/8.9.3) with SMTP id UAA16479;
	Thu, 13 Jul 2000 20:43:50 -0400
Message-ID: <000065c27a75$0000412f$0000643d@113>
To: <ReduceDebt@2free.fsnet.co.uk>
Subject: FREE!  Confidential Debt Reduction Analysis 
Date: Fri, 14 Jul 2000 16:32:24 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
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: quoted-printable

<html>

<head>
<title>CLICK HERETo apply for your FREE</title>
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 4.0">
</head>

<body>
<div align=3D"center"><center>

<table border=3D"0" width=3D"41%" height=3D"651">
  <tr>
    <td width=3D"100%" height=3D"640" bgcolor=3D"#000000"><div align=3D"ce=
nter"><center><table
    border=3D"0" cellspacing=3D"1" width=3D"94%" height=3D"492">
      <tr>
        <td width=3D"100%" height=3D"113" bgcolor=3D"#FFFFFF"><div align=3D=
"center"><center><table
        border=3D"0" cellspacing=3D"1" width=3D"98%">
          <tr>
            <td width=3D"100%"><p align=3D"center"><img
            src=3D"http://3518593971/bin/redirector2.cgi?http://3626198025=
/pop/formmail/top.jpg"
            alt=3D"top.jpg (5280 bytes)"></td>
          </tr>
          <tr>
            <td width=3D"100%"><p align=3D"center"><img
            src=3D"http://3518593971/bin/redirector2.cgi?http://3626198025=
/pop/formmail/banner.gif"
            alt=3D"banner.gif (20967 bytes)"></td>
          </tr>
        </table>
        </center></div></td>
      </tr>
      <tr>
        <td width=3D"100%" height=3D"144" bgcolor=3D"#FFFFFF"><p align=3D"=
center"><b><font
        face=3D"Verdana, Arial, Helvetica, 
sans-serif"><a href=3D"http://3518593971/bin/redirector2.cgi?http://362619=
8025/pop/formmail/"><font
        color=3D"#000000">CLICK HERE</font></a><br>
        <br>
        To apply for your FREE, no obligation quote.</font></b></td>
      </tr>
      <tr>
        <td width=3D"100%" height=3D"363" bgcolor=3D"#0000FF"><font color=3D=
"#FFFFFF"><span style=3D"background-color: #0000FF"><b>Our Non-Profit
        Organization can do the following &nbsp; JUST BY ASKING YOUR CREDI=
TORS:</b></span><span style=3D"background-color: #FFFF00"><br>
          </span>
        <br>
        (*)Cut your bills in half.<br>
        (*)Consolidate your bills into ONE LOW monthly payment.<br>
        (*)Eliminate interest and late fee charges.<br>
        (*)Improve your credit rating.<br>
        (*)NO Need To Own Any Property<br>
        <br>
          <b><font size=3D"4">
        A trained professional negotiates with your creditors to:</font></=
b><br>
        <br>
        1) Lower your monthly debt payments by 40-60%<br>
        2) End creditor harassment<br>
        3) Save thousands of dollars in interest and late charges<br>
        4) Start improving your credit rating.</font></td>
      </tr>
      <tr>
        <td width=3D"100%" height=3D"64" bgcolor=3D"#FFFFFF"><p align=3D"c=
enter">_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/<br>
        If you have received this message in error and would<br>
        like to be removed from future mailings, please reply<br>
        with the word remove in the subject. <br>
        _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/</td>
      </tr>
    </table>
    </center></div></td>
  </tr>
</table>
</center></div>
</body>
</html>






From owner-ietf-calendar@mail.imc.org  Sat Jul 15 06:22:52 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08690
	for <calsch-archive@odin.ietf.org>; Sat, 15 Jul 2000 06:22:51 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA17122
	for ietf-calendar-bks; Sat, 15 Jul 2000 03:04:44 -0700 (PDT)
Received: from cmailg1.svr.pol.co.uk (cmailg1.svr.pol.co.uk [195.92.195.171])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA17118
	for <ietf-calendar@imc.org>; Sat, 15 Jul 2000 03:04:42 -0700 (PDT)
Received: from modem-215.blue-angel.dialup.pol.co.uk ([62.136.234.215] helo=helixcode.com)
	by cmailg1.svr.pol.co.uk with esmtp (Exim 3.13 #0)
	id 13DOqR-0002Vv-00
	for ietf-calendar@imc.org; Sat, 15 Jul 2000 11:06:51 +0100
Message-ID: <396FD1DF.C911A017@helixcode.com>
Date: Sat, 15 Jul 2000 03:52:15 +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: "ietf-calendar@imc.org" <ietf-calendar@imc.org>
Subject: Recurrence ambiguities
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


While implementing recurrence expansion I noticed a few problems:

o The BYDAY modifier is ambiguous. In a YEARLY frequency with BYMONTH and/or
  BYWEEKNO set, does the BYDAY modifier apply to the year day, the month day,
  or the week day? I'd guess it applies to the month day or week day.

o Should BYWEEKNO and BYMONTH be mutually exclusive? They make no sense
  together. (This would also avoid part of the previous problem.)

o Is it possible to use BYMONTHDAY in a WEEKLY frequency, or BYYEARDAY in
  a MONTHLY or WEEKLY frequency? I suppose it is possible, but it doesn't
  really make any sense. Maybe the spec should say that they aren't
  applicable to those frequencies (as it says that BYWEEKNO is only
  applicable to YEARLY, (even though it would also make sense in DAILY)).

o BYSETPOS is limited to 366 values (or maybe 999 values if the comment doesn't
  count as part of the spec!), yet a complete expansion for every second in
  every day of the year would result in much larger sets. (Though I realize
  it is unlikely that this limit is reached.) If it is an arbitrary limit
  then maybe the spec should say so.

o The algorithm to calculate the first week in the year may be awkward,
  since some people/countries may be used to other numbering schemes.
  Maybe there should be a choice of a few schemes for this. (Though I'm
  not sure how many people/countries this affects.)

Damon




From owner-ietf-calendar@mail.imc.org  Sun Jul 16 03:19:52 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07841
	for <calsch-archive@odin.ietf.org>; Sun, 16 Jul 2000 03:19:51 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA25839
	for ietf-calendar-bks; Sat, 15 Jul 2000 23:58:11 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA25832
	for <ietf-calendar@imc.org>; Sat, 15 Jul 2000 23:58:09 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA13126
	for ietf-calendar@imc.org; Sun, 16 Jul 2000 00:00:03 -0700 (PDT)
Date: Sun, 16 Jul 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200007160700.AAA13126@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	N
     text as commented on the list		Paul

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

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

 C-13 Post CAP-00.txt					Y

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

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

 C-21 Resubmit REQUIREMENTS draft.
 
------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:

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

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

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

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

 I-4 Add ALARMID to VALARM ?			Y

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


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

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



From owner-ietf-calendar@mail.imc.org  Mon Jul 17 07:06:58 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03866
	for <calsch-archive@odin.ietf.org>; Mon, 17 Jul 2000 07:06:57 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA10807
	for ietf-calendar-bks; Mon, 17 Jul 2000 03:36:35 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10803
	for <ietf-calendar@imc.org>; Mon, 17 Jul 2000 03:36:33 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24529;
	Mon, 17 Jul 2000 06:38:53 -0400 (EDT)
Message-Id: <200007171038.GAA24529@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-calendar@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-calsch-imp-guide-01.txt
Date: Mon, 17 Jul 2000 06:38:53 -0400
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Working Group of the IETF.

	Title		: Implementors' Guide to Internet Calendaring
	Author(s)	: B. Mahoney, A. Taler, G. Babics
	Filename	: draft-ietf-calsch-imp-guide-01.txt
	Pages		: 
	Date		: 14-Jul-00
	
This document describes the relationship between the various internet
calendaring and scheduling protocols defined by RFC 2445 (iCalendar), 
RFC 2446 (iTIP), and RFC 2447 (iMIP), as well as the works in 
progress,'iCalendar Real-time Interoperability Protocol' (iRIP), 
and 'Calendar Access Protocol' (CAP). It's intention is to provide 
a context for these protocols, assist in their understanding, and 
ultimately help implementors in the design of their internet 
calendaring and scheduling systems.
[Note: in the past there has been some discussion as to whether iRIP 
was a live effort, given that interest has waned and some functionality 
has been moved to CAP.  What's the status?]
This document also describes issues and problems which are not solved
by these protocols, and could be targets for future work.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsch-imp-guide-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-calsch-imp-guide-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-calsch-imp-guide-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000714142518.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsch-imp-guide-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsch-imp-guide-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000714142518.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-calendar@mail.imc.org  Mon Jul 17 09:39:22 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10990
	for <calsch-archive@odin.ietf.org>; Mon, 17 Jul 2000 09:39:22 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA13931
	for ietf-calendar-bks; Mon, 17 Jul 2000 06:20:59 -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 GAA13927
	for <ietf-calendar@imc.org>; Mon, 17 Jul 2000 06:20:58 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id JAA17028
	for <ietf-calendar@imc.org>; Mon, 17 Jul 2000 09:24:08 -0400
Message-ID: <397308F7.53016372@ecal.com>
Date: Mon, 17 Jul 2000 09:24:07 -0400
From: John Stracke <francis@ecal.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: ietf-calendar@imc.org
Subject: Re: iRIP and CAP
References: <OFA440B2E9.DC0D2D6F-ON8525691B.007A5283@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

pregen@egenconsulting.com wrote:

> The iRIP (Real Time Processing)  calendar draft has expired.
> This note is to query the list as to whether it needs to be
> re-opened or scrapped.  There is an opinion that much of iRIP
> is in CAP and does not really need to be a separate draft..

It might be a good idea to have a draft specifying how to use CAP
for iRIP-like functionality.  I'm thinking of a profile document,
rather than a separate protocol, specifying a subset of CAP and
the security considerations for the subset.

My thinking here is that CAP has functionality that security
admins might not want to expose through the firewall; giving them
a safer subset would address that.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Piscatorice non aristotelice.                |
|francis@ecal.com|                                             |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Mon Jul 17 14:07:48 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29995
	for <calsch-archive@odin.ietf.org>; Mon, 17 Jul 2000 14:07:46 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19882
	for ietf-calendar-bks; Mon, 17 Jul 2000 10:45:29 -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 KAA19876
	for <ietf-calendar@imc.org>; Mon, 17 Jul 2000 10:45:27 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: Re: iRIP and CAP
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF7C034520.51931F18-ON8525691F.0061B308@com>
Date: Mon, 17 Jul 2000 13:47:45 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 07/17/2000 01:47:47 PM,
	Serialize complete at 07/17/2000 01:47:47 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00619C928525691F_="
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 00619C928525691F_=
Content-Type: text/plain; charset="us-ascii"

Yes, I did mean to send this to the list. Thanks.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
----- Forwarded by Pat R Egen/Egen Consulting/01 on 07/17/00 01:45 PM 
-----


John Stracke <francis@ecal.com>
Sent by: francis@localhost.localdomain
07/17/00 01:12 PM

 
        To:     pregen@egenconsulting.com
        cc: 
        Subject:        Re: iRIP and CAP

pregen@egenconsulting.com wrote:

> A subset. Hm, interesting. And it may be quicker to get
> something cooked up if it was a subset.

Right.

> Other opinions?

Did you mean to send this to the list?

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |In the country of the blind, the one-eyed man is|
|francis@ecal.com|in therapy.                                     |
\=================================================================/





--=_alternative 00619C928525691F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Yes, I did mean to send this to the list. Thanks.<br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Pat R Egen/Egen Consulting/01 on 07/17/00 01:45 PM -----</font>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>John Stracke &lt;francis@ecal.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: francis@localhost.localdomain</font>
<p><font size=1 face="sans-serif">07/17/00 01:12 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;pregen@egenconsulting.com</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;Re: iRIP and CAP</font></table>
<br>
<br><font size=2><tt>pregen@egenconsulting.com wrote:<br>
<br>
&gt; A subset. Hm, interesting. And it may be quicker to get<br>
&gt; something cooked up if it was a subset.<br>
<br>
Right.<br>
<br>
&gt; Other opinions?<br>
<br>
Did you mean to send this to the list?<br>
<br>
--<br>
/=================================================================\<br>
|John Stracke &nbsp; &nbsp;| http://www.ecal.com |My opinions are my own. &nbsp; |<br>
|Chief Scientist |================================================|<br>
|eCal Corp. &nbsp; &nbsp; &nbsp;|In the country of the blind, the one-eyed man is|<br>
|francis@ecal.com|in therapy. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
\=================================================================/<br>
<br>
<br>
<br>
</tt></font>
<br>
--=_alternative 00619C928525691F_=--


From owner-ietf-calendar@mail.imc.org  Tue Jul 18 12:19:06 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11209
	for <calsch-archive@odin.ietf.org>; Tue, 18 Jul 2000 12:19:06 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA29693
	for ietf-calendar-bks; Tue, 18 Jul 2000 08:55:53 -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 IAA29688
	for <ietf-calendar@imc.org>; Tue, 18 Jul 2000 08:55:47 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: John Stracke <francis@ecal.com>
Cc: ietf-calendar@imc.org
Subject: Re: iRIP and CAP
X-Mailer: Lotus Notes Build V60_07162000 July 16, 2000
Message-ID: <OF3A0DAFA6.89141F1B-ON85256920.0056A2AB@iris.com>
Date: Tue, 18 Jul 2000 11:58:06 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at
 07/18/2000 11:58:19 AM,
	Serialize complete at 07/18/2000 11:58:19 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0057C8D685256920_="
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 0057C8D685256920_=
Content-Type: text/plain; charset="us-ascii"

John replied with:
>> This note is to query the list as to whether it needs to be
>> re-opened or scrapped.  There is an opinion that much of iRIP
>> is in CAP and does not really need to be a separate draft..
>
>It might be a good idea to have a draft specifying how to use CAP
>for iRIP-like functionality.  I'm thinking of a profile document,
>rather than a separate protocol, specifying a subset of CAP and
>the security considerations for the subset.

So it sounds like 1 vote to let iRIP expire.  Or did I misread your 
meaning?

Im also one who (quite a long time ago) voiced the thought that iRIP 
looked like CAP (or at least "CAP Lite" sic!).  While we did design iTIP 
so that we could later build iRIP, it seems that the WG has decided to 
forgo iRIP in favor of the snazzier CAP.  I think that iRIP would be a 
very very useful learning step for building CAP (and fixing up any 
mistakes or crocs we find while building iRIP) but Im in the minority. 
(Something I remember from childhood about "Learning to walk before 
learning to do marathons..." or some such idea)

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


<br><font size=2 face="sans-serif">John replied with:</font>
<br><font size=2 face="Courier New">&gt;&gt; This note is to query the list as to whether it needs to be<br>
&gt;&gt; re-opened or scrapped. &nbsp;There is an opinion that much of iRIP<br>
&gt;&gt; is in CAP and does not really need to be a separate draft..<br>
&gt;<br>
&gt;It might be a good idea to have a draft specifying how to use CAP<br>
&gt;for iRIP-like functionality. &nbsp;I'm thinking of a profile document,<br>
&gt;rather than a separate protocol, specifying a subset of CAP and<br>
&gt;the security considerations for the subset.</font>
<br>
<br><font size=2 face="sans-serif">So it sounds like 1 vote to let iRIP expire. &nbsp;Or did I misread your meaning?</font>
<br>
<br><font size=2 face="sans-serif">Im also one who (quite a long time ago) voiced the thought that iRIP looked like CAP (or at least &quot;CAP Lite&quot; sic!). &nbsp;While we did design iTIP so that we could later build iRIP, it seems that the WG has decided to forgo iRIP in favor of the snazzier CAP. &nbsp;I think that iRIP would be a very very useful learning step for building CAP (and fixing up any mistakes or crocs we find while building iRIP) but Im in the minority. &nbsp;(Something I remember from childhood about &quot;Learning to walk before learning to do marathons...&quot; or some such idea)</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 0057C8D685256920_=--


From owner-ietf-calendar@mail.imc.org  Tue Jul 18 12:21:01 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12399
	for <calsch-archive@odin.ietf.org>; Tue, 18 Jul 2000 12:21:00 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA29879
	for ietf-calendar-bks; Tue, 18 Jul 2000 09:01:26 -0700 (PDT)
Received: from localhost.localdomain ([216.52.68.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29875
	for <ietf-calendar@imc.org>; Tue, 18 Jul 2000 09:01:24 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA20965
	for <ietf-calendar@imc.org>; Tue, 18 Jul 2000 12:05:09 -0400
Message-ID: <39748035.6027CD2D@ecal.com>
Date: Tue, 18 Jul 2000 12:05:09 -0400
From: John Stracke <francis@ecal.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: ietf-calendar@imc.org
Subject: Re: iRIP and CAP
References: <OF3A0DAFA6.89141F1B-ON85256920.0056A2AB@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:

> So it sounds like 1 vote to let iRIP expire.  Or did I misread
> your meaning?

Mmm...I would actually prefer to see iRIP exist; I think
real-time iTIP has value.  But, if we can't do iRIP, then we
should do the subset.

Hmm.  OK, so Bruce and I want to finish iRIP.  I'm willing to
work on it; Bruce, are you? Does anybody have any objections to
seeing iRIP completed and standardized?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Solipsists have all the fun.                 |
|francis@ecal.com|                                             |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Tue Jul 18 12:47:59 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24962
	for <calsch-archive@odin.ietf.org>; Tue, 18 Jul 2000 12:47:58 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01208
	for ietf-calendar-bks; Tue, 18 Jul 2000 09:32:33 -0700 (PDT)
Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01203
	for <ietf-calendar@imc.org>; Tue, 18 Jul 2000 09:32:32 -0700 (PDT)
From: andrec@cst.ca
Received: from apollo.cst.ca (apollo.cst.ca [193.77.49.44])
	by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id MAA07060;
	Tue, 18 Jul 2000 12:34:24 -0400
Received: by apollo.CST.CA with Internet Mail Service (5.5.2650.21)
	id <3ZXXMPD2>; Tue, 18 Jul 2000 12:34:23 -0400
Message-ID: <D28949FC21D5D311843500104B6D1D8F043B91@apollo.CST.CA>
To: francis@ecal.com, ietf-calendar@imc.org
Subject: RE: iRIP and CAP
Date: Tue, 18 Jul 2000 12:34:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>


I think we should renew iRIP. At a minumum, it contains
good information should we want to include iRIP style
functionality in CAP.


-----Original Message-----
From: John Stracke [mailto:francis@ecal.com]
Sent: Tuesday, July 18, 2000 12:05 PM
To: ietf-calendar@imc.org
Subject: Re: iRIP and CAP


Bruce_Kahn@iris.com wrote:

> So it sounds like 1 vote to let iRIP expire.  Or did I misread
> your meaning?

Mmm...I would actually prefer to see iRIP exist; I think
real-time iTIP has value.  But, if we can't do iRIP, then we
should do the subset.

Hmm.  OK, so Bruce and I want to finish iRIP.  I'm willing to
work on it; Bruce, are you? Does anybody have any objections to
seeing iRIP completed and standardized?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Solipsists have all the fun.                 |
|francis@ecal.com|                                             |
\==============================================================/




From owner-ietf-calendar@mail.imc.org  Tue Jul 18 12:56:47 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29005
	for <calsch-archive@odin.ietf.org>; Tue, 18 Jul 2000 12:56:46 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01726
	for ietf-calendar-bks; Tue, 18 Jul 2000 09:40:23 -0700 (PDT)
Received: from home.royer.com (dsl-att1-115-136.sb.101freeway.net [12.44.115.136])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01722
	for <ietf-calendar@imc.org>; Tue, 18 Jul 2000 09:40:21 -0700 (PDT)
Received: (from doug@localhost)
	by home.royer.com (8.9.1/8.9.1) id JAA04982
	for ietf-calendar@imc.org; Tue, 18 Jul 2000 09:43:33 -0700 (PDT)
Date: Tue, 18 Jul 2000 09:43:33 -0700 (PDT)
From: Doug Royer <doug@home.royer.com>
Message-Id: <200007181643.JAA04982@home.royer.com>
To: ietf-calendar@imc.org
Subject: CAP draft update
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>


The CAP draft files have been updated on:

	ftp://royer.com/pub/CALSCH

The current cap drafit is:

	ftp://royer.com/pub/CALSCH/cap.txt.gz

Nroff and other source files including cap.txt:

	ftp://royer.com/pub/CALSCH/sources.tar.gz
	


From owner-ietf-calendar@mail.imc.org  Tue Jul 18 14:15:01 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28973
	for <calsch-archive@odin.ietf.org>; Tue, 18 Jul 2000 14:15:01 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA03273
	for ietf-calendar-bks; Tue, 18 Jul 2000 10:57:14 -0700 (PDT)
Received: from home.royer.com (dsl-att1-115-136.sb.101freeway.net [12.44.115.136])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03267
	for <ietf-calendar@imc.org>; Tue, 18 Jul 2000 10:57:12 -0700 (PDT)
Received: from home.royer.com (doug@home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA05270
	for <ietf-calendar@imc.org>; Tue, 18 Jul 2000 11:00:35 -0700 (PDT)
Message-ID: <39749B42.2A0A86BA@home.royer.com>
Date: Tue, 18 Jul 2000 11:00:34 -0700
From: Doug Royer <doug@home.royer.com>
Reply-To: Doug@royer.com
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: New CAP draft.
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


Email has been sent out about a new CAP draft.

What is done:

	I added 'sql-min' ABNF for what I propose is the minimum
	set of SQL commands. Plus how to specify that you support SQL-92.

	I added defaults for every capability reply - please review.

	I moved some of the editor notes from inside the invisible text,
	to inside the draft. See [EDITORS NOTE...]'s in draft.

	Formatting fixes.

	Added SQL examples using VQUERY.

-Doug


From owner-ietf-calendar@mail.imc.org  Tue Jul 18 14:17:48 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29732
	for <calsch-archive@odin.ietf.org>; Tue, 18 Jul 2000 14:17:48 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03467
	for ietf-calendar-bks; Tue, 18 Jul 2000 11:01:13 -0700 (PDT)
Received: from home.royer.com (dsl-att1-115-136.sb.101freeway.net [12.44.115.136])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03462
	for <ietf-calendar@imc.org>; Tue, 18 Jul 2000 11:01:12 -0700 (PDT)
Received: from home.royer.com (doug@home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA05279;
	Tue, 18 Jul 2000 11:04:13 -0700 (PDT)
Message-ID: <39749C1B.A5D8FF73@home.royer.com>
Date: Tue, 18 Jul 2000 11:04:11 -0700
From: Doug Royer <doug@home.royer.com>
Reply-To: Doug@royer.com
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: andrec@cst.ca
CC: francis@ecal.com, ietf-calendar@imc.org
Subject: Re: iRIP and CAP
References: <D28949FC21D5D311843500104B6D1D8F043B91@apollo.CST.CA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@mail.imc.org
Precedence: bulk
List-Archive: <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

andrec@cst.ca wrote:
> 
> I think we should renew iRIP. At a minumum, it contains
> good information should we want to include iRIP style
> functionality in CAP.

I think we already did that. That's why I am curious if
someone found something in iRIP that is not in CAP.

-Doug


From owner-ietf-calendar@mail.imc.org  Tue Jul 18 18:48:24 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01560
	for <calsch-archive@odin.ietf.org>; Tue, 18 Jul 2000 18:48:24 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA09637
	for ietf-calendar-bks; Tue, 18 Jul 2000 15:19:44 -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 PAA09633
	for <ietf-calendar@imc.org>; Tue, 18 Jul 2000 15:19:42 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: Pittsuburg - Monday evening dinner
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OFF74F3A13.D6BBED37-ON85256920.007AC1B9@com>
Date: Tue, 18 Jul 2000 18:22:08 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 07/18/2000 06:22:08 PM,
	Serialize complete at 07/18/2000 06:22:08 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 007AB9E785256920_="
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 007AB9E785256920_=
Content-Type: text/plain; charset="us-ascii"

We will once again do our usual Monday night get together on Monday night 
in Pittsburg.  Anyone wishing to go with us to dinner should meet in the 
lobby of the DoubleTree Hotel unless other wise advised on this list. 
We'll shoot for 6:30 pm.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
--=_alternative 007AB9E785256920_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">We will once again do our usual Monday night get together on Monday night in Pittsburg. &nbsp;Anyone wishing to go with us to dinner should meet in the lobby of the DoubleTree Hotel unless other wise advised on this list. &nbsp;We'll shoot for 6:30 pm.<br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
--=_alternative 007AB9E785256920_=--


From owner-ietf-calendar@mail.imc.org  Fri Jul 21 15:01:09 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08041
	for <calsch-archive@odin.ietf.org>; Fri, 21 Jul 2000 15:01:09 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15553
	for ietf-calendar-bks; Fri, 21 Jul 2000 11:30:53 -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 LAA15549
	for <ietf-calendar@imc.org>; Fri, 21 Jul 2000 11:30:51 -0700 (PDT)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id OAA02201;
	Fri, 21 Jul 2000 14:34:27 -0400
Message-ID: <397897B3.F0159491@ecal.com>
Date: Fri, 21 Jul 2000 14:34:27 -0400
From: John Stracke <francis@ecal.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: calsch WG <ietf-calendar@imc.org>
Subject: Timezones: STANDARD vs. DAYLIGHT; RDATE definition
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

It seems to me that there's no actual difference between STANDARD
and DAYLIGHT subcomponents of VTIMEZONE; they're treated
identically, and the two different words are just for clarity to
human readers.  Am I wrong?

Also, this sounds odd to me:

     Alternatively, the "RDATE" property can be used to
     define the onset of the observance by giving the
     individual onset date and times.  "RDATE" in this usage
     MUST be specified as a local DATE-TIME value in UTC
     time.

"Local" usually means "in the local timezone", which is pretty
much the opposite of "in UTC time".  Am I missing something?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |So what's the gene for belief in genetic     |
|francis@ecal.com|determinism?                                 |
\==============================================================/





From owner-ietf-calendar@mail.imc.org  Sat Jul 22 04:49:24 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15313
	for <calsch-archive@odin.ietf.org>; Sat, 22 Jul 2000 04:49:23 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id BAA19213
	for ietf-calendar-bks; Sat, 22 Jul 2000 01:29:57 -0700 (PDT)
Received: from home.royer.com (home.royer.com [12.44.115.136])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA19208
	for <ietf-calendar@imc.org>; Sat, 22 Jul 2000 01:29:55 -0700 (PDT)
Received: from home.royer.com (doug@home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id BAA12310;
	Sat, 22 Jul 2000 01:33:15 -0700 (PDT)
Message-ID: <39795C49.7B776300@home.royer.com>
Date: Sat, 22 Jul 2000 01:33:13 -0700
From: Doug Royer <doug@home.royer.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: calsch WG <ietf-calendar@imc.org>
Subject: Re: Timezones: STANDARD vs. DAYLIGHT; RDATE definition
References: <397897B3.F0159491@ecal.com>
Content-Type: multipart/mixed;
 boundary="------------C76CF8D774D662F7E0345194"
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.
--------------C76CF8D774D662F7E0345194
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Stracke wrote:
> 
> It seems to me that there's no actual difference between STANDARD
> and DAYLIGHT subcomponents of VTIMEZONE; they're treated
> identically, and the two different words are just for clarity to
> human readers.  Am I wrong?

That's how I read it. Some (few) places have more than two per year.
Too bad we only have two names.

> Also, this sounds odd to me:
> 
>      Alternatively, the "RDATE" property can be used to
>      define the onset of the observance by giving the
>      individual onset date and times.  "RDATE" in this usage
>      MUST be specified as a local DATE-TIME value in UTC
>      time.
> 
> "Local" usually means "in the local timezone", which is pretty
> much the opposite of "in UTC time".  Am I missing something?

I read this to mean - Local time in UTC:

US/Pacific is 7/8 hours from UTC. It is now about 1:30 local time,
or about 8:30 UTC. Two hours ago it would have been 23:30 local time
or (6:30 UTC - the next day).

I don't remember why it had to be in UTC however.

-Doug
--------------C76CF8D774D662F7E0345194
Content-Type: text/x-vcard; charset=us-ascii;
 name="doug.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="doug.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:650-274-8960 or pager@Royer.com
tel;cell:650-274-8960
tel;home:650-274-8960
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
version:2.1
email;internet:doug@home.royer.com
adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA
x-mozilla-cpt:;0
fn:Doug Royer
end:vcard

--------------C76CF8D774D662F7E0345194--



From owner-ietf-calendar@mail.imc.org  Sun Jul 23 03:16:39 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05181
	for <calsch-archive@odin.ietf.org>; Sun, 23 Jul 2000 03:16:38 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA08347
	for ietf-calendar-bks; Sat, 22 Jul 2000 23:57:26 -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 XAA08343
	for <ietf-calendar@imc.org>; Sat, 22 Jul 2000 23:57:24 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA00959
	for ietf-calendar@imc.org; Sun, 23 Jul 2000 00:00:03 -0700 (PDT)
Date: Sun, 23 Jul 2000 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200007230700.AAA00959@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	N
     text as commented on the list		Paul

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

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

 C-13 Post CAP-00.txt					Y

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

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

 C-21 Resubmit REQUIREMENTS draft.
 
------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:

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

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

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

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

 I-4 Add ALARMID to VALARM ?			Y

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


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

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



From owner-ietf-calendar@mail.imc.org  Sun Jul 23 14:30:18 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09015
	for <calsch-archive@odin.ietf.org>; Sun, 23 Jul 2000 14:30:18 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA00881
	for ietf-calendar-bks; Sun, 23 Jul 2000 11:13:44 -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 LAA00877
	for <ietf-calendar@imc.org>; Sun, 23 Jul 2000 11:13:42 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id LAA09531
	for ietf-calendar@imc.org; Sun, 23 Jul 2000 11:16:34 -0700 (PDT)
Date: Sun, 23 Jul 2000 11:16:34 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200007231816.LAA09531@royer.com>
X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r
To: ietf-calendar@imc.org
Subject: (update)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
 
------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:

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

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

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

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

 I-4 Add ALARMID to VALARM ?			Y

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


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

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



From owner-ietf-calendar@mail.imc.org  Sun Jul 23 14:32:28 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09672
	for <calsch-archive@odin.ietf.org>; Sun, 23 Jul 2000 14:32:27 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00904
	for ietf-calendar-bks; Sun, 23 Jul 2000 11:15:26 -0700 (PDT)
Received: from home.royer.com (home.royer.com [12.44.115.136])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00900
	for <ietf-calendar@imc.org>; Sun, 23 Jul 2000 11:15:25 -0700 (PDT)
Received: from home.royer.com (doug@home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA17109
	for <ietf-calendar@imc.org>; Sun, 23 Jul 2000 11:19:14 -0700 (PDT)
Message-ID: <397B3720.9CB71B25@home.royer.com>
Date: Sun, 23 Jul 2000 11:19:12 -0700
From: Doug Royer <doug@home.royer.com>
Reply-To: Doug@royer.com
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Near done
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


I have updated the TODO list.

There are a few editor notes in the draft. - most of the
work is done!!!

-Doug


From owner-ietf-calendar@mail.imc.org  Mon Jul 24 16:35:58 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28927
	for <calsch-archive@odin.ietf.org>; Mon, 24 Jul 2000 16:35:57 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA20920
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:19:10 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20912;
	Mon, 24 Jul 2000 13:19:09 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA15293; Mon, 24 Jul 2000 13:22:07 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA15282; Mon, 24 Jul 2000 13:22:06 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with
 ESMTP id NAA15712; Mon, 24 Jul 2000 13:22:41 -0700 (PDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA20612
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:14:08 -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 NAA20607;
	Mon, 24 Jul 2000 13:14:00 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA26266;
	Mon, 24 Jul 2000 16:17:35 -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 QAA22801;
	Mon, 24 Jul 2000 16:16:21 -0400 (EDT)
To: ietf-calendar@imc.org
Cc: calsch WG <ietf-calendar@imc.org>, owner-ietf-calendar@mail.imc.org
Subject: Re: Timezones: STANDARD vs. DAYLIGHT; RDATE definition
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF30183B13.EDF0AEAC-ON85256926.006F2747@lotus.com>
Date: Mon, 24 Jul 2000 16:15:58 -0400
X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Release 5.0.4 |June 8, 2000) at
 07/24/2000 04:15:59 PM,
	Serialize complete at 07/24/2000 04:15:59 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006F5BDD85256926_="
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>
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 006F5BDD85256926_=
Content-Type: text/plain; charset="us-ascii"

Doug Royer replied in part to John Stracke:
>> "Local" usually means "in the local timezone", which is pretty
>> much the opposite of "in UTC time".  Am I missing something?

>I read this to mean - Local time in UTC:

Most legislation for time zones specifies that the time zone change are to 
be made at a given local time, for example between 2AM and 4AM on the 
given date.
SO...using UTC time is not appropriate for the RDATE. It needs to be in 
local "floating" time. For example, 20000404T020000 for April 4, 2000 at 
2AM.
-- Frank
--=_alternative 006F5BDD85256926_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 face="Courier New">Doug Royer replied in part to John Stracke:</font>
<p><font size=2 face="Courier New">&gt;&gt; &quot;Local&quot; usually means &quot;in the local timezone&quot;, which is pretty<br>
&gt;&gt; much the opposite of &quot;in UTC time&quot;. &nbsp;Am I missing something?<br>
<br>
&gt;I read this to mean - Local time in UTC:</font>
<br>
<br><font size=3 face="Courier New">Most legislation for time zones specifies that the time zone change are to be made at a given local time, for example between 2AM and 4AM on the given date.</font>
<p><font size=3 face="Courier New">SO...using UTC time is not appropriate for the RDATE. It needs to be in local &quot;floating&quot; time. For example, 20000404T020000 for April 4, 2000 at 2AM.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 006F5BDD85256926_=--



From owner-ietf-calendar@mail.imc.org  Mon Jul 24 16:36:19 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29039
	for <calsch-archive@odin.ietf.org>; Mon, 24 Jul 2000 16:36:19 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA20966
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:20:25 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20960;
	Mon, 24 Jul 2000 13:20:24 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA17098; Mon, 24 Jul 2000 13:23:22 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA17089; Mon, 24 Jul 2000 13:23:21 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with
 ESMTP id NAA16187; Mon, 24 Jul 2000 13:23:56 -0700 (PDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA20941
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:19:48 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20935;
	Mon, 24 Jul 2000 13:19:47 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA16038; Mon, 24 Jul 2000 13:22:45 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA16017; Mon, 24 Jul 2000 13:22:45 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with
 ESMTP id NAA15912; Mon, 24 Jul 2000 13:23:19 -0700 (PDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA20920
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:19:10 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20912;
	Mon, 24 Jul 2000 13:19:09 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA15293; Mon, 24 Jul 2000 13:22:07 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA15282; Mon, 24 Jul 2000 13:22:06 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with
 ESMTP id NAA15712; Mon, 24 Jul 2000 13:22:41 -0700 (PDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA20612
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:14:08 -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 NAA20607;
	Mon, 24 Jul 2000 13:14:00 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA26266;
	Mon, 24 Jul 2000 16:17:35 -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 QAA22801;
	Mon, 24 Jul 2000 16:16:21 -0400 (EDT)
To: ietf-calendar@imc.org
Cc: calsch WG <ietf-calendar@imc.org>, owner-ietf-calendar@mail.imc.org
Subject: Re: Timezones: STANDARD vs. DAYLIGHT; RDATE definition
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF30183B13.EDF0AEAC-ON85256926.006F2747@lotus.com>
Date: Mon, 24 Jul 2000 16:15:58 -0400
X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Release 5.0.4 |June 8, 2000) at
 07/24/2000 04:15:59 PM,
	Serialize complete at 07/24/2000 04:15:59 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006F5BDD85256926_="
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>
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>
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>
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 006F5BDD85256926_=
Content-Type: text/plain; charset="us-ascii"

Doug Royer replied in part to John Stracke:
>> "Local" usually means "in the local timezone", which is pretty
>> much the opposite of "in UTC time".  Am I missing something?

>I read this to mean - Local time in UTC:

Most legislation for time zones specifies that the time zone change are to 
be made at a given local time, for example between 2AM and 4AM on the 
given date.
SO...using UTC time is not appropriate for the RDATE. It needs to be in 
local "floating" time. For example, 20000404T020000 for April 4, 2000 at 
2AM.
-- Frank
--=_alternative 006F5BDD85256926_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 face="Courier New">Doug Royer replied in part to John Stracke:</font>
<p><font size=2 face="Courier New">&gt;&gt; &quot;Local&quot; usually means &quot;in the local timezone&quot;, which is pretty<br>
&gt;&gt; much the opposite of &quot;in UTC time&quot;. &nbsp;Am I missing something?<br>
<br>
&gt;I read this to mean - Local time in UTC:</font>
<br>
<br><font size=3 face="Courier New">Most legislation for time zones specifies that the time zone change are to be made at a given local time, for example between 2AM and 4AM on the given date.</font>
<p><font size=3 face="Courier New">SO...using UTC time is not appropriate for the RDATE. It needs to be in local &quot;floating&quot; time. For example, 20000404T020000 for April 4, 2000 at 2AM.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 006F5BDD85256926_=--



From owner-ietf-calendar@mail.imc.org  Mon Jul 24 16:36:24 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29064
	for <calsch-archive@odin.ietf.org>; Mon, 24 Jul 2000 16:36:24 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA20612
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:14:08 -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 NAA20607;
	Mon, 24 Jul 2000 13:14:00 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA26266;
	Mon, 24 Jul 2000 16:17:35 -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 QAA22801;
	Mon, 24 Jul 2000 16:16:21 -0400 (EDT)
To: ietf-calendar@imc.org
Cc: calsch WG <ietf-calendar@imc.org>, owner-ietf-calendar@mail.imc.org
Subject: Re: Timezones: STANDARD vs. DAYLIGHT; RDATE definition
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF30183B13.EDF0AEAC-ON85256926.006F2747@lotus.com>
Date: Mon, 24 Jul 2000 16:15:58 -0400
X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Release 5.0.4 |June 8, 2000) at
 07/24/2000 04:15:59 PM,
	Serialize complete at 07/24/2000 04:15:59 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006F5BDD85256926_="
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 006F5BDD85256926_=
Content-Type: text/plain; charset="us-ascii"

Doug Royer replied in part to John Stracke:
>> "Local" usually means "in the local timezone", which is pretty
>> much the opposite of "in UTC time".  Am I missing something?

>I read this to mean - Local time in UTC:

Most legislation for time zones specifies that the time zone change are to 
be made at a given local time, for example between 2AM and 4AM on the 
given date.
SO...using UTC time is not appropriate for the RDATE. It needs to be in 
local "floating" time. For example, 20000404T020000 for April 4, 2000 at 
2AM.
-- Frank
--=_alternative 006F5BDD85256926_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 face="Courier New">Doug Royer replied in part to John Stracke:</font>
<p><font size=2 face="Courier New">&gt;&gt; &quot;Local&quot; usually means &quot;in the local timezone&quot;, which is pretty<br>
&gt;&gt; much the opposite of &quot;in UTC time&quot;. &nbsp;Am I missing something?<br>
<br>
&gt;I read this to mean - Local time in UTC:</font>
<br>
<br><font size=3 face="Courier New">Most legislation for time zones specifies that the time zone change are to be made at a given local time, for example between 2AM and 4AM on the given date.</font>
<p><font size=3 face="Courier New">SO...using UTC time is not appropriate for the RDATE. It needs to be in local &quot;floating&quot; time. For example, 20000404T020000 for April 4, 2000 at 2AM.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 006F5BDD85256926_=--


From owner-ietf-calendar@mail.imc.org  Mon Jul 24 16:37:17 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29289
	for <calsch-archive@odin.ietf.org>; Mon, 24 Jul 2000 16:37:16 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA20941
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:19:48 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20935;
	Mon, 24 Jul 2000 13:19:47 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA16038; Mon, 24 Jul 2000 13:22:45 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA16017; Mon, 24 Jul 2000 13:22:45 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with
 ESMTP id NAA15912; Mon, 24 Jul 2000 13:23:19 -0700 (PDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA20920
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:19:10 -0700 (PDT)
Received: from enigma.qualcomm.com (enigma.qualcomm.com [129.46.2.228])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20912;
	Mon, 24 Jul 2000 13:19:09 -0700 (PDT)
Received: (from root@localhost) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) id NAA15293; Mon, 24 Jul 2000 13:22:07 -0700 (PDT)
Received: from qualcomm.com (qualcomm.com [192.35.156.11]) by enigma.qualcomm.com (8.9.3/8.9.3/8.9) with ESMTP id NAA15282; Mon, 24 Jul 2000 13:22:06 -0700 (PDT)
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by qualcomm.com  with
 ESMTP id NAA15712; Mon, 24 Jul 2000 13:22:41 -0700 (PDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA20612
	for ietf-calendar-bks; Mon, 24 Jul 2000 13:14:08 -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 NAA20607;
	Mon, 24 Jul 2000 13:14:00 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id QAA26266;
	Mon, 24 Jul 2000 16:17:35 -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 QAA22801;
	Mon, 24 Jul 2000 16:16:21 -0400 (EDT)
To: ietf-calendar@imc.org
Cc: calsch WG <ietf-calendar@imc.org>, owner-ietf-calendar@mail.imc.org
Subject: Re: Timezones: STANDARD vs. DAYLIGHT; RDATE definition
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF30183B13.EDF0AEAC-ON85256926.006F2747@lotus.com>
Date: Mon, 24 Jul 2000 16:15:58 -0400
X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Release 5.0.4 |June 8, 2000) at
 07/24/2000 04:15:59 PM,
	Serialize complete at 07/24/2000 04:15:59 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006F5BDD85256926_="
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>
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>
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 006F5BDD85256926_=
Content-Type: text/plain; charset="us-ascii"

Doug Royer replied in part to John Stracke:
>> "Local" usually means "in the local timezone", which is pretty
>> much the opposite of "in UTC time".  Am I missing something?

>I read this to mean - Local time in UTC:

Most legislation for time zones specifies that the time zone change are to 
be made at a given local time, for example between 2AM and 4AM on the 
given date.
SO...using UTC time is not appropriate for the RDATE. It needs to be in 
local "floating" time. For example, 20000404T020000 for April 4, 2000 at 
2AM.
-- Frank
--=_alternative 006F5BDD85256926_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 face="Courier New">Doug Royer replied in part to John Stracke:</font>
<p><font size=2 face="Courier New">&gt;&gt; &quot;Local&quot; usually means &quot;in the local timezone&quot;, which is pretty<br>
&gt;&gt; much the opposite of &quot;in UTC time&quot;. &nbsp;Am I missing something?<br>
<br>
&gt;I read this to mean - Local time in UTC:</font>
<br>
<br><font size=3 face="Courier New">Most legislation for time zones specifies that the time zone change are to be made at a given local time, for example between 2AM and 4AM on the given date.</font>
<p><font size=3 face="Courier New">SO...using UTC time is not appropriate for the RDATE. It needs to be in local &quot;floating&quot; time. For example, 20000404T020000 for April 4, 2000 at 2AM.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 006F5BDD85256926_=--



From owner-ietf-calendar@mail.imc.org  Sun Jul 30 03:24:59 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11321
	for <calsch-archive@odin.ietf.org>; Sun, 30 Jul 2000 03:24:58 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA03508
	for ietf-calendar-bks; Sat, 29 Jul 2000 23:56:53 -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 XAA03502
	for <ietf-calendar@imc.org>; Sat, 29 Jul 2000 23:56:51 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA10890
	for ietf-calendar@imc.org; Sun, 30 Jul 2000 00:00:05 -0700 (PDT)
Date: Sun, 30 Jul 2000 00:00:05 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <200007300700.AAA10890@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
 
------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:

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

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

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

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

 I-4 Add ALARMID to VALARM ?			Y

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


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

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



From owner-ietf-calendar@mail.imc.org  Mon Jul 31 06:09:23 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01241
	for <calsch-archive@odin.ietf.org>; Mon, 31 Jul 2000 06:09:23 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id CAA01468
	for ietf-calendar-bks; Mon, 31 Jul 2000 02:43:28 -0700 (PDT)
Received: from ns.aav.co.jp (ns.aav.co.jp [210.237.157.209])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01360;
	Mon, 31 Jul 2000 02:40:23 -0700 (PDT)
From: MerchantPower@accept.fsnet.co.uk
Message-ID: <000052414abb$000025d4$000046bf@x179>
To: <MerchantPower@accept.fsnet.co.uk>
Subject: Payment Solution
Date: Mon, 31 Jul 2000 03:41:51 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

<html>

<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 4.0">
<meta name=3D"ProgId" content=3D"FrontPage.Editor.Document">
<title>If you would like to be removed from future mailings</title>
</head>

<body>

<p align=3D"center"><font face=3D"Arial" size=3D"2" ptsize=3D"8">If you wo=
uld like to be
removed from future mailings, please reply with the word remove.</font></p=
>
<hr>
<div align=3D"center">
<br>
<font color=3D"#0000FF"><b>Complete E-COMMERCE solutions to accept VISA,
MasterCard, <br>
American Express, Discover and Checks for your website, <br>
online store, traditional storefront or home based business.<br>
<br>
</font></b>
</font><font color=3D"#000000"><a href=3D"http://hypermart.homeloans:freey=
ellow.com@angelfire.com/pop/acceptme/">CLICK HERE</a><br>
<br>
</font><font size=3D4><b><i>WHAT WE OFFER<br>
<br>
</b>
</font></i><b><font size=3D3 color=3D"#008080">Bank-approved merchant acco=
unts
<br>
Real-time, online payment transactions <br>
Shopping carts <br>
Terminals &amp; printers <br>
99% approval rate <br>
<br>
</font><font size=3D4 color=3D"#000000"><i>A TURNKEY E-COMMERCE SOLUTION
FOR<br>
<br>
</font></i><font size=3D3 color=3D"#008080">Internet Storefront Businesses
<br>
Mail Order and Phone Order <br>
Start-up Businesses <br>
Traditional Retail Stores <br>
Home based Businesses<br>
<br>
</font><font color=3D"#0000FF">Good Credit / Bad Credit / No Credit <br>
**** </font><font color=3D"#FF0000">NO PROBLEM</font><font color=3D"#0000F=
F">
****<br>
<br>
</font></b><font color=3D"#000000"><a href=3D"http://hypermart.homeloans:f=
reeyellow.com@angelfire.com/pop/acceptme/">CLICK HERE</a><br>
<br>
</font><font color=3D"#0000FF"><b>ACCEPT CREDIT CARDS<br>
NO APPLICATION FEES<br>
For a Limited Time Only!<br>
<br>
Regular $195.00 Application Fee Waived For This Offer!<br>
<br>
<br>
</font></b><font color=3D"#000000">_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_=
/_/_/_/_/_/_/_/_/_/_/_/<br>
If you have received this message in error and would<br>
like to be removed from future mailings, please reply<br>
with the word remove in the subject.<br>
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/</font>

</body>

</html>





From owner-ietf-calendar@mail.imc.org  Mon Jul 31 11:21:21 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20370
	for <calsch-archive@odin.ietf.org>; Mon, 31 Jul 2000 11:21:18 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA09302
	for ietf-calendar-bks; Mon, 31 Jul 2000 07:54:20 -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 HAA09297;
	Mon, 31 Jul 2000 07:54:18 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA25891;
	Mon, 31 Jul 2000 10:58:42 -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 KAA18206;
	Mon, 31 Jul 2000 10:57:19 -0400 (EDT)
To: Doug Royer <Doug@royer.com>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org
Subject: Re: CALSCH Action Items
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OFA3823A9A.9D6B7267-ON8525692D.0051F326@lotus.com>
Date: Mon, 31 Jul 2000 10:56:54 -0400
X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Release 5.0.4 |June 8, 2000) at
 07/31/2000 10:56:57 AM,
	Serialize complete at 07/31/2000 10:56:57 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005226158525692D_="
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 005226158525692D_=
Content-Type: text/plain; charset="us-ascii"

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

Doug:
I have mentioned this before, but it has not been corrected in the Action 
Items yet. This is not an iCalendar item. This is an iTIP and iMIP item. 
The RFC2445 just specifies a format definition and text/calendar MIME 
media type registration. However, this requirement is germaine to the iTIP 
and iMIP specs. 
This Action Item should be changed to an iTIP/iMIP action item. FYI.
-- Frank
--=_alternative 005226158525692D_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="Courier New">&gt; I-1 MIME alternate/related &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; Frank &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ?<br>
&gt; &nbsp; &nbsp;MUST be supported.</font>
<br>
<br><font size=3 face="Courier New">Doug:</font>
<p><font size=3 face="Courier New">I have mentioned this before, but it has not been corrected in the Action Items yet. This is not an iCalendar item. This is an iTIP and iMIP item. The RFC2445 just specifies a format definition and text/calendar MIME media type registration. However, this requirement is germaine to the iTIP and iMIP specs. </font>
<p><font size=3 face="Courier New">This Action Item should be changed to an iTIP/iMIP action item. FYI.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 005226158525692D_=--


From owner-ietf-calendar@mail.imc.org  Mon Jul 31 13:05:08 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10709
	for <calsch-archive@odin.ietf.org>; Mon, 31 Jul 2000 13:05:06 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA16350
	for ietf-calendar-bks; Mon, 31 Jul 2000 09:38:29 -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 JAA16346
	for <ietf-calendar@imc.org>; Mon, 31 Jul 2000 09:38:28 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: Dinner in Pittsburgh
X-Mailer: Lotus Notes Release 5.0.2a  November 23, 1999
Message-ID: <OF077B477D.1CC6E24D-ON8525692D.005B5BF1@com>
Date: Mon, 31 Jul 2000 12:41:52 -0400
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.2a |November 23, 1999) at 07/31/2000 12:41:55 PM,
	Serialize complete at 07/31/2000 12:41:55 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005B6DC18525692D_="
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 005B6DC18525692D_=
Content-Type: text/plain; charset="us-ascii"

THis is to confirm that we are meeting in the lobby of the Doubletree 
Hotel at 7:00 pm this evening.  See you there
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
--=_alternative 005B6DC18525692D_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">THis is to confirm that we are meeting in the lobby of the Doubletree Hotel at 7:00 pm this evening. &nbsp;See you there<br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
--=_alternative 005B6DC18525692D_=--


From owner-ietf-calendar@mail.imc.org  Mon Jul 31 14:49:03 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23778
	for <calsch-archive@odin.ietf.org>; Mon, 31 Jul 2000 14:49:03 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA18465
	for ietf-calendar-bks; Mon, 31 Jul 2000 11:23: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 LAA18461
	for <ietf-calendar@imc.org>; Mon, 31 Jul 2000 11:23:15 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA24501;
	Mon, 31 Jul 2000 14:27:36 -0400 (EDT)
Received: from ismail.lotus.com (ISMAIL.lotus.com [9.95.4.115])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA24282;
	Mon, 31 Jul 2000 14:26:12 -0400 (EDT)
To: ietf-calendar@imc.org
Cc: Doug Royer <Doug@royer.com>, droyer@lotus.com
Subject: Re: CALSCH Action Items
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OF4785BF6D.C69C12EC-ON8525692D.006524F0@lotus.com>
Date: Mon, 31 Jul 2000 14:25:37 -0400
X-MIMETrack: Serialize by Router on ISMail/CAM/M/Lotus(Release 5.0.4 |June 8, 2000) at
 07/31/2000 02:25:50 PM,
	Serialize complete at 07/31/2000 02:25:50 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006541C78525692D_="
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 006541C78525692D_=
Content-Type: text/plain; charset="us-ascii"

Doug:
I remember the discussion on the list.
Problem is, iCalendar doesn't address MIME other than to register a 
text/calendar MIME type.
MIME encapsulation is addressed in iTIP and iMIP, though.
-- Frank

--=_alternative 006541C78525692D_=
Content-Type: text/html; charset="us-ascii"


<br><font size=3 face="Courier New">Doug:</font>
<p><font size=3 face="Courier New">I remember the discussion on the list.</font>
<p><font size=3 face="Courier New">Problem is, iCalendar doesn't address MIME other than to register a text/calendar MIME type.</font>
<p><font size=3 face="Courier New">MIME encapsulation is addressed in iTIP and iMIP, though.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 006541C78525692D_=--


From owner-ietf-calendar@mail.imc.org  Mon Jul 31 17:13:28 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16850
	for <calsch-archive@odin.ietf.org>; Mon, 31 Jul 2000 17:13:27 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA21360
	for ietf-calendar-bks; Mon, 31 Jul 2000 13:43:34 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21356
	for <ietf-calendar@imc.org>; Mon, 31 Jul 2000 13:43:33 -0700 (PDT)
Received: from Software.com ([147.73.134.105]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000731204745.CXFD459995.mta1biz.bizmailsrvcs.net@Software.com>;
          Mon, 31 Jul 2000 15:47:45 -0500
Message-ID: <3985D47D.F90B1CB2@Software.com>
Date: Mon, 31 Jul 2000 12:33:17 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank_Dawson@lotus.com, ietf-calendar@imc.org
Subject: Re: CALSCH Action Items
References: <OF4785BF6D.C69C12EC-ON8525692D.006524F0@lotus.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

Frank_Dawson@lotus.com wrote:
> 
> Doug:
> 
> I remember the discussion on the list.
> 
> Problem is, iCalendar doesn't address MIME other than to register a
> text/calendar MIME type.
> 
> MIME encapsulation is addressed in iTIP and iMIP, though.

1) The ONLY way to do a "external MIMIE entity" as described below,
   is if iCal support MULTIPART/RELATED. 

   (iCal) 4.1.3 Binary Content

     Binary content information in an iCalendar object SHOULD be
     referenced using a URI within a property value. That is the binary
     content information SHOULD be placed in an external MIME entity that
     can be referenced by a URI from within the iCalendar object. In
     applications where this is not feasible, binary content information

2)  And in (iCal) 4.8.4.2 Contact:

	...
   The following is an example of this property with an alternate
   representation of a MIME body part containing the contact
   information, such as a vCard [RFC 2426] embedded in a [MIME-DIR]
   content-type:

     CONTACT;ALTREP="CID=<part3.msg970930T083000SILVER@host.com>":Jim
       Dolittle\, ABC Industries\, +1-919-555-1234

   The ONLY way to do a CID, is with MULTIPART/RELATED.

3) Nowhere in RFC2445, do we say it is kinda-MIME, but not all of it.

-Doug