From owner-ietf-calendar@imc.org  Fri Oct  1 00:06:10 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28577
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 00:06:09 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id UAA13041
	for ietf-calendar-bks; Thu, 30 Sep 1999 20:38:00 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA13034
	for <ietf-calendar@imc.org>; Thu, 30 Sep 1999 20:37:58 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF762ED240.B367075F-ON852567FD.001406AA@com>
Date: Thu, 30 Sep 1999 23:38:51 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 09/30/99 11:38:54 PM
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_mixed 00140D0A852567FD_="
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

--=_mixed 00140D0A852567FD_=
Content-Type: multipart/alternative; boundary="=_alternative 00140D0A852567FD_="


--=_alternative 00140D0A852567FD_=
Content-Type: text/plain; charset="us-ascii"

Ok with me.




Doug Royer <Doug.Royer@software.com>
Sent by: owner-ietf-calendar@imc.org
09/30/99 03:35 PM
Please respond to ietf-calendar

 
        To:     ietf-calendar@imc.org
        cc: 
        Subject:        W-21 Get/Set user properties.


As there has been only a question (Richard), and no proposals.
Shall I consider this issue dead? (N status in the action item
list)


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


--=_alternative 00140D0A852567FD_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Ok with me.</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@imc.org</font>
<p><font size=1 face="sans-serif">09/30/99 03:35 PM</font>
<br><font size=1 face="sans-serif">Please respond to ietf-calendar</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;ietf-calendar@imc.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;W-21 Get/Set user properties.</font></table>
<br>
<br><font size=2><tt><br>
As there has been only a question (Richard), and no proposals.<br>
Shall I consider this issue dead? (N status in the action item<br>
list)<br>
<br>
<br>
-- <br>
Doug<br>
--------------------------------------------------------------------------<br>
Work: Doug.Royer@Software.com &nbsp; &nbsp; &nbsp;Home &nbsp; &nbsp;801 Woodside Rd #14-244<br>
 &nbsp; &nbsp; &nbsp;530 E. Montecito St. &nbsp; &nbsp; &nbsp; &nbsp; Office: Redwood City, CA 94061<br>
 &nbsp; &nbsp; &nbsp;Santa Barbara, CA 93103<br>
 &nbsp; &nbsp; &nbsp;805-957-1790 x541 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Personal Email: Doug@Royer.com</tt></font>
<br>
<br>
--=_alternative 00140D0A852567FD_=--
--=_mixed 00140D0A852567FD_=
Content-Type: application/octet-stream; name="ATT6EMWH"
Content-Disposition: attachment; filename="ATT6EMWH"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

YmVnaW46dmNhcmQgDQpuOlJveWVyO0RvdWcNCnRlbDtwYWdlcjpwYWdlckByb3llci5jb20gb3Ig
NjUwLTI3NC04OTYwDQp0ZWw7Y2VsbDo2NTAtMjc0LTg5NjANCnRlbDtmYXg6ODA1LTk1Ny0xNTQ0
DQp0ZWw7d29yazo4MDUtOTU3LTE3OTAgeDU0MQ0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpo
dHRwOi8vUm95ZXIuY29tL1Blb3BsZS9Eb3VnDQpvcmc6U29mdHdhcmUuY29tDQp2ZXJzaW9uOjIu
MQ0KZW1haWw7aW50ZXJuZXQ6RG91Zy5Sb3llckBTb2Z0d2FyZS5jb20NCnRpdGxlOkFyY2hpdGVj
dA0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs1MzAgRS4gTW9udGVjaXRvIFN0Lj0wRD0wQTtTYW50
YSBCYXJiYXJhO0NBOzkzMTAzO1UuUy5BDQpmbjpEb3VnIFJveWVyDQplbmQ6dmNhcmQNCg==
--=_mixed 00140D0A852567FD_=--


From owner-ietf-calendar@imc.org  Fri Oct  1 01:01:22 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29182
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 01:01:21 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id VAA17004
	for ietf-calendar-bks; Thu, 30 Sep 1999 21:30:55 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA16999
	for <ietf-calendar@imc.org>; Thu, 30 Sep 1999 21:30:54 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id VAA17875
	for <ietf-calendar@imc.org>; Thu, 30 Sep 1999 21:31:16 -0700 (PDT)
Received: from netscape.com ([205.217.229.90]) by
          tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id
          FIWPW300.LSH; Thu, 30 Sep 1999 21:31:15 -0700 
Message-ID: <37F43B66.10729293@netscape.com>
Date: Thu, 30 Sep 1999 21:41:10 -0700
From: rans@netscape.com (Richard Shusterman)
Reply-To: rans@netscape.com
Organization: Netscape Communications Corporation
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OF762ED240.B367075F-ON852567FD.001406AA@com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

I would appreciate a little time to respond to my emails :)

This action item was not a question. It was a placeholder for someone (I
suppose it should have been me) to propose a way for a CUA to retrieve
user properties from a CS using CAP. Examples of user properties that
would be useful to a CUA:

   * First and last name of this user.
   * A default calendar to fetch for this user.
   * The URI's that are described by the draft-ietf-calsch-locating
     document.

This "capability" would be especially useful to thin client CUA's that
don't want/need to implement code to contact a directory server to
get/set these user properties. Also, the CUA would only need to prompt
for a login name/password if the CUA could retrieve the above user
properties from the CS.

So, I will try to get together such a proposal (by early next week) and
submit it to this WG.

Richard

pregen@egenconsulting.com wrote:

>
> Ok with me.
>
>
>  Doug Royer
   <Doug.Royer@software.com>                    To:
   Sent by:                             ietf-calendar@imc.org
   owner-ietf-calendar@imc.org                  cc:
                                                Subject:        W-21
   09/30/99 03:35 PM                    Get/Set user properties.
   Please respond to ietf-calendar
>
>
>
> As there has been only a question (Richard), and no proposals.
> Shall I consider this issue dead? (N status in the action item
> list)
>
>
> --
> Doug
>
> -------------------------------------------------------------------------
>
> 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@imc.org  Fri Oct  1 07:33:16 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12525
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 07:33:15 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id DAA09357
	for ietf-calendar-bks; Fri, 1 Oct 1999 03:52:11 -0700 (PDT)
Received: from stardivision.de (ns.stardivision.de [62.156.160.99])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA09351
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 03:52:10 -0700 (PDT)
Received: from tlx-1011.stardiv.de (tlx-1011.stardiv.de [172.17.1.11])
	by stardivision.de (8.9.0/8.9.0) with SMTP id MAA10365
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 12:53:07 +0200
From: Thorsten Laux <tlx@stardivision.de>
Date: Fri, 01 Oct 1999 10:56:33 GMT
Message-ID: <19991001.10563362@tlx-1011.stardiv.de>
Subject: Re: CAP and Timezones/Recurrence/Queries
To: ietf-calendar@imc.org
In-Reply-To: <37F3C8E8.7EC24C74@Software.com>
References: <OF54763FB9.57A76E6F-ON852567FC.006D9B8E@Lotus.com> <37F3C8E8.7EC24C74@Software.com>
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Win32)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.imc.org id DAA09353
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit



>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<

Am 30.09.99, 22:32:40, schrieb Doug Royer <Doug.Royer@software.com> zum 
Thema Re: CAP and Timezones/Recurrence/Queries:


> Frank_Dawson@lotus.com wrote:
> >
> > Doug Royer wrote, in part:
> >
> > >This implies that the CUA already knows the UID of an event.
> > >If the query is for a date-time range there does not seem
> > >to be a way to say send me the 'raw' iCalendar data or
> > >'expand' the recurrences for me.
> >
> > The scenarios that I have seen in meetings and hear discussed was a
> > CUA would query for the events within a given date/time window. For
> > example, for a UI of next 5 days, what are the events occurring in
> > this interval. Assuming that the server unzips any recurring events to
> > find events that overlap the window (this is a good assumption or the
> > whole system model is caput), then the return can be forced to be UID,
> > DTSTART, DTEND and RECURRENCE-ID and sorted by UID or even DSTART.
> > With this initial query results you can certainly determine (a) if an
> > event is a recurring one or not and also the UID of the parent.
> >
> > Did you have a different and new scenario in mind?

> Yes.

> How do you (as I understand the original post asked) get the events
> non-un-zipped) as in the raw data?

> Example:

>       The owner of an event wishes to modify an event.
>       The CU does not know the UID, so they would want
>       to fetch say a VEVENT by SUMMARY. They do not want it
>       unzipped, and it would consume bandwidth. The CUA just
>       needs the original VEVENT as PUBLISHed. So it can be
>       modified and sent back to the CS with CAP.

>       If the VEVENT was daily, do you want or need 29-31
>       copies of the event - if you only want to modify it.

>       When the VEVENT is displayed in a calendar, then
>       yes - it needs to be unzipped.


A common example for this is to have all events rendered in list form. 
Since a list opposed to the standard time views enforces no time limit 
on its events you have to resort to showing parents of recurrence 
series to keep the result set limited.

Thorsten





From owner-ietf-calendar@imc.org  Fri Oct  1 07:39:52 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12663
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 07:39:51 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id DAA09167
	for ietf-calendar-bks; Fri, 1 Oct 1999 03:49:14 -0700 (PDT)
Received: from stardivision.de (ns.stardivision.de [62.156.160.99])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA09162
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 03:49:11 -0700 (PDT)
Received: from tlx-1011.stardiv.de (tlx-1011.stardiv.de [172.17.1.11])
	by stardivision.de (8.9.0/8.9.0) with SMTP id MAA10328;
	Fri, 1 Oct 1999 12:50:05 +0200
From: Thorsten Laux <tlx@stardivision.de>
Date: Fri, 01 Oct 1999 10:53:31 GMT
Message-ID: <19991001.10533127@tlx-1011.stardiv.de>
Subject: Re: CAP and Timezones/Recurrence/Queries
To: Frank_Dawson@lotus.com
CC: ietf-calendar@imc.org
References: <OF5054EED1.BE5666C6-ON852567FC.005FBA85@Lotus.com>
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Win32)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------=_4D4800BF3CD403879F14"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

--------------=_4D4800BF3CD403879F14
Content-Description: filename="text1.txt"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Urspr=FCngliche Nachricht vom 30.09.99, 19:35:15
Autor: Frank_Dawson@lotus.com
Thema: Re: CAP and Timezones/Recurrence/Queries



Thorsten Laux wrote, in part:=20
>1. From the cap draft I can't seem to figure out, how queries can=20
>specify whether they want recurrent events to be returned only once=20=

>(the start of the series) or once for every occurrence in the queried=20=

>time span. It hopefully is not the burden of the CUA to calculate all=20=

>recurrences from the base event!? You would specify a WHERE clause=20
either for the UID for the parent, to get the whole recurrence=20
definition, the RECURRENCE-ID for a particular recurrence instance, to=20=

get an individual occurrence, the RECURRENCE-ID and RECTYPE (i.e.,=20
"THISANDBEFORE" or "THISANDAFTER"), to get a range of recurrences.
>2. How do I specify the timezone of a datetime in a query? I suppose=20=

>the CUA does not have to readjust its query time span into GMT?=20
>Burdening the CUA with timezone calculations means calculating=20
>recurrence rules which I don't think is a good idea for CUAs to be=20
>forced to. In the same context wouldn't it be a good idea to have the=20=

>CUA identify its timezone to the CS and then let the CS do all=20
>timezone conversions for the client? The CS has to be able to do the=20=

>conversions anyway since it has (as I suppose) to calculate=20
recurrence=20
>instances. Why not let it do all conversion work. Having to do this=20=

in=20
>two places is error prone - especially given the vast reservoir of=20
>recurrence rules. It is clear of course that the tzid would still=20
have=20
>to be transmitted since it indicates the timezone, the date is tied=20=

>to.
Yes, specifying the date/time in terms of UTC (NOTE: GMT is=20
deprecated. We all use UTC as the absolute time format) is the way to=20=

go. The CAP server would need to adjust/translate into absolute time=20=

of UTC. But good question. This should be noted in the specification.=20=

Actually, CUAs will have to be able to do time zone conversion for=20
many UI displays of data anyway. If you have a date/time in "floating"=20=

time, you will have to display this in your UI in the local time zone=20=

of the CUA. In addition, the most common form for specification of=20
iCalendar DTSTART and DTEND properties will be UTC based format of=20
time. You only need a time zone when a recurring event is specified.=20=

So, the CUA will have to UTC to local time conversion all the time anywa=
y.
Floating time simply means that no conversion needs to be done=20
(neither on CS nor on CUA), doesn't it? The reason I am mentioning the=20=

timezone issue is that in our product we have been sparing the CUA=20
entirely of timezone calculations and this works quite well for us.=20
From our view point the data in the vevents container can be viewed=20
from different viewpoints. The viewpoint consists of the access rights=20=

the viewing person is granted, of the timezone, the viewer resides in=20=

and whether he wants to see recurring events replicated. Thus clients=20=

and client apis need to know hardly anything about timezones (only if=20=

they want to schedule events outside their own timezone which is=20
hardly ever the case). Isn't the existence of timezones a nasty=20
implementation detail of how world time works that should be hidden as=20=

good as possible from clients? Actually we could leave the choice to=20=

the client by providing TZ convertion functions in our sql subset:
select tzconv( dtstart, MEZ), tzconv( dtend, MEZ ) where tzconf(=20
dtstart, MEZ ) < endtime and tzconf( dtend, MEZ ) > starttime.
This also would allow to query on floating events:
select * where tzconv( dtstart, MEZ ) =3D=3D dtstart and tzconf( dtstart=
,=20
MEZ+1) =3D=3D dtstart.
Since greater and lower for datetimes appearantly is supposed to mean=20=

greater and lower in UTC (since queries have to be formulated in UTC)=20=

we have no way to query correctly for a range containing floating=20
events since they will happily float to their UTC representation=20
(Server doesn't know clients timezone). Tzconv() would fix that, too.
As regarding the recurrence problem I would say that for the client=20
either all events are held replicated in the server or they are not. If =

they are, I have to include recurrenceID =3D=3D dtstart to your where cl=
ause=20
containing the uid to get the parent (and careful! Without recurrence Id=
=20
or time range you have endlessly many events -> illegal query). Having=20=

the server replicate only if one mentions recurrence ids seems very=20
unclear to me. Now if the event that I want to query as parent is in the=
=20
exclusion list of its recurences things get harry again (it is not one=20=

of its recurrences). It seems to me, that the recurring event container =

and the plain event container although they hold the same data are so=20=

different when they are accessed that one should use two containers for =

query purposes (for examlple vevent and vrecurringevent).



--------------=_4D4800BF3CD403879F14
Content-Description: filename="text1.html"
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
	<TITLE>Re: CAP and Timezones/Recurrence/Queries</TITLE>
	<META NAME=3D"GENERATOR" CONTENT=3D"StarOffice/5.1 (Win32)">
	<META NAME=3D"CREATED" CONTENT=3D"19991001;11010611">
	<META NAME=3D"CHANGEDBY" CONTENT=3D"Thorsten Laux">
	<META NAME=3D"CHANGED" CONTENT=3D"19991001;12532970">
</HEAD>
<BODY>
<P><BR><BR>
</P>
<HR>
<P ALIGN=3DLEFT>Urspr&uuml;ngliche Nachricht vom 30.09.99, 19:35:15</P>=

<P ALIGN=3DLEFT>Autor: Frank_Dawson@lotus.com</P>
<P ALIGN=3DLEFT>Thema: Re: CAP and Timezones/Recurrence/Queries</P>
<HR>
<P><BR><BR>
</P>
<P><BR><FONT SIZE=3D3><FONT FACE=3D"Courier New">Thorsten Laux wrote, in=

part:</FONT></FONT>=20
</P>
<P><FONT SIZE=3D2><FONT FACE=3D"Courier New">&gt;1. From the cap draft I=

can't seem to figure out, how queries can <BR>&gt;specify whether they
want recurrent events to be returned only once <BR>&gt;(the start of
the series) or once for every occurrence in the queried <BR>&gt;time
span. It hopefully is not the burden of the CUA to calculate all
<BR>&gt;recurrences from the base event!?</FONT></FONT> <FONT SIZE=3D3><=
FONT FACE=3D"Courier New">You
would specify a WHERE clause either for the UID for the parent, to get
the whole recurrence definition, the RECURRENCE-ID for a particular
recurrence instance, to get an individual occurrence, the RECURRENCE-ID=

and RECTYPE (i.e., &quot;THISANDBEFORE&quot; or &quot;THISANDAFTER&quot;=
),
to get a range of recurrences.</FONT></FONT></P>
<P><FONT FACE=3D"Courier New"><FONT SIZE=3D2>&gt;2. How do I specify the=

timezone of a datetime in a query? I suppose <BR>&gt;the CUA does not
have to readjust its query time span into GMT? <BR>&gt;Burdening the
CUA with timezone calculations means calculating <BR>&gt;recurrence
rules which I don't think is a good idea for CUAs to be <BR>&gt;forced
to. In the same context wouldn't it be a good idea to have the <BR>&gt;C=
UA
identify its timezone to the CS and then let the CS do all <BR>&gt;timez=
one
conversions for the client? The CS has to be able to do the
<BR>&gt;conversions anyway since it has (as I suppose) to calculate
recurrence <BR>&gt;instances. Why not let it do all conversion work.
Having to do this in <BR>&gt;two places is error prone - especially
given the vast reservoir of <BR>&gt;recurrence rules. It is clear of
course that the tzid would still have <BR>&gt;to be transmitted since
it indicates the timezone, the date is tied <BR>&gt;to.</FONT></FONT></P=
>
<P><FONT SIZE=3D3><FONT FACE=3D"Courier New"><FONT COLOR=3D"#0000ff">Yes=
,
specifying the date/time in terms of UTC (NOTE: GMT is deprecated. We
all use UTC as the absolute time format) is the way to go. The CAP
server would need to adjust/translate into absolute time of UTC. But
good question. This should be noted in the specification.</FONT></FONT><=
/FONT>
</P>
<P><FONT COLOR=3D"#0000ff"><FONT FACE=3D"Courier New"><FONT SIZE=3D3>Act=
ually,
CUAs will have to be able to do time zone conversion for many UI
displays of data anyway. If you have a date/time in &quot;floating&quot;=

time, you will have to display this in your UI in the local time zone
of the CUA. In addition, the most common form for specification of
iCalendar DTSTART and DTEND properties will be UTC based format of
time. You only need a time zone when a recurring event is specified.
So, the CUA will have to UTC to local time conversion all the time
anyway.</FONT></FONT></FONT></P>
<P>Floating time simply means that no conversion needs to be done
(neither on CS nor on CUA), doesn't it? The reason I am mentioning the
timezone issue is that in our product we have been sparing the CUA
entirely of timezone calculations and this works quite well for us.
From our view point the data in the vevents container can be viewed
from different viewpoints. The viewpoint consists of the access rights
the viewing person is granted, of the timezone, the viewer resides in
and whether he wants to see recurring events replicated. Thus clients
and client apis need to know hardly anything about timezones (only if
they want to schedule events outside their own timezone which is hardly=

ever the case). Isn't the existence of timezones a nasty implementation=

detail of how world time works that should be hidden as good as
possible from clients? Actually we could leave the choice to the client=

by providing TZ convertion functions in our sql subset:</P>
<P>select tzconv( dtstart, MEZ), tzconv( dtend, MEZ ) where tzconf(
dtstart, MEZ ) &lt; endtime and tzconf( dtend, MEZ ) &gt; starttime.</P>=

<P>This also would allow to query on floating events:</P>
<P>select * where tzconv( dtstart, MEZ ) =3D=3D dtstart and tzconf(
dtstart, MEZ+1) =3D=3D dtstart.</P>
<P>Since greater and lower for datetimes appearantly is supposed to
mean greater and lower in UTC (since queries have to be formulated in
UTC) we have no way to query correctly for a range containing floating
events since they will happily float to their UTC representation
(Server doesn't know clients timezone). Tzconv() would fix that, too.</P=
>
<P>As regarding the recurrence problem I would say that for the client
either all events are held replicated in the server or they are not. If=

they are, I have to include recurrenceID =3D=3D dtstart to your where
clause containing the uid to get the parent (and careful! Without
recurrence Id or time range you have endlessly many events -&gt;
illegal query). Having the server replicate only if one mentions
recurrence ids seems very unclear to me. Now if the event that I want
to query as parent is in the exclusion list of its recurences things
get harry again (it is not one of its recurrences). It seems to me,
that the recurring event container and the plain event container
although they hold the same data are so different when they are
accessed that one should use two containers for query purposes (for
examlple vevent and vrecurringevent).</P>
<P><BR><BR>
</P>
</BODY>
</HTML>

--------------=_4D4800BF3CD403879F14--



From owner-ietf-calendar@imc.org  Fri Oct  1 11:49:20 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17567
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 11:49:19 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id HAA16276
	for ietf-calendar-bks; Fri, 1 Oct 1999 07:52:38 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA16270
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 07:52:36 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA26663;
	Fri, 1 Oct 1999 11:05:34 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA01642;
	Fri, 1 Oct 1999 10:51:40 -0400 (EDT)
To: Thorsten Laux <tlx@stardivision.de>
Cc: ietf-calendar@imc.org
Subject: Re: CAP and Timezones/Recurrence/Queries
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OFBE648F6F.B085715B-ON852567FD.005275C1@Lotus.com>
Date: Fri, 1 Oct 1999 11:04:43 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/01/99 11:05:04 AM,
	Serialize complete at 10/01/99 11:05:05 AM,
	Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/01/99 11:05:05 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00524892852567FD_="
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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

Thorsten Laux wrote, in part:
>A common example for this is to have all events rendered in list form. 
>Since a list opposed to the standard time views enforces no time limit 
>on its events you have to resort to showing parents of recurrence 
>series to keep the result set limited.

Obviously, a list structure isn't ideal to represent an infinitely 
repeating event (e.g., FREQ=WEEKLY). 
I think the answer to Doug's earlier comment is that if you query based on 
a WHERE UID="123", then you get back the definition for the base event. If 
it is a recurring event, then you get the original definition of the 
VEVENT. If you specified WHERE (UID="123" RECURRENCE-ID=" <date/ time of 
the first occurence), then you would get the unzipped definition of the 
first occurrence (i.e., the one specified by the DTSTART/DTEND) in the 
zipped definition for the event.
-- Frank


--=_alternative 00524892852567FD_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Thorsten Laux wrote, in part:</font>
<p><font size=2 face="Courier New">&gt;A common example for this is to have all events rendered in list form. <br>
&gt;Since a list opposed to the standard time views enforces no time limit <br>
&gt;on its events you have to resort to showing parents of recurrence <br>
&gt;series to keep the result set limited.</font>
<br>
<br><font size=3 face="Courier New">Obviously, a list structure isn't ideal to represent an infinitely repeating event (e.g., FREQ=WEEKLY). </font>
<p><font size=3 face="Courier New">I think the answer to Doug's earlier comment is that if you query based on a WHERE UID=&quot;123&quot;, then you get back the definition for the base event. If it is a recurring event, then you get the original definition of the VEVENT. If you specified WHERE (UID=&quot;123&quot; RECURRENCE-ID=&quot; &lt;date/ time of the first occurence), then you would get the unzipped definition of the first occurrence (i.e., the one specified by the DTSTART/DTEND) in the zipped definition for the event.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p><font size=3 face="Courier New"><br>
</font>
--=_alternative 00524892852567FD_=--


From owner-ietf-calendar@imc.org  Fri Oct  1 12:06:29 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17909
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 12:06:29 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id IAA16668
	for ietf-calendar-bks; Fri, 1 Oct 1999 08:14:50 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA16664
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 08:14:49 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA29508;
	Fri, 1 Oct 1999 11:28:02 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA06256;
	Fri, 1 Oct 1999 11:14:08 -0400 (EDT)
To: rans@netscape.com
Cc: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OFA045385E.85FCF4DD-ON852567FD.00544BA3@Lotus.com>
Date: Fri, 1 Oct 1999 11:27:28 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/01/99 11:27:33 AM,
	Serialize complete at 10/01/99 11:27:33 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00545DA3852567FD_="
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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

Richard Schusterman wrote, in part:
>This action item was not a question. It was a placeholder for someone (I
>suppose it should have been me) to propose a way for a CUA to retrieve
>user properties from a CS using CAP. Examples of user properties that
>would be useful to a CUA:
>
>   * First and last name of this user.
>   * A default calendar to fetch for this user.
>   * The URI's that are described by the draft-ietf-calsch-locating
>     document.

The assumption then is that the "user profile" is a server function. Okay. 
That answers my earlier question.
However, I don't believe that this was a user requirement in the 
requirements document. Right? If not, then this should be deferred to a 
future version as it appears that we have a full plate of functions, as it 
is.
Even if this is a current requirement, I question the merits of it. In 
current practice, "user profiles" for applications can be kept in the CUA, 
the CS or even in a common directory. I prefer the former, but can also 
see rationale for the latter. However, to stuff this kind of 
meta-information about a CUA in the CS doesn't seem to me to be the 
direction that the rest of the world is taking. What if the server is down 
and the CUA wants to access a backup server? How does it get to this 
information? By going to the backup server's copy of the "user profile"? 
That is data redundancy and also leaves open the opportunity for data 
integrity discrepancies due to delays or errors in synchronization between 
the two profile's settings. In addition, this approach wouldn't seem to 
scale very well.
I suggest, mark this as closed or defer it.
-- Frank

--=_alternative 00545DA3852567FD_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Richard Schusterman wrote, in part:</font>
<p><font size=2 face="Courier New">&gt;This action item was not a question. It was a placeholder for someone (I<br>
&gt;suppose it should have been me) to propose a way for a CUA to retrieve<br>
&gt;user properties from a CS using CAP. Examples of user properties that<br>
&gt;would be useful to a CUA:<br>
&gt;<br>
&gt; &nbsp; * First and last name of this user.<br>
&gt; &nbsp; * A default calendar to fetch for this user.<br>
&gt; &nbsp; * The URI's that are described by the draft-ietf-calsch-locating<br>
&gt; &nbsp; &nbsp; document.</font>
<br>
<br><font size=3 face="Courier New">The assumption then is that the &quot;user profile&quot; is a server function. Okay. That answers my earlier question.</font>
<p><font size=3 face="Courier New">However, I don't believe that this was a user requirement in the requirements document. Right? If not, then this should be deferred to a future version as it appears that we have a full plate of functions, as it is.</font>
<p><font size=3 face="Courier New">Even if this is a current requirement, I question the merits of it. In current practice, &quot;user profiles&quot; for applications can be kept in the CUA, the CS or even in a common directory. I prefer the former, but can also see rationale for the latter. However, to stuff this kind of meta-information about a CUA in the CS doesn't seem to me to be the direction that the rest of the world is taking. What if the server is down and the CUA wants to access a backup server? How does it get to this information? By going to the backup server's copy of the &quot;user profile&quot;? That is data redundancy and also leaves open the opportunity for data integrity discrepancies due to delays or errors in synchronization between the two profile's settings. In addition, this approach wouldn't seem to scale very well.</font>
<p><font size=3 face="Courier New">I suggest, mark this as closed or defer it.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 00545DA3852567FD_=--


From owner-ietf-calendar@imc.org  Fri Oct  1 14:24:14 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20331
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 14:24:12 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id KAA18976
	for ietf-calendar-bks; Fri, 1 Oct 1999 10:36:38 -0700 (PDT)
Received: from stardivision.de (ns.stardivision.de [62.156.160.99])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA18972
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 10:36:36 -0700 (PDT)
Received: from tlx-1011.stardiv.de (tlx-1011.stardiv.de [172.17.1.11])
	by stardivision.de (8.9.0/8.9.0) with SMTP id TAA25592;
	Fri, 1 Oct 1999 19:37:23 +0200
From: Thorsten Laux <tlx@stardivision.de>
Date: Fri, 01 Oct 1999 17:40:49 GMT
Message-ID: <19991001.17404927@tlx-1011.stardiv.de>
Subject: Re: CAP and Timezones/Recurrence/Queries
To: Frank_Dawson@lotus.com
CC: ietf-calendar@imc.org
In-Reply-To: <OFBE648F6F.B085715B-ON852567FD.005275C1@Lotus.com>
References: <OFBE648F6F.B085715B-ON852567FD.005275C1@Lotus.com>
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Win32)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------=_4D480128181104EF97DC"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

--------------=_4D480128181104EF97DC
Content-Description: filename="text1.txt"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Thorsten Laux wrote, in part:=20
>A common example for this is to have all events rendered in list=20
form.=20
>Since a list opposed to the standard time views enforces no time=20
limit=20
>on its events you have to resort to showing parents of recurrence=20
>series to keep the result set limited.=20

Obviously, a list structure isn't ideal to represent an infinitely=20
repeating event (e.g., FREQ=3DWEEKLY).=20
I think the answer to Doug's earlier comment is that if you query=20
based on a WHERE UID=3D"123", then you get back the definition for the=20=

base event. If it is a recurring event, then you get the original=20
definition of the VEVENT. If you specified WHERE (UID=3D"123"=20
RECURRENCE-ID=3D" <date/ time of the first occurence), then you would=20=

get the unzipped definition of the first occurrence (i.e., the one=20
specified by the DTSTART/DTEND) in the zipped definition for the=20
event.=20
-- Frank=20
Are you saying that unzipping takes place if and only if the property=20=

RECURRENCE-ID is used in the where clause? So to query all unzipped=20
occurrences in a time intervall you would have to say WHERE DTEND>x=20
AND DTSTART<y AND RECURRENCE-ID LIKE %. I think that can and should be=20=

said more explicit.=20
Thorsten


--------------=_4D480128181104EF97DC
Content-Description: filename="text1.html"
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
	<TITLE>Re: CAP and Timezones/Recurrence/Queries</TITLE>
	<META NAME=3D"GENERATOR" CONTENT=3D"StarOffice/5.1 (Win32)">
	<META NAME=3D"CREATED" CONTENT=3D"19991001;19305296">
	<META NAME=3D"CHANGEDBY" CONTENT=3D"Thorsten Laux">
	<META NAME=3D"CHANGED" CONTENT=3D"19991001;19404839">
</HEAD>
<BODY>
<P><BR><FONT SIZE=3D3><FONT FACE=3D"Courier New">Thorsten Laux wrote, in=

part:</FONT></FONT>=20
</P>
<P><FONT SIZE=3D2><FONT FACE=3D"Courier New">&gt;A common example for th=
is
is to have all events rendered in list form. <BR>&gt;Since a list
opposed to the standard time views enforces no time limit <BR>&gt;on
its events you have to resort to showing parents of recurrence <BR>&gt;s=
eries
to keep the result set limited.</FONT></FONT> <BR><BR><FONT SIZE=3D3><FO=
NT FACE=3D"Courier New">Obviously,
a list structure isn't ideal to represent an infinitely repeating event=

(e.g., FREQ=3DWEEKLY). </FONT></FONT>
</P>
<P><FONT SIZE=3D3><FONT FACE=3D"Courier New">I think the answer to Doug'=
s
earlier comment is that if you query based on a WHERE UID=3D&quot;123&qu=
ot;,
then you get back the definition for the base event. If it is a
recurring event, then you get the original definition of the VEVENT. If=

you specified WHERE (UID=3D&quot;123&quot; RECURRENCE-ID=3D&quot; &lt;da=
te/
time of the first occurence), then you would get the unzipped
definition of the first occurrence (i.e., the one specified by the
DTSTART/DTEND) in the zipped definition for the event.</FONT></FONT>=20=

</P>
<P><FONT SIZE=3D3><FONT FACE=3D"Courier New">-- Frank</FONT></FONT>=20
</P>
<P><FONT FACE=3D"Courier New"><FONT SIZE=3D3>Are you saying that unzippi=
ng
takes place if and only if the property RECURRENCE-ID is used in the
where clause? So to query all unzipped occurrences in a time intervall
you would have to say WHERE DTEND&gt;x AND DTSTART&lt;y AND
RECURRENCE-ID LIKE %. I think that can and should be said more
explicit. </FONT></FONT>
</P>
<P><FONT FACE=3D"Courier New"><FONT SIZE=3D3>Thorsten</FONT></FONT></P>=

</BODY>
</HTML>

--------------=_4D480128181104EF97DC--



From owner-ietf-calendar@imc.org  Fri Oct  1 14:59:44 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20946
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 14:59:44 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id LAA19752
	for ietf-calendar-bks; Fri, 1 Oct 1999 11:28:24 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA19747
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 11:28:22 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA21469;
	Fri, 1 Oct 1999 14:41:32 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA04867;
	Fri, 1 Oct 1999 14:27:31 -0400 (EDT)
To: Thorsten Laux <tlx@stardivision.de>
Cc: ietf-calendar@imc.org
Subject: Re: CAP and Timezones/Recurrence/Queries
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OFA6ADCBB9.CAE0CF9C-ON852567FD.0066282F@Lotus.com>
Date: Fri, 1 Oct 1999 14:40:53 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/01/99 02:40:59 PM,
	Serialize complete at 10/01/99 02:40:59 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006612DB852567FD_="
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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

Thorsten:
The iCalendar and iTIP specification is assumed as a model and system base 
for any of the CAP discussions. Certainly, we have extensions to this base 
in CAP, also. Just to re-enforce this here, though.
So...
...Then there are only two ways to specify recurrence instances. One is 
with RRULE and RDATE in the original VEVENT/REQUEST (or PUBLISH). The 
other is with a VEVENT/ADD method that is used to add instances to an 
existing calendar component. Hence, my observation that if you query a CS 
with a CAP query statement that specifies a UID, then in the case of a 
recurring event, this is semantically how you ask for the complete event 
definition. Also, if you ask for an event specifying a  RECURRENCE-ID, 
then you are asking for a recurrence instance.
This seemed implicit, but you are right, we need examples in CAP to 
demonstrate how these various scenarios are played out in actual CAP 
commands. THANKS for pointing this out!
-- Frank

--=_alternative 006612DB852567FD_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Thorsten:</font>
<p><font size=3 face="Courier New">The iCalendar and iTIP specification is assumed as a model and system base for any of the CAP discussions. Certainly, we have extensions to this base in CAP, also. Just to re-enforce this here, though.</font>
<p><font size=3 face="Courier New">So...</font>
<p><font size=3 face="Courier New">...Then there are only two ways to specify recurrence instances. One is with RRULE and RDATE in the original VEVENT/REQUEST (or PUBLISH). The other is with a VEVENT/ADD method that is used to add instances to an existing calendar component. Hence, my observation that if you query a CS with a CAP query statement that specifies a UID, then in the case of a recurring event, this is semantically how you ask for the complete event definition. Also, if you ask for an event specifying a &nbsp;RECURRENCE-ID, then you are asking for a recurrence instance.</font>
<p><font size=3 face="Courier New">This seemed implicit, but you are right, we need examples in CAP to demonstrate how these various scenarios are played out in actual CAP commands. THANKS for pointing this out!</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 006612DB852567FD_=--


From owner-ietf-calendar@imc.org  Fri Oct  1 15:08:36 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21171
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 15:08:35 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id LAA19825
	for ietf-calendar-bks; Fri, 1 Oct 1999 11:32:10 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA19820
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 11:32:09 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id LAA10285
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 11:32:38 -0700 (PDT)
Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com
          (Netscape Messaging Server 4.1) with ESMTP id FIXSUE00.KXD; Fri,
          1 Oct 1999 11:32:38 -0700 
Message-ID: <37F4FE73.59742DD0@netscape.com>
Date: Fri, 01 Oct 1999 11:33:23 -0700
From: rans@netscape.com (Richard Shusterman)
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.61 [en]C-NSCP  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OFA045385E.85FCF4DD-ON852567FD.00544BA3@Lotus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Let's not mix implementation details (like where the user profile is
stored and whether it has to be sync'ed between two servers) with CUA
and CS requirements for CAP. Although the original CAP requirements (for
example, access control used to be a deferred requirement) did not list
a CUA requirement to get/set user profiles, it did state that CAP must
support "How to allow for CUAs without local store and with minimal
memory."

So, what I'm arguing for here is a optional capability that, if
implemented by the CS, allows a CUA to get/set basic user profile
information. Where this user profile is stored should not be part of
CAP. We just need to define the commands/responses that allows the CUA
to get/set this information thru a CS. At a minimum, we should at least
define the "get" command/response so that a CUA does not have to store
or prompt for the user's first/last name and calid - all it needs from
the user is a login name/password.

As for the "direction that the rest of the world is taking", I actually
think there is a movement towards smaller (thin) clients vs larger (fat)
clients. This argues for making sure that a small, thin CUA can be a
reasonable calendar application without keeping local storage or having
to implement multiple protocols.

Frank_Dawson@lotus.com wrote:

>
> Richard Shusterman wrote, in part:
>
> >This action item was not a question. It was a placeholder for someone
> (I
> >suppose it should have been me) to propose a way for a CUA to
> retrieve
> >user properties from a CS using CAP. Examples of user properties that
>
> >would be useful to a CUA:
> >
> >   * First and last name of this user.
> >   * A default calendar to fetch for this user.
> >   * The URI's that are described by the draft-ietf-calsch-locating
> >     document.
>
> The assumption then is that the "user profile" is a server function.
> Okay. That answers my earlier question.
>
> However, I don't believe that this was a user requirement in the
> requirements document. Right? If not, then this should be deferred to
> a future version as it appears that we have a full plate of functions,
> as it is.
>
> Even if this is a current requirement, I question the merits of it. In
> current practice, "user profiles" for applications can be kept in the
> CUA, the CS or even in a common directory. I prefer the former, but
> can also see rationale for the latter. However, to stuff this kind of
> meta-information about a CUA in the CS doesn't seem to me to be the
> direction that the rest of the world is taking. What if the server is
> down and the CUA wants to access a backup server? How does it get to
> this information? By going to the backup server's copy of the "user
> profile"? That is data redundancy and also leaves open the opportunity
> for data integrity discrepancies due to delays or errors in
> synchronization between the two profile's settings. In addition, this
> approach wouldn't seem to scale very well.
>
> I suggest, mark this as closed or defer it.
>
> -- Frank
>
>



From owner-ietf-calendar@imc.org  Fri Oct  1 16:02:27 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22181
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 16:02:24 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id MAA20935
	for ietf-calendar-bks; Fri, 1 Oct 1999 12:26:10 -0700 (PDT)
Received: from komarr.local.thibault.org (adsl-151-197-16-76.bellatlantic.net [151.197.16.76])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA20931
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 12:26:09 -0700 (PDT)
Received: from ariel.local.thibault.org (ariel.local.thibault.org [192.168.10.18])
	by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id PAA27742
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 15:26:23 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.local.thibault.org (8.8.7/8.8.7) with ESMTP id PAA07295
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 15:26:39 -0400
Message-ID: <37F50AEF.B0A67D01@ecal.com>
Date: Fri, 01 Oct 1999 15:26:39 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OFA045385E.85FCF4DD-ON852567FD.00544BA3@Lotus.com> <37F4FE73.59742DD0@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Richard Shusterman wrote:

> So, what I'm arguing for here is a optional capability that, if
> implemented by the CS, allows a CUA to get/set basic user profile
> information.

This sounds like it'd be redundant with ACAP (Application Configuration
Access Protocol, RFC-2244).  I think a monolayer client should probably use
ACAP directly rather than shoehorning identical functionality into CAP.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Life is like a metaphor.                     |
|francis@ecal.com|                                             |
\==============================================================/





From owner-ietf-calendar@imc.org  Fri Oct  1 18:22:03 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24286
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 18:21:51 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id OAA23671
	for ietf-calendar-bks; Fri, 1 Oct 1999 14:44:21 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA23667
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 14:44:20 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id OAA07187
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 14:44:51 -0700 (PDT)
Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com
          (Netscape Messaging Server 4.1) with ESMTP id FIY1QQ00.S0T for
          <ietf-calendar@imc.org>; Fri, 1 Oct 1999 14:44:50 -0700 
Message-ID: <37F52B7E.20056F00@netscape.com>
Date: Fri, 01 Oct 1999 14:45:35 -0700
From: rans@netscape.com (Richard Shusterman)
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.61 [en]C-NSCP  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OFA045385E.85FCF4DD-ON852567FD.00544BA3@Lotus.com> <37F4FE73.59742DD0@netscape.com> <37F50AEF.B0A67D01@ecal.com> <37F52B01.1BECE4CC@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Oops, forgot to CC the working group.

Richard Shusterman wrote:

> Uh, what's ACAP got to do with this discussion? Why not suggest LDAP instead
> (it's more widespread)?
>
> What I'm trying to say is that small (thin) CUAs do not want to talk to
> multiple servers and use multiple protocols. For example, such a CUA might
> simply want to connect to a CS, authenticate as user X, fetch user X's default
> calid Y, and then disconnect.
>
> X does not necessarily equal Y, that Y is required as a target for all CAP
> application commands, and that Y may be a long string of characters (to
> guarantee unique of calid's) that user X has not memorized.
>
> Hmmm, one way to avoid having this CUA request user X's default calid Y would
> be for Y to be returned as part of the AUTHENTICATE command response. If we can
> at least add this response to CAP, that may be sufficient for this first
> version of CAP. It would be real nice to have a way to "pass thru" simple
> directory queries/responses thru CAP (to what is probably an external user
> directory) ...
>
> John Stracke wrote:
>
> > Richard Shusterman wrote:
> >
> > > So, what I'm arguing for here is a optional capability that, if
> > > implemented by the CS, allows a CUA to get/set basic user profile
> > > information.
> >
> > This sounds like it'd be redundant with ACAP (Application Configuration
> > Access Protocol, RFC-2244).  I think a monolayer client should probably use
> > ACAP directly rather than shoehorning identical functionality into CAP.



From owner-ietf-calendar@imc.org  Fri Oct  1 22:38:16 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28021
	for <calsch-archive@odin.ietf.org>; Fri, 1 Oct 1999 22:38:15 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id SAA01895
	for ietf-calendar-bks; Fri, 1 Oct 1999 18:58:36 -0700 (PDT)
Received: from tyr.siebel.com ([209.37.100.162])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id SAA01889
	for <ietf-calendar@imc.org>; Fri, 1 Oct 1999 18:58:35 -0700 (PDT)
Received: from 10.1.24.31 by tyr.siebel.com with SMTP (WorldSecure
 Server SMTP Relay(WSS) v4.0.1); Fri, 01 Oct 99 18:58:59 -0700
X-Server-Uuid: 345c517b-5fb4-11d3-a613-00508b3222df
Received: from 208.184.76.39 by tyr.siebel.com with SMTP (WorldSecure
 Server SMTP Relay(WSS) v3.2 SR1); Thu, 30 Sep 99 11:48:40 -0700
X-Server-Uuid: 61afff7a-dbde-11d2-be31-0008c74c62f4
Received: by mail.imc.org (8.9.3/8.9.3) id LAA21854 for
 ietf-calendar-bks; Thu, 30 Sep 1999 11:44:15 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net
 [206.46.164.2]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA21850
 for <ietf-calendar@imc.org>; Thu, 30 Sep 1999 11:44:14 -0700 (PDT)
Received: from Software.com ([207.175.94.238]) by
 mta2biz.bizmailsrvcs.net with ESMTP id
 <19990930184438.BCOX363884.mta2biz@Software.com> for
 <ietf-calendar@imc.org>; Thu, 30 Sep 1999 13:44:38 -0500
Message-ID: <37F3AF8D.27AD9764@Software.com>
Date: Thu, 30 Sep 1999 11:44:29 -0700
From: "Doug Royer" <Doug.Royer@software.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
cc: ietf-calendar@imc.org
Subject: Re: CAP and Timezones/Recurrence/Queries
References: <19990930.16492083@tlx-1011.stardiv.de>
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:
 ietf-calendar-request@imc.org?body=unsubscribe>
X-WSS-ID: 1BEBB9698317-01-01
Content-Type: multipart/mixed; 
 boundary=------------ACE9F0986A6B2A429B9B07EB
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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



Thorsten Laux wrote:
> 
> 1. From the cap draft I can't seem to figure out, how queries can
> specify whether they want recurrent events to be returned only once
> (the start of the series) or once for every occurrence in the queried
> time span. It hopefully is not the burden of the CUA to calculate all
> recurrences from the base event!?

Your right. In the requirements doc is (our used to be) a requirement
to address this issue. It has not been addressed yet.

Suggestions?

I have added this as issue 'W-27' to the action item list.

> 2. How do I specify the timezone of a datetime in a query? I suppose
> the CUA does not have to readjust its query time span into GMT?
> Burdening the CUA with timezone calculations means calculating
> recurrence rules which I don't think is a good idea for CUAs to be
> forced to. In the same context wouldn't it be a good idea to have the
> CUA identify its timezone to the CS and then let the CS do all
> timezone conversions for the client? The CS has to be able to do the
> conversions anyway since it has (as I suppose) to calculate recurrence
> instances. Why not let it do all conversion work. Having to do this in
> two places is error prone - especially given the vast reservoir of
> recurrence rules. It is clear of course that the tzid would still have
> to be transmitted since it indicates the timezone, the date is tied
> to.

The current thoughts were that the CUA would have to be aware of
its own timeline anyway. So if the CUA only queries the CS for time
in GMT then the CUA would not have to download all of the timelines
in the CS in order to make a query.

The CS is going to have to know how to process timelines anyway.
And the CUA is going to have to know its own timeline.

Does this work for you?

-- 
Doug
--------------------------------------------------------------------------
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
--------------ACE9F0986A6B2A429B9B07EB
Content-Type: text/x-vcard; 
 charset=us-ascii; 
 name=Doug.Royer.vcf
Content-Description: Card for Doug Royer
Content-Disposition: attachment; 
 filename=Doug.Royer.vcf
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------ACE9F0986A6B2A429B9B07EB--



From owner-ietf-calendar@imc.org  Sun Oct  3 04:21:05 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05643
	for <calsch-archive@odin.ietf.org>; Sun, 3 Oct 1999 04:21:04 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id AAA28638
	for ietf-calendar-bks; Sun, 3 Oct 1999 00:42:15 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA28633
	for <ietf-calendar@imc.org>; Sun, 3 Oct 1999 00:42:14 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA29680
	for ietf-calendar@imc.org; Sun, 3 Oct 1999 00:00:03 -0700 (PDT)
Date: Sun, 3 Oct 1999 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <199910030700.AAA29680@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@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
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		U
     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

 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			U
     <there were issues - I can't remember
     them>

 W-9 CAP MOVE method. Issues with VCARs.	U
     [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				U
 
 W-14 CAP VEVENT Schema				U
 
 W-15 CAP VTODO Schema				U
 
 W-16 CAP VJOURNAL Schema			U
 
 W-17 CAP VCAR Schema				U

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

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

 W-21 CAP Get/Set calendar user properties	U

 W-22 VTIMEZONE and IANA			U

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

 W-24 CAP Calendar CHARSET property issues	U

 W-25 Remove MUST from UID in 4.8.4.7		U

 W-26 Write/Submit information draft/rfc	Y

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

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

 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

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

 The following are a list of action items for the iCalendar-2 draft editors:
 
 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.

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


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@imc.org  Sun Oct  3 21:50:21 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12194
	for <calsch-archive@odin.ietf.org>; Sun, 3 Oct 1999 21:50:20 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id SAA12458
	for ietf-calendar-bks; Sun, 3 Oct 1999 18:12:26 -0700 (PDT)
Received: from komarr.local.thibault.org (adsl-151-197-16-76.bellatlantic.net [151.197.16.76])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA12451
	for <ietf-calendar@imc.org>; Sun, 3 Oct 1999 18:12:23 -0700 (PDT)
Received: from ariel.local.thibault.org (ariel.local.thibault.org [192.168.10.18])
	by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id VAA30418
	for <ietf-calendar@imc.org>; Sun, 3 Oct 1999 21:12:38 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.local.thibault.org (8.8.7/8.8.7) with ESMTP id VAA13662
	for <ietf-calendar@imc.org>; Sun, 3 Oct 1999 21:12:57 -0400
Message-ID: <37F7FF17.1E3846B3@ecal.com>
Date: Sun, 03 Oct 1999 21:12:55 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OFA045385E.85FCF4DD-ON852567FD.00544BA3@Lotus.com> <37F4FE73.59742DD0@netscape.com> <37F50AEF.B0A67D01@ecal.com> <37F52B01.1BECE4CC@netscape.com> <37F52B7E.20056F00@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Richard Shusterman wrote:

> > Uh, what's ACAP got to do with this discussion?

Everything.  You're talking about application configuration information, after all.

> > What I'm trying to say is that small (thin) CUAs do not want to talk to
> > multiple servers and use multiple protocols.

How exactly is it worse for a thin client to speak CAP and ACAP than to speak
CAP-with-ACAP-like-features-thrown-in? I can think of a few ways separate protocols
are better for a thin client, actually:

   * Separate protocols means you can deploy separate servers if you want, which
     means better scalability.  Since the server is the bottleneck for all your thin
     clients, scalability is essential.
   * Smaller protocols means simpler servers, which, again, means better
     scalability.
   * Simpler servers can mean better security, since it's easier to do a security
     analysis.
   * Simpler servers are cheaper.

> > It would be real nice to have a way to "pass thru" simple
> > directory queries/responses thru CAP (to what is probably an external user
> > directory) ...

How simple? Wherever you draw the line, sooner or later you'll find a use case that
says you need something more complicated; before you know it, you've got the whole
camel in the tent with you.  Just use the existing protocols.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Beware of wizards, for you are crunchy and good|
|francis@ecal.com|with ketchup.                                  |
\================================================================/





From owner-ietf-calendar@imc.org  Mon Oct  4 11:13:41 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03432
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 11:13:41 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id HAA06635
	for ietf-calendar-bks; Mon, 4 Oct 1999 07:34:00 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA06631
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 07:33:56 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA09896;
	Mon, 4 Oct 1999 10:47:22 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA25408;
	Mon, 4 Oct 1999 10:33:22 -0400 (EDT)
To: rans@netscape.com (Richard Shusterman)
Cc: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF321431A9.FE208609-ON85256800.0044422C@Lotus.com>
Date: Mon, 4 Oct 1999 10:45:52 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/04/99 10:46:10 AM,
	Serialize complete at 10/04/99 10:46:10 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0044E8E185256800_="
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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

Richard:
It appears that your suggestion regards CAP as some "uber protocol". I 
don't hold that opinion. We should recognize that CAP needs to keep within 
well defined boundaries or we will find ourselves feature-creaping and not 
have the bandwidth/resources to complete our basic set of work.
The definition of server based user-profiles is a considerable amount of 
work and is a new work item. For example, we will need to study what kinds 
of properties define a CUA setup. This could go on for some time. In 
addition, we will have to have some work on the server side too. For 
example, will these properties need to be specified at the server-level, 
calendar-level or both? Should the profile be a new calendar component or 
just individual properties.
This is not something that can just be arbitrarily added to our scope of 
work. Do you have a formal proposal prepared for this work?
-- Frank

--=_alternative 0044E8E185256800_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Richard:</font>
<p><font size=3 face="Courier New">It appears that your suggestion regards CAP as some &quot;uber protocol&quot;. I don't hold that opinion. We should recognize that CAP needs to keep within well defined boundaries or we will find ourselves feature-creaping and not have the bandwidth/resources to complete our basic set of work.</font>
<p><font size=3 face="Courier New">The definition of server based user-profiles is a considerable amount of work and is a new work item. For example, we will need to study what kinds of properties define a CUA setup. This could go on for some time. In addition, we will have to have some work on the server side too. For example, will these properties need to be specified at the server-level, calendar-level or both? Should the profile be a new calendar component or just individual properties.</font>
<p><font size=3 face="Courier New">This is not something that can just be arbitrarily added to our scope of work. Do you have a formal proposal prepared for this work?</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 0044E8E185256800_=--


From owner-ietf-calendar@imc.org  Mon Oct  4 11:13:50 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03444
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 11:13:50 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id HAA06768
	for ietf-calendar-bks; Mon, 4 Oct 1999 07:39:07 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA06764
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 07:39:06 -0700 (PDT)
Received: from Software.com ([207.175.94.130]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991004143950.DES484239.mta2biz.bizmailsrvcs.net@Software.com>;
          Mon, 4 Oct 1999 09:39:50 -0500
Message-ID: <37F8BC2D.49464C6D@Software.com>
Date: Mon, 04 Oct 1999 07:39:41 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OFA045385E.85FCF4DD-ON852567FD.00544BA3@Lotus.com>
Content-Type: multipart/mixed;
 boundary="------------A5C495239C9E20EC10B180C3"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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



Frank_Dawson@lotus.com wrote:

> The assumption then is that the "user profile" is a server function.
> Okay. That answers my earlier question.
> 
> However, I don't believe that this was a user requirement in the
> requirements document. Right? If not, then this should be deferred to
> a future version as it appears that we have a full plate of functions,
> as it is.

I also don't think it was in cap requirements.
 
> Even if this is a current requirement, I question the merits of it. In
> current practice, "user profiles" for applications can be kept in the
> CUA, the CS or even in a common directory. I prefer the former, but
> can also see rationale for the latter. However, to stuff this kind of
> meta-information about a CUA in the CS doesn't seem to me to be the
> direction that the rest of the world is taking. What if the server is
> down and the CUA wants to access a backup server? How does it get to
> this information? By going to the backup server's copy of the "user
> profile"? That is data redundancy and also leaves open the opportunity
> for data integrity discrepancies due to delays or errors in
> synchronization between the two profile's settings. In addition, this
> approach wouldn't seem to scale very well.
> 
> I suggest, mark this as closed or defer it.

ACAP is where user prefs go. I am willing to see Richard's proposal
before we close it in case there is something we missed.

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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------A5C495239C9E20EC10B180C3--



From owner-ietf-calendar@imc.org  Mon Oct  4 11:14:10 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03455
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 11:14:09 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id HAA06957
	for ietf-calendar-bks; Mon, 4 Oct 1999 07:46:23 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA06953
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 07:46:21 -0700 (PDT)
Received: from Software.com ([207.175.94.130]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991004144706.DFT484239.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 09:47:06 -0500
Message-ID: <37F8BDE2.8889E2F0@Software.com>
Date: Mon, 04 Oct 1999 07:46:58 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: CAP and Timezones/Recurrence/Queries
References: <OFBE648F6F.B085715B-ON852567FD.005275C1@Lotus.com> <19991001.17404927@tlx-1011.stardiv.de>
Content-Type: multipart/mixed;
 boundary="------------B81E3BE679B7DFE30E6DAEF1"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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



Thorsten Laux wrote:

> 
> Are you saying that unzipping takes place if and only if the property
> RECURRENCE-ID is used in the where clause? So to query all unzipped
> occurrences in a time intervall you would have to say WHERE DTEND>x
> AND DTSTART<y AND RECURRENCE-ID LIKE %. I think that can and should be
> said more explicit.

I agree.

-- 
Doug
--------------------------------------------------------------------------
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
--------------B81E3BE679B7DFE30E6DAEF1
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------B81E3BE679B7DFE30E6DAEF1--



From owner-ietf-calendar@imc.org  Mon Oct  4 11:35:14 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03847
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 11:35:13 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id HAA07259
	for ietf-calendar-bks; Mon, 4 Oct 1999 07:58:11 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA07253
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 07:58:10 -0700 (PDT)
Received: from Software.com ([207.175.94.130]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991004145854.DHX484239.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 09:58:54 -0500
Message-ID: <37F8C0A6.C0271F0B@Software.com>
Date: Mon, 04 Oct 1999 07:58:46 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OFA045385E.85FCF4DD-ON852567FD.00544BA3@Lotus.com> <37F4FE73.59742DD0@netscape.com> <37F50AEF.B0A67D01@ecal.com> <37F52B01.1BECE4CC@netscape.com> <37F52B7E.20056F00@netscape.com>
Content-Type: multipart/mixed;
 boundary="------------DBA66FDCEFCC8A33AC21E58B"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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



Richard Shusterman wrote:
> 
> Oops, forgot to CC the working group.
> 
> Richard Shusterman wrote:
> 
> > Uh, what's ACAP got to do with this discussion?

I agree with John. It looks like what you want is ACAP.

> Why not suggest LDAP instead (it's more widespread)?

Different issue. LDAP is a phone book and a protocol
to that phone book. ACAP is a protocol that describes how
to Get/Set user properties.

> >
> > What I'm trying to say is that small (thin) CUAs do not want to talk to
> > multiple servers and use multiple protocols. For example, such a CUA might
> > simply want to connect to a CS, authenticate as user X, fetch user X's\
> > default calid Y, and then disconnect.

I agree. However a lot of time was spent on ACAP on those issues.

> > X does not necessarily equal Y, that Y is required as a target for all CAP
> > application commands, and that Y may be a long string of characters (to
> > guarantee unique of calid's) that user X has not memorized.
> >
> > Hmmm, one way to avoid having this CUA request user X's default calid Y
> > would be for Y to be returned as part of the AUTHENTICATE command
> > response. If we can at least add this response to CAP, that may be 
> > sufficient for this first version of CAP. It would be real nice to
> > have a way to "pass thru" simple directory queries/responses thru
> > CAP (to what is probably an external user directory) ...

I understand the issues now that you have explained them - thanks.

But Frank is right in that maybe this needs to be a separate task.
Lets design CAP so that something like this could be added in the
future. However I don't see it as a MUST at this time.

> > John Stracke wrote:
> >
> > > Richard Shusterman wrote:
> > >
> > > > So, what I'm arguing for here is a optional capability that, if
> > > > implemented by the CS, allows a CUA to get/set basic user profile
> > > > information.
> > >
> > > This sounds like it'd be redundant with ACAP (Application Configuration
> > > Access Protocol, RFC-2244).  I think a monolayer client should probably use
> > > ACAP directly rather than shoehorning identical functionality into CAP.

-- 
Doug
--------------------------------------------------------------------------
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
--------------DBA66FDCEFCC8A33AC21E58B
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------DBA66FDCEFCC8A33AC21E58B--



From owner-ietf-calendar@imc.org  Mon Oct  4 17:56:38 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09389
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 17:56:37 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id OAA17076
	for ietf-calendar-bks; Mon, 4 Oct 1999 14:20:03 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA17072
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 14:20:02 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id OAA24211
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 14:20:43 -0700 (PDT)
Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com
          (Netscape Messaging Server 4.1) with ESMTP id FJ3KMJ00.NAT; Mon,
          4 Oct 1999 14:20:43 -0700 
Message-ID: <37F91A56.B667743B@netscape.com>
Date: Mon, 04 Oct 1999 14:21:26 -0700
From: rans@netscape.com (Richard Shusterman)
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.61 [en]C-NSCP  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OF321431A9.FE208609-ON85256800.0044422C@Lotus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Frank_Dawson@lotus.com wrote:

> It appears that your suggestion regards CAP as some "uber protocol". I
> don't hold that opinion. We should recognize that CAP needs to keep
> within well defined boundaries or we will find ourselves
> feature-creaping and not have the bandwidth/resources to complete our
> basic set of work.
>
> The definition of server based user-profiles is a considerable amount
> of work and is a new work item. For example, we will need to study
> what kinds of properties define a CUA setup. This could go on for some
> time. In addition, we will have to have some work on the server side
> too. For example, will these properties need to be specified at the
> server-level, calendar-level or both? Should the profile be a new
> calendar component or just individual properties.
>
> This is not something that can just be arbitrarily added to our scope
> of work. Do you have a formal proposal prepared for this work?

Nope and I think we've beat this topic to death for now. Doug, please
close this work item.

My intention was/is not to overload CAP. What I was trying to do was
bring up one of the issues that has come up in offline CAP discussions.
Now that we've discussed this on the mailing list, I'm satisfied.

BTW, anyone have a good client and server implementation of ACAP to
offer :)

From the CAP draft:

"... There is no implied structure in a Relative CALID. It is an
arbitrary string of 7 bit ASCII characters. It may refer to the calendar
of a user or of a  resource such as a conference room. It MUST be unique
within the calendar store. It is recommended that the Relative CALID be
globally unique."

In a large population of calendars, these Relative CALID's will not be
very user friendly. As such, a CAP CUA will have to retrieve a user's
Relative CALID from somewhere, probably a ACAP server or perhaps, a LDAP
server. Since I've never heard of a commercial implementation of ACAP,
I'm guessing it'll be LDAP.



From owner-ietf-calendar@imc.org  Mon Oct  4 18:29:09 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09648
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 18:29:09 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id PAA17592
	for ietf-calendar-bks; Mon, 4 Oct 1999 15:10:11 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA17588
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 15:10:10 -0700 (PDT)
Received: from Software.com ([207.175.94.130]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991004221055.GDK484239.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 17:10:55 -0500
Message-ID: <37F925E7.2B9BCE25@Software.com>
Date: Mon, 04 Oct 1999 15:10:47 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OF321431A9.FE208609-ON85256800.0044422C@Lotus.com> <37F91A56.B667743B@netscape.com>
Content-Type: multipart/mixed;
 boundary="------------65AE38056F30D222992DA80D"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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



Richard Shusterman wrote:
> 
> Nope and I think we've beat this topic to death for now. Doug, please
> close this work item.

Thanks - I have marked it 'N'
--------------65AE38056F30D222992DA80D
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------65AE38056F30D222992DA80D--



From owner-ietf-calendar@imc.org  Mon Oct  4 18:29:43 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09659
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 18:29:43 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id PAA17561
	for ietf-calendar-bks; Mon, 4 Oct 1999 15:05:59 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA17557
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 15:05:57 -0700 (PDT)
Received: from Software.com ([207.175.94.130]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991004220643.GCN484239.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 17:06:43 -0500
Message-ID: <37F924EA.64CC697@Software.com>
Date: Mon, 04 Oct 1999 15:06:34 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-21 Get/Set user properties.
References: <OF321431A9.FE208609-ON85256800.0044422C@Lotus.com> <37F91A56.B667743B@netscape.com>
Content-Type: multipart/mixed;
 boundary="------------7460EB2082742AB1752B5C9B"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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



Richard Shusterman wrote:

> >From the CAP draft:
> 
> "... There is no implied structure in a Relative CALID. It is an
> arbitrary string of 7 bit ASCII characters. It may refer to the calendar
> of a user or of a  resource such as a conference room. It MUST be unique
> within the calendar store. It is recommended that the Relative CALID be
> globally unique."
> 
> In a large population of calendars, these Relative CALID's will not be
> very user friendly. As such, a CAP CUA will have to retrieve a user's
> Relative CALID from somewhere, probably a ACAP server or perhaps, a LDAP
> server. Since I've never heard of a commercial implementation of ACAP,
> I'm guessing it'll be LDAP.

Maybe this is an issue for the locate draft?

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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------7460EB2082742AB1752B5C9B--



From owner-ietf-calendar@imc.org  Mon Oct  4 18:59:40 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09846
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 18:59:40 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id PAA17914
	for ietf-calendar-bks; Mon, 4 Oct 1999 15:38:20 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA17904
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 15:38:19 -0700 (PDT)
Received: from Software.com ([207.175.94.130]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991004223904.GHR484239.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 17:39:04 -0500
Message-ID: <37F92C80.BB2D415C@Software.com>
Date: Mon, 04 Oct 1999 15:38:56 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: W-8 CAP Bounded Latency Issues
Content-Type: multipart/mixed;
 boundary="------------D7D8D76B03B09C97A149D161"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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


W-8 CAP Bounded Latency Issues                 U
    <there were issues - I can't remember
    them>

Anyone remember why I was asked to put this on this list?

I'll set it to 'N' if no one objects.

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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------D7D8D76B03B09C97A149D161--



From owner-ietf-calendar@imc.org  Mon Oct  4 19:09:14 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09964
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 19:09:13 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id PAA17957
	for ietf-calendar-bks; Mon, 4 Oct 1999 15:41:55 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA17953
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 15:41:54 -0700 (PDT)
Received: from Software.com ([207.175.94.130]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991004224239.GIE484239.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 17:42:39 -0500
Message-ID: <37F92D57.74CDF07D@Software.com>
Date: Mon, 04 Oct 1999 15:42:31 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: W-23 overlapped booking
Content-Type: multipart/mixed;
 boundary="------------4E38A3D01989605F448012C6"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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


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

I think this is a 'Y' and there needs to be a proposal.

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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------4E38A3D01989605F448012C6--



From owner-ietf-calendar@imc.org  Mon Oct  4 20:45:17 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10566
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 20:45:17 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id RAA19160
	for ietf-calendar-bks; Mon, 4 Oct 1999 17:20:13 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA19156
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 17:20:11 -0700 (PDT)
Received: from Software.com ([207.175.94.130]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991005002103.LDZ487796.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 19:21:03 -0500
Message-ID: <37F94465.F09BE9E2@Software.com>
Date: Mon, 04 Oct 1999 17:20:53 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: W-24 CAP Calendar CHARSET property issues
Content-Type: multipart/mixed;
 boundary="------------AFAE91D14E2EEC57A1B7C90E"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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


W-24 CAP Calendar CHARSET property issues      U

There was a small debate. Unless there is objection, I will
be be changing this to 'Y' to add charset at the calendar level.
The default is UTF-8.

And it is already in the CAP draft. So there must have
been someone that had an issue? If we do not here from
you it will be changed to a 'Y'

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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------AFAE91D14E2EEC57A1B7C90E--



From owner-ietf-calendar@imc.org  Mon Oct  4 20:45:41 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10577
	for <calsch-archive@odin.ietf.org>; Mon, 4 Oct 1999 20:45:40 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id RAA19226
	for ietf-calendar-bks; Mon, 4 Oct 1999 17:23:59 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA19222
	for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 17:23:58 -0700 (PDT)
Received: from Software.com ([207.175.94.130]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991005002444.LER487796.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 4 Oct 1999 19:24:44 -0500
Message-ID: <37F94543.DE6BAD83@Software.com>
Date: Mon, 04 Oct 1999 17:24:35 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: W-27 RRULE expanson flag.
Content-Type: multipart/mixed;
 boundary="------------FB44242831B07D2CBBF5EA96"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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


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

I think the consensus is that this is needed, so unless
there are objections, I'll change this to a 'Y' on
Oct 12th.

Now the issues is - how?

Frank says query with RECURRENCE-ID equal to NULL (or empty).
Are there any other proposals?

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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------FB44242831B07D2CBBF5EA96--



From owner-ietf-calendar@imc.org  Tue Oct  5 08:43:57 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28862
	for <calsch-archive@odin.ietf.org>; Tue, 5 Oct 1999 08:43:56 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id FAA29419
	for ietf-calendar-bks; Tue, 5 Oct 1999 05:04:02 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA29409
	for <ietf-calendar@imc.org>; Tue, 5 Oct 1999 05:04:00 -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 GAA26039;
	Tue, 5 Oct 1999 06:52:13 -0400 (EDT)
Message-Id: <199910051052.GAA26039@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-00.txt
Date: Tue, 05 Oct 1999 06:52:12 -0400
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
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
	Filename	: draft-ietf-calsch-imp-guide-00.txt
	Pages		: 9
	Date		: 04-Oct-99
	
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 Protoco' (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.

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

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

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


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

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

--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:	<19991004095957.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--




From owner-ietf-calendar@imc.org  Tue Oct  5 11:00:48 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04397
	for <calsch-archive@odin.ietf.org>; Tue, 5 Oct 1999 11:00:47 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id HAA07179
	for ietf-calendar-bks; Tue, 5 Oct 1999 07:13:26 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA07175
	for <ietf-calendar@imc.org>; Tue, 5 Oct 1999 07:13:25 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA19317
	for <ietf-calendar@imc.org>; Tue, 5 Oct 1999 10:26:32 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA22449
	for <ietf-calendar@imc.org>; Tue, 5 Oct 1999 10:12:22 -0400 (EDT)
To: ietf-calendar@imc.org
Subject: Re: W-27 RRULE expanson flag.
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF28169889.7BE4498B-ON85256801.004F2612@Lotus.com>
Date: Tue, 5 Oct 1999 10:25:11 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/05/99 10:25:29 AM,
	Serialize complete at 10/05/99 10:25:29 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 004EC06685256801_="
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

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

Unless we have a proposal, it should still be "N". Changing issues to "Y" 
without a concrete proposal doesn't server reaching closure.
-- Frank

--=_alternative 004EC06685256801_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Unless we have a proposal, it should still be &quot;N&quot;. Changing issues to &quot;Y&quot; without a concrete proposal doesn't server reaching closure.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 004EC06685256801_=--


From owner-ietf-calendar@imc.org  Sun Oct 10 12:38:16 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04111
	for <calsch-archive@odin.ietf.org>; Sun, 10 Oct 1999 12:38:15 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id AAA19144
	for ietf-calendar-bks; Sun, 10 Oct 1999 00:41:46 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA19138
	for <ietf-calendar@imc.org>; Sun, 10 Oct 1999 00:41:44 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA05687
	for ietf-calendar@imc.org; Sun, 10 Oct 1999 00:00:03 -0700 (PDT)
Date: Sun, 10 Oct 1999 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <199910100700.AAA05687@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@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		U
     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

 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			U
     <there were issues - I can't remember
     them>

 W-9 CAP MOVE method. Issues with VCARs.	U
     [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				U
 
 W-14 CAP VEVENT Schema				U
 
 W-15 CAP VTODO Schema				U
 
 W-16 CAP VJOURNAL Schema			U
 
 W-17 CAP VCAR Schema				U

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

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

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			U

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

 W-24 CAP Calendar CHARSET property issues	U

 W-25 Remove MUST from UID in 4.8.4.7		U

 W-26 Write/Submit information draft/rfc	Y

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

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

 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

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

 The following are a list of action items for the iCalendar-2 draft editors:
 
 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.

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


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@imc.org  Thu Oct 14 12:36:57 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06476
	for <calsch-archive@odin.ietf.org>; Thu, 14 Oct 1999 12:36:56 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id IAA21592
	for ietf-calendar-bks; Thu, 14 Oct 1999 08:55:22 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA21588
	for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 08:55:20 -0700 (PDT)
Received: from Software.com ([207.175.94.201]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991014155649.SZO959.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 10:56:49 -0500
Message-ID: <3805FD35.A360F7D5@Software.com>
Date: Thu, 14 Oct 1999 08:56:37 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Comments: Draft-many-ical-ski
Content-Type: multipart/mixed;
 boundary="------------7CF633460884BBAB4652ADC1"
Sender: owner-ietf-calendar@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.
--------------7CF633460884BBAB4652ADC1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I have read the draft and I just don't see any need for most
of what is in the draft. Here are my comments;

First, I do not think this was a well written document. After reading
it I do not understand what many of the sections mean. Some
seem so ambiguous or lacking in detail that would seem to me that
there needs to be a definition of term section at the start of the
document.

(2.1) DIPROLE:

	Why not add to PARTSTAT? Why a new parameter?

	[9] Is some non-standard file format - unreadable so I don't know
	what a 'DIP' is.

(2.2) DITROLE:

	Again [9] is unreadable, so what is a 'DIT'?

	It looks to me as if this is some kind of comment about
	why you would want to attend the event?

(3.1) X-SKI-TITLE:

	Why is this different than SUMMARY?

(3.1.2) X-SKI-PERSONS

	Why can't they be ATTENDEEs? It looks the same to me.

(3.1.8) X-SKI-URL

	Why not use URL as defined in rfc-2445?

(3.1.9) EUID

	Why not UID?

(3.2.1) Opening times.
(3.2.2)	Scheduled times.

	I recall the conversations with Greg and on the mailing list.
	I can not reconcile those conversations with the text in this
	draft.

(3.2.3) Geo related natural times.

	What (who?) is a "geographic location. altitude, and
	compass course cross-referencing authority registries..." ?

	What is "Natural time/date"?

	With regard to:

			Sunrise, Sunset, High tide, low tide,
			full moon, solar eclipses etc...

	Do you mean that you want to be able to describe these
	events given a geo location? As in a query to a server
	provides these and you want to be able to represent them
	in a iCal way?

(3.2.4) Relative times.

	This is one I think is so important I wonder how we missed it
	in iCalendar.

(3.3) WHICH

	After reading this draft. I have no idea what this is about.

(3.4) Venue

	Near the top the draft says: "This property defined the
	physical room in which an event takes place". Yet lower
	down the venue types are Internet, Radio, TV, Outdoors,
	indoors, Travel-Transit. What happened to room?

	I do not think that you mean 'room'. As room to me
	implies the which room inside of a building.

(3.4.3) Media Address.

	I do not follow what this has to do with iCal or SKiCal.

	Address of what? As in what TV channel? What radio
	frequency to listen to?

(3.5.1) X-SKI-ADMISSION

	I think I understand what this section says. However
	the format of the examples is not 'iCal'ish.

	As in many of the examples do not have a ':' for the value.
	They have only ';'s. Typo?

(3.5.2) X-SKI-PARTICIPATION

	Same typo's as in 3.5.1 ?

(3.5.4) Ticketing
(3.5.5) Reservations

	Why not one property with a parameter that indicated
	if tickets are available? Or just reservations needed?


(3.5.6) Smoking

	Why another one? Looks like you could have used (Example):

		X-SKI-PARTICIPATION;SMOKING=PROHIBITED

(3.5.7) X-SKI-PARKING

	What about parking fees?

(3.7.1) Responsible

	Why not CONTACT or ORGANIZER ?

(3.7.2) Other agents

	typo - 'WhoDoUsue' ?

(3.8.1) Checksum

	This should be a transport issue not an iCal issue. If someone
	intends to alter the data, they can also alter the checksum.

(4.*) List examples for qualparam

	I do not see examples. Just a list. After reading this draft I
	have no idea how to generate a 'qualparam'.


General comments:

	Now that I have read the draft I understand you needs much
	better. However I personally do not feel that this draft
	will produce code that is interoperable without further 
	work and definitions inside of the draft.

	The ideas are great. I just think the document needs work.

	Why a not a list managed by IANA? (re: [8])

	Many of the examples do not conform to the iCal syntax
	making it a no-starter. 

	Why 'X-' values. Why not propose this as a standard
	IANA extensions for iCalendar?
--------------7CF633460884BBAB4652ADC1
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------7CF633460884BBAB4652ADC1--



From owner-ietf-calendar@imc.org  Thu Oct 14 14:53:00 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11055
	for <calsch-archive@odin.ietf.org>; Thu, 14 Oct 1999 14:52:59 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id LAA24853
	for ietf-calendar-bks; Thu, 14 Oct 1999 11:17:25 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA24849
	for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 11:17:24 -0700 (PDT)
Received: from Software.com ([207.175.94.201]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991014181853.TZH959.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 13:18:53 -0500
Message-ID: <38061E80.F600FAC1@Software.com>
Date: Thu, 14 Oct 1999 11:18:40 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: CAP editor action items
Content-Type: multipart/mixed;
 boundary="------------543E66047D9937F8E8062AA5"
Sender: owner-ietf-calendar@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.
--------------543E66047D9937F8E8062AA5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


We have work todo. Should we schedule a phone call to discuss
who is going to write what?

-Doug
(Below is an updated todo list with new CAP editor action items
 that already existed - just not on the todo list).

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

	There was email talking about his - anyone remember?
	When I switched jobs I lost my old inbox. I do not
	have that email any more.

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

	Alex - Paul is this going to make it in time for DC?

 C-3 Text for 2.7 [Finding CAP Servers]         Doug    N

	I'll do some write up on this and send it to the WG
	next week.

 C-4 VCAR examples                              Doug?   N
 
	I'll do some write up on this and send text to the WG
	next week.

 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

	Any volunteers to enter iTIP like restriction tables for CAP?

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

	Steve - you did the original one - correct? Do you
	want to update it?

 C-15 Document the 'CALMASTER' calendar property

	Steve - I think that Richard proposed this. If I am
	right then maybe you can get text from him?

And I have added some:

  
C-16 (2.11)  Query Schema

       I'll send this out next week. More text needed.

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.


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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------543E66047D9937F8E8062AA5--



From owner-ietf-calendar@imc.org  Thu Oct 14 16:35:30 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13076
	for <calsch-archive@odin.ietf.org>; Thu, 14 Oct 1999 16:35:29 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id NAA26589
	for ietf-calendar-bks; Thu, 14 Oct 1999 13:03:17 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA26585
	for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 13:03:16 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id MAA27408
	for ietf-calendar@imc.org; Thu, 14 Oct 1999 12:21:57 -0700 (PDT)
Date: Thu, 14 Oct 1999 12:21:57 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <199910141921.MAA27408@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@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		U
     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

 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.	U
     [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				U
 
 W-14 CAP VEVENT Schema				U
 
 W-15 CAP VTODO Schema				U
 
 W-16 CAP VJOURNAL Schema			U
 
 W-17 CAP VCAR Schema				U

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

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

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			U

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

 W-24 CAP Calendar CHARSET property issues	U

 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				U
      (CAP-00 - 12.2)
      Will there need to be one?		U
      Optional?					U


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

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

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


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@imc.org  Thu Oct 14 17:23:34 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13949
	for <calsch-archive@odin.ietf.org>; Thu, 14 Oct 1999 17:23:31 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id NAA27371
	for ietf-calendar-bks; Thu, 14 Oct 1999 13:47:37 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA27366
	for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 13:47:34 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: Re: CAP editor action items
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF96888DC0.6F8E9039-ON8525680A.00725AB5@com>
Date: Thu, 14 Oct 1999 16:49:31 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 10/14/99 04:49:37 PM
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_mixed 007265B58525680A_="
Sender: owner-ietf-calendar@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>

--=_mixed 007265B58525680A_=
Content-Type: multipart/alternative; boundary="=_alternative 007265B68525680A_="


--=_alternative 007265B68525680A_=
Content-Type: text/plain; charset="us-ascii"

Fine with me.  We need to get it in by Oct 22nd to be able to talk about 
it in Washington.




Doug Royer <Doug.Royer@software.com>
Sent by: owner-ietf-calendar@imc.org
10/14/99 02:18 PM
Please respond to ietf-calendar

 
        To:     ietf-calendar@imc.org
        cc: 
        Subject:        CAP editor action items


We have work todo. Should we schedule a phone call to discuss
who is going to write what?

-Doug
(Below is an updated todo list with new CAP editor action items
 that already existed - just not on the todo list).

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

                 There was email talking about his - anyone remember?
                 When I switched jobs I lost my old inbox. I do not
                 have that email any more.

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

                 Alex - Paul is this going to make it in time for DC?

 C-3 Text for 2.7 [Finding CAP Servers]         Doug    N

                 I'll do some write up on this and send it to the WG
                 next week.

 C-4 VCAR examples                              Doug?   N
 
                 I'll do some write up on this and send text to the WG
                 next week.

 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

                 Any volunteers to enter iTIP like restriction tables for 
CAP?

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

                 Steve - you did the original one - correct? Do you
                 want to update it?

 C-15 Document the 'CALMASTER' calendar property

                 Steve - I think that Richard proposed this. If I am
                 right then maybe you can get text from him?

And I have added some:

 
C-16 (2.11)  Query Schema

       I'll send this out next week. More text needed.

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.


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


--=_alternative 007265B68525680A_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Fine with me. &nbsp;We need to get it in by Oct 22nd to be able to talk about it in Washington.</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@imc.org</font>
<p><font size=1 face="sans-serif">10/14/99 02:18 PM</font>
<br><font size=1 face="sans-serif">Please respond to ietf-calendar</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;ietf-calendar@imc.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;CAP editor action items</font></table>
<br>
<br><font size=2><tt><br>
We have work todo. Should we schedule a phone call to discuss<br>
who is going to write what?<br>
<br>
-Doug<br>
(Below is an updated todo list with new CAP editor action items<br>
 that already existed - just not on the todo list).<br>
<br>
==<br>
 The following are a list of action items for the CAP draft editors:<br>
 <br>
 Draft Action Item &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Who &nbsp; &nbsp; Done (Y/N)<br>
 ----------------- &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;--- &nbsp; &nbsp; ----------<br>
 &nbsp; &nbsp; &nbsp; &nbsp;<br>
 C-1 Remove unused definitions &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;N<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; There was email talking about his - anyone remember?<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; When I switched jobs I lost my old inbox. I do not<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; have that email any more.<br>
<br>
 C-2 Fix up changes in authentication &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Alex &nbsp; &nbsp;N<br>
 &nbsp; &nbsp; text as commented on the list &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Paul<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Alex - Paul is this going to make it in time for DC?<br>
<br>
 C-3 Text for 2.7 [Finding CAP Servers] &nbsp; &nbsp; &nbsp; &nbsp; Doug &nbsp; &nbsp;N<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I'll do some write up on this and send it to the WG<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; next week.<br>
<br>
 C-4 VCAR examples &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Doug? &nbsp; N<br>
 <br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I'll do some write up on this and send text to the WG<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; next week.<br>
<br>
 C-5 PUBLISH text<br>
 C-6 REQUEST text<br>
 C-7 REPLY text<br>
 C-8 ADD text<br>
 C-9 CANCEL text <br>
 C-10 REFRESH text<br>
 C-11 COUNTER text<br>
 C-12 DECLINECOUNTER Text<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Any volunteers to enter iTIP like restriction tables for CAP?<br>
<br>
 C-14 Redo state diagram to include STARTTLS<br>
 &nbsp; &nbsp; &nbsp;and IDENTIFY command.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Steve - you did the original one - correct? Do you<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; want to update it?<br>
<br>
 C-15 Document the 'CALMASTER' calendar property<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Steve - I think that Richard proposed this. If I am<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; right then maybe you can get text from him?<br>
<br>
And I have added some:<br>
<br>
 &nbsp;<br>
C-16 (2.11) &nbsp;Query Schema<br>
<br>
 &nbsp; &nbsp; &nbsp; I'll send this out next week. More text needed.<br>
<br>
C-17 (7.2.1.5) MOVE Method<br>
<br>
 &nbsp; &nbsp; &nbsp; More text needed - Who?<br>
<br>
C-18 (12.1) Calendar Store Properties<br>
<br>
 &nbsp; &nbsp; &nbsp; Editors note. (Per W-27)<br>
<br>
C-19 (12.2) SCHEDULABLE-HOURS<br>
<br>
 &nbsp; &nbsp; &nbsp; Format? Text needs to be written.<br>
<br>
C-20 (13.) Security Considerations<br>
<br>
 &nbsp; &nbsp; &nbsp; See editors note - more text.<br>
<br>
<br>
-----------------------------------------------------</tt></font>
<br>
<br>
--=_alternative 007265B68525680A_=--
--=_mixed 007265B58525680A_=
Content-Type: application/octet-stream; name="ATT82U49"
Content-Disposition: attachment; filename="ATT82U49"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

YmVnaW46dmNhcmQgDQpuOlJveWVyO0RvdWcNCnRlbDtwYWdlcjpwYWdlckByb3llci5jb20gb3Ig
NjUwLTI3NC04OTYwDQp0ZWw7Y2VsbDo2NTAtMjc0LTg5NjANCnRlbDtmYXg6ODA1LTk1Ny0xNTQ0
DQp0ZWw7d29yazo4MDUtOTU3LTE3OTAgeDU0MQ0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpo
dHRwOi8vUm95ZXIuY29tL1Blb3BsZS9Eb3VnDQpvcmc6U29mdHdhcmUuY29tDQp2ZXJzaW9uOjIu
MQ0KZW1haWw7aW50ZXJuZXQ6RG91Zy5Sb3llckBTb2Z0d2FyZS5jb20NCnRpdGxlOkFyY2hpdGVj
dA0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs1MzAgRS4gTW9udGVjaXRvIFN0Lj0wRD0wQTtTYW50
YSBCYXJiYXJhO0NBOzkzMTAzO1UuUy5BDQpmbjpEb3VnIFJveWVyDQplbmQ6dmNhcmQNCg==
--=_mixed 007265B58525680A_=--


From owner-ietf-calendar@imc.org  Thu Oct 14 21:53:15 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17359
	for <calsch-archive@odin.ietf.org>; Thu, 14 Oct 1999 21:53:13 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id SAA03339
	for ietf-calendar-bks; Thu, 14 Oct 1999 18:22:55 -0700 (PDT)
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA03332
	for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 18:22:53 -0700 (PDT)
Received: from [212.151.179.195] (d212-151-179-195.swipnet.se [212.151.179.195]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA03640 for <ietf-calendar@imc.org>; 
          Fri, 15 Oct 1999 03:24:57 +0200 (MET DST)
Message-Id: <199910150124.DAA03640@mb05.swip.net>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Fri, 15 Oct 1999 03:40:59 +0100
Subject: Subject: Comments: Draft-many-ical-ski -SKiCal position
From: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
To: ietf-calendar@imc.org
Mime-version: 1.0
X-Priority: 3
Content-type: multipart/alternative; boundary="MS_Mac_OE_3022803660_111266_MIME_Part"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

> THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--MS_Mac_OE_3022803660_111266_MIME_Part
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


Subject: Comments: Draft-many-ical-ski -SKiCal position

First of all I would like to thank Doug for taking the time to actually wade
through the first SKiCal draft and write down his reactions.  It is just
this kind of criticism which we are hoping for, the alternative being
silence (read -who cares).  I would like to answer the points on which we
differ.
Since there are so many issues raised, I and other members of our WG, will
bite them off on individual mails, and hope that this itemization makes it
easier to concentrate on the specific details of quite independent issues.
In this first message I would just like to reiterate once again the SKiCal
Point of view.
We came into the CALSCH environment quite late in the game, a lot of water
had already passed under the bridge, and even though we researched the
archives, we invariably tried to open some doors which were considered by
the group as definitely closed, e.g. embedding vCards in iCal objects.
Our SKiCal goal, was and is, considerably wider in scope than iCal's, and
sometimes one might question if iCal was the right place for SKiCal to be at
all.  But for this, the CALSCH WG just might share the blame, CALSCH members
can also not help from seeing iCal in a greater perspective than just the
ol' office meeting. Look at the examples of football (or is it basketball?)
games, and anniversaries in the RFCs, and see how both Doug and Frank rose
to the challenge of describing the operating hours of "Sam's bakery" with
2445 syntax.
We realize that the CALSCH WG is way behind "schedule" and it is out of
respect for that predicament that we have left you in peace, for the most
part anyway:-). Every time we have entered the fracas, it has just seemed to
slow things down.  We too, would like to see CAP put to bed.
But on the other hand, Doug wrote (in a very isolated spark of positivism in
his chow-down on the SKiCal draft) the following about one SKiCal property.
(3.2.4) Relative times.
 This is one I think is so important I wonder how we missed it
 in iCalendar.
Thanks for this acknowledgement Doug, but I believe that there is a lot more
in the SKiCal draft, though admittedly not very crisply written, which has
definitely been missed in iCalendar- even when limiting ourselves to humdrum
office meetings. And if we do wish to move on to cover football games and
theatre performances and opening times and so on, well then there are some
very majors discrepancies to clear up first.  To begin with the very essence
of the iCalendar object has a serious logical flaw.  See my next mail       
 Subject: Comments: Draft-many-iCal-ski - DIPS and DOPS


--MS_Mac_OE_3022803660_111266_MIME_Part
Content-type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Subject: Comments: Draft-many-ical-ski -SKiCal position</TITLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
=00<FONT SIZE=3D"2"><BR>
Subject: Comments: Draft-many-ical-ski -SKiCal position<BR>
<BR>
First of all I would like to thank Doug for taking the time to actually wad=
e through the first SKiCal draft and write down his reactions.  It is just t=
his kind of criticism which we are hoping for, the alternative being silence=
 (read -who cares).  I would like to answer the points on which we differ.<B=
R>
Since there are so many issues raised, I and other members of our WG, will =
bite them off on individual mails, and hope that this itemization makes it e=
asier to concentrate on the specific details of quite independent issues.<BR=
>
In this first message I would just like to reiterate once again the SKiCal =
Point of view.<BR>
We came into the CALSCH environment quite late in the game, a lot of water =
had already passed under the bridge, and even though we researched the archi=
ves, we invariably tried to open some doors which were considered by the gro=
up as definitely closed, e.g. embedding vCards in iCal objects.<BR>
Our SKiCal goal, was and is, considerably wider in scope than iCal's, and s=
ometimes one might question if iCal was the right place for SKiCal to be at =
all.  But for this, the CALSCH WG just might share the blame, CALSCH members=
 can also not help from seeing iCal in a greater perspective than just the o=
l' office meeting. Look at the examples of football (or is it basketball?) g=
ames, and anniversaries in the RFCs, and see how both Doug and Frank rose to=
 the challenge of describing the operating hours of &quot;Sam's bakery&quot;=
 with 2445 syntax.<BR>
We realize that the CALSCH WG is way behind &quot;schedule&quot; and it is =
out of respect for that predicament that we have left you in peace, for the =
most part anyway:-). Every time we have entered the fracas, it has just seem=
ed to slow things down.  We too, would like to see CAP put to bed.<BR>
But on the other hand, Doug wrote (in a very isolated spark of positivism i=
n his chow-down on the SKiCal draft) the following about one SKiCal property=
.<BR>
(3.2.4) Relative times.<BR>
 This is one I think is so important I wonder how we missed it<BR>
 in iCalendar.<BR>
Thanks for this acknowledgement Doug, but I believe that there is a lot mor=
e in the SKiCal draft, though admittedly not very crisply written, which has=
 definitely been missed in iCalendar- even when limiting ourselves to humdru=
m office meetings. And if we do wish to move on to cover football games and =
theatre performances and opening times and so on, well then there are some v=
ery majors discrepancies to clear up first.  To begin with the very essence =
of the iCalendar object has a serious logical flaw.  See my next mail       =
<BR>
 Subject: Comments: Draft-many-iCal-ski - DIPS and DOPS<BR>
<BR>
</FONT>
</BODY>
</HTML>

--MS_Mac_OE_3022803660_111266_MIME_Part--



From owner-ietf-calendar@imc.org  Thu Oct 14 21:59:13 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17399
	for <calsch-archive@odin.ietf.org>; Thu, 14 Oct 1999 21:59:12 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id SAA03363
	for ietf-calendar-bks; Thu, 14 Oct 1999 18:23:03 -0700 (PDT)
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA03356
	for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 18:23:01 -0700 (PDT)
Received: from [212.151.179.195] (d212-151-179-195.swipnet.se [212.151.179.195]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA03682 for <ietf-calendar@imc.org>; 
          Fri, 15 Oct 1999 03:25:04 +0200 (MET DST)
Message-Id: <199910150125.DAA03682@mb05.swip.net>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Fri, 15 Oct 1999 03:42:02 +0100
Subject: Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT
From: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
To: ietf-calendar@imc.org
Mime-version: 1.0
X-Priority: 3
Content-type: multipart/alternative; boundary="MS_Mac_OE_3022803723_115057_MIME_Part"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

> THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--MS_Mac_OE_3022803723_115057_MIME_Part
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable



---------------------
Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT

Doug's comments on the SKiCal draft:
 
>(2.1) DIPROLE:

> Why not add to PARTSTAT? Why a new parameter?
>(2.2) DITROLE:

> Again [9] is unreadable, so what is a 'DIT'?
It looks to me as if this is some kind of comment about
 why you would want to attend the event?
>

Apologies, apologies for dealing out acronyms without defining them.

A DIT is a "by Description Identifiable Thing" and a DIP is a "by
Description Identifiable Person".  A DIPROLE is the role of a person or
person present at an event, e.g. actor, award respondent, MC, Parade
Marshall, ... hostess, salesperson etc.

A DITROLE is the role of a thing at an event and should among other things
convey whether the DIT is actually present at the event, e.g. "'99 model
cars" or referred to in its absence, e.g. the "Holy Grail", "the works of
Picasso".   DITROLE tells us if the DIT is being played on or x-rayed,
blown-up, being sold, on-display, unveiled, launched etc.

Now Doug suggests partstat which is defined as:

(from RFC 2445) partstat - Purpose: To specify the participation status for
the calendar user specified by the property.

In our eyes this doesn't fit the participation status for the "non"-
calendar-user.  As you can see, terms like "NEEDS-ACTION" / "ACCEPTED" /
"DECLINED do not jell with terms like "SINGER" / "DANCER" / "STANDUP
COMEDIAN" / 

Perhaps Doug meant ROLE, but there is still a problem with the definition o=
f
ROLE;

(from RFC 2445) ROLE - Purpose: To specify the participation role for the
calendar user specified by the property.

  We see these parameters as part of the calendar mechanism, which should b=
e
reserved for the purposes of reservations, bookings and confirmations and
not for describing the "cast" or the "orchestra" or "the football team"

Neither do we feel that ATTENDEE should be stretched to cover what we inten=
d
DIP to cover.   
 
Greg




--MS_Mac_OE_3022803723_115057_MIME_Part
Content-type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT</TITLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
<FONT SIZE=3D"2"><BR>
<BR>
---------------------<BR>
Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT<BR>
<BR>
Doug's comments on the SKiCal draft:<BR>
 <BR>
&gt;(2.1) DIPROLE:<BR>
<BR>
&gt;&nbsp;Why not add to PARTSTAT? Why a new parameter?<BR>
&gt;(2.2) DITROLE:<BR>
<BR>
&gt;&nbsp;Again [9] is unreadable, so what is a 'DIT'?<BR>
It looks to me as if this is some kind of comment about<BR>
&nbsp;why you would want to attend the event?<BR>
&gt;<BR>
<BR>
Apologies, apologies for dealing out acronyms without defining them.<BR>
<BR>
A DIT is a &quot;by Description Identifiable Thing&quot; and a DIP is a &qu=
ot;by Description Identifiable Person&quot;.  A DIPROLE is the role of a per=
son or person present at an event, e.g. actor, award respondent, MC, Parade =
Marshall, ... hostess, salesperson etc.<BR>
<BR>
A DITROLE is the role of a thing at an event and should among other things =
convey whether the DIT is actually present at the event, e.g. &quot;'99 mode=
l cars&quot; or referred to in its absence, e.g. the &quot;Holy Grail&quot;,=
 &quot;the works of Picasso&quot;.   DITROLE tells us if the DIT is being pl=
ayed on or x-rayed, blown-up, being sold, on-display, unveiled, launched etc=
.<BR>
<BR>
Now Doug suggests partstat which is defined as:<BR>
<BR>
(from RFC 2445) partstat - Purpose: To specify the participation status for=
 the calendar user specified by the property.<BR>
<BR>
In our eyes this doesn't fit the participation status for the &quot;non&quo=
t;- calendar-user.  As you can see, terms like &quot;NEEDS-ACTION&quot; / &q=
uot;ACCEPTED&quot; / &quot;DECLINED do not jell with terms like &quot;SINGER=
&quot; / &quot;DANCER&quot; / &quot;STANDUP COMEDIAN&quot; / <BR>
<BR>
Perhaps Doug meant ROLE, but there is still a problem with the definition o=
f ROLE;<BR>
<BR>
(from RFC 2445) ROLE - Purpose: To specify the participation role for the c=
alendar user specified by the property.<BR>
<BR>
  We see these parameters as part of the calendar mechanism, which should b=
e reserved for the purposes of reservations, bookings and confirmations and =
not for describing the &quot;cast&quot; or the &quot;orchestra&quot; or &quo=
t;the football team&quot;<BR>
<BR>
Neither do we feel that ATTENDEE should be stretched to cover what we inten=
d DIP to cover.   <BR>
 <BR>
Greg<BR>
<BR>
<BR>
<BR>
</FONT>
</BODY>
</HTML>

--MS_Mac_OE_3022803723_115057_MIME_Part--



From owner-ietf-calendar@imc.org  Thu Oct 14 22:03:55 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17475
	for <calsch-archive@odin.ietf.org>; Thu, 14 Oct 1999 22:03:54 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id SAA03349
	for ietf-calendar-bks; Thu, 14 Oct 1999 18:22:58 -0700 (PDT)
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA03342
	for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 18:22:56 -0700 (PDT)
Received: from [212.151.179.195] (d212-151-179-195.swipnet.se [212.151.179.195]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id DAA03672 for <ietf-calendar@imc.org>; 
          Fri, 15 Oct 1999 03:25:00 +0200 (MET DST)
Message-Id: <199910150125.DAA03672@mb05.swip.net>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Fri, 15 Oct 1999 03:41:52 +0100
Subject: Subject: Comments: Draft-many-iCal-ski =?ISO-8859-1?B?LQ==?=
	 DIPS and DOPS 
From: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
To: ietf-calendar@imc.org
Mime-version: 1.0
X-Priority: 3
Content-type: multipart/alternative; boundary="MS_Mac_OE_3022803713_114458_MIME_Part"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

> THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--MS_Mac_OE_3022803713_114458_MIME_Part
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable



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

Subject: Comments: Draft-many-iCal-ski - DIPS and DOPS 

With the help of these, perhaps silly, acronyms,  DIP and DOP, and DIT and
DOT I will try  illustrate a major inconsistency in RFC 2445. 

A DIT is a "by Description Identifiable Thing" and a DIP is a "by
Description Identifiable Person".

A DOP is the "Description Of a Person" and a DOT is the "Description Of a
Thing.

We will confine ourselves for now to DITS and DOTS.

In our world, a calendar object is a DOT.  It is the Description Of a Thing=
.
 The thing could be a meeting. The meeting is by description identifiable. 
The meeting is a DIT.   

Unfortunately (because it confuses things) a DOT, upon its instantiation, i=
s
automatically a DIT as well, since it in turn can be described by another
DOT and so on like a train of cars.  But like the train, there is only one
last car; the caboose.  The caboose has no car behind it, in other words
there is a DIT which doesn't describe any other DIT.  Just one DIT is not
also simultaneously  a DOT!

Ex;

A hammer is a DIT.  John's book about the hammer is a DOT.  Eddy's book
criticizing Johns book is a DOT.  The on-line Dublin Core document 
appraising  Eddy's book is a DOT.

 And of course these publications are all DITS as well.

Lets look at the Dublin Core document.  It must be uniquely identified. It
has a Distinguishing Name, the date it was published, updated, who wrote it
and so forth.  Actually much of this DOT is actually busy selfdescribing
itself as a DIT.

Some information has to be entered which is actually about Eddy's book. 
Basically the same stuff as above, a uid, and a publishing date, and the
title and the author:Eddie and so on.  At this stage we have illustrated an
initial Dublin Core problem.  In pioneering Dublin Core, it was not
completely clear whether a tag was employed as its own self-DOT or as a DOT
for an external DIT.  

Not to mention how to accommodate John's book - not to mention the actual
hammer itself.  Without a telescopic tag structure, all metadata functional
advantages for the hammer and John's book about the hammer were lost as
these references were relegated to the free-text areas of the Dublin Core
document.                            

When I spoke of this in Oslo where I complained that the RFC 2445 property,
ORGANIZER, was a misnomer, since it referred to the publisher of the
calendar object describing the meeting and not the person actually
responsible for the meeting, the person we capriciously  refer to as the
WhodoUsue, the gathered group replied in unison

"It is the same person!".  

I maintain that the WhodoUsue and the calendar publisher can never be
assumed to be one in the same.  Just as the Dublin Core property, CREATOR,
the author of a book, can never be assumed to be the same person as the
creator of a DC object describing that book.  If I may say so, they are mos=
t
likely two different DIPS.

Apparently CALSCH people see calendar objects as DITS and not DOTS.  The
calendar object is seen as an instance where the vectors of time, space, a
bunch a people and an overhead projector intersect.   Whoever orchestrates
the instance does so by creating a calendar object which plots the
intersection and becomes its master.   I hope I am being fair here.  Correc=
t
me if I am wrong.

But what happens if the event was already  planned before anybody thought t=
o
publish it as a calendar object?  And this event had its organizer
(WhodoUsue).already?  And this WhodoUsue didn't give two hoots for computer
calendars.  And this was a big event so an Internet guide published it as a
calendar object? And it was downloaded by 5000 people?

Who is Who?  Who is the organizer and who is the publisher?



And what about the sporting event example in RFC 2445?  Where is the tag fo=
r
the "real" organizer of the game?  How is this valuable property to be
inherited by the numerous calendar objects created by various publishers to
publicize the game.

Unfortunately this is only the beginning.  RFC 2445 consistently avoids
declaring the DIT or DOT status of properties within the Change Management
and Relationship Component Properties.  Many of the tags which we have
introduced in Draft-many-iCal-ski, are there for the purpose of  making tha=
t
status clear.

    See Subject: Comments: Draft-many-ical-ski - DIPROLE vs PARTSTAT


--MS_Mac_OE_3022803713_114458_MIME_Part
Content-type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Subject: Comments: Draft-many-iCal-ski - DIPS and DOPS </TITLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
<FONT SIZE=3D"2"><BR>
<BR>
---------------<BR>
<BR>
Subject: Comments: Draft-many-iCal-ski - DIPS and DOPS <BR>
<BR>
With the help of these, perhaps silly, acronyms,  DIP and DOP, and DIT and =
DOT I will try  illustrate a major inconsistency in RFC 2445. <BR>
<BR>
A DIT is a &quot;by Description Identifiable Thing&quot; and a DIP is a &qu=
ot;by Description Identifiable Person&quot;.<BR>
<BR>
A DOP is the &quot;Description Of a Person&quot; and a DOT is the &quot;Des=
cription Of a Thing.<BR>
<BR>
We will confine ourselves for now to DITS and DOTS.<BR>
<BR>
In our world, a calendar object is a DOT.  It is the Description Of a Thing=
.  The thing could be a meeting. The meeting is by description identifiable.=
  The meeting is a DIT.   <BR>
<BR>
Unfortunately (because it confuses things) a DOT, upon its instantiation, i=
s automatically a DIT as well, since it in turn can be described by another =
DOT and so on like a train of cars.  But like the train, there is only one l=
ast car; the caboose.  The caboose has no car behind it, in other words ther=
e is a DIT which doesn't describe any other DIT.  Just one DIT is not also s=
imultaneously  a DOT!<BR>
<BR>
Ex;<BR>
<BR>
A hammer is a DIT.  John's book about the hammer is a DOT.  Eddy's book cri=
ticizing Johns book is a DOT.  The on-line Dublin Core document  appraising =
 Eddy's book is a DOT.<BR>
<BR>
 And of course these publications are all DITS as well.<BR>
<BR>
Lets look at the Dublin Core document.  It must be uniquely identified. It =
has a Distinguishing Name, the date it was published, updated, who wrote it =
and so forth.  Actually much of this DOT is actually busy selfdescribing its=
elf as a DIT.<BR>
<BR>
Some information has to be entered which is actually about Eddy's book.  Ba=
sically the same stuff as above, a uid, and a publishing date, and the title=
 and the author:Eddie and so on.  At this stage we have illustrated an initi=
al Dublin Core problem.  In pioneering Dublin Core, it was not completely cl=
ear whether a tag was employed as its own self-DOT or as a DOT for an extern=
al DIT.  <BR>
<BR>
Not to mention how to accommodate John's book - not to mention the actual h=
ammer itself.  Without a telescopic tag structure, all metadata functional a=
dvantages for the hammer and John's book about the hammer were lost as these=
 references were relegated to the free-text areas of the Dublin Core documen=
t.                            <BR>
<BR>
When I spoke of this in Oslo where I complained that the RFC 2445 property,=
 ORGANIZER, was a misnomer, since it referred to the publisher of the calend=
ar object describing the meeting and not the person actually responsible for=
 the meeting, the person we capriciously  refer to as the WhodoUsue, the gat=
hered group replied in unison<BR>
<BR>
&quot;It is the same person!&quot;.  <BR>
<BR>
I maintain that the WhodoUsue and the calendar publisher can never be assum=
ed to be one in the same.  Just as the Dublin Core property, CREATOR, the au=
thor of a book, can never be assumed to be the same person as the creator of=
 a DC object describing that book.  If I may say so, they are most likely tw=
o different DIPS.<BR>
<BR>
Apparently CALSCH people see calendar objects as DITS and not DOTS.  The ca=
lendar object is seen as an instance where the vectors of time, space, a bun=
ch a people and an overhead projector intersect.   Whoever orchestrates the =
instance does so by creating a calendar object which plots the intersection =
and becomes its master.   I hope I am being fair here.  Correct me if I am w=
rong.<BR>
<BR>
But what happens if the event was already  planned before anybody thought t=
o publish it as a calendar object?  And this event had its organizer (WhodoU=
sue).already?  And this WhodoUsue didn't give two hoots for computer calenda=
rs.  And this was a big event so an Internet guide published it as a calenda=
r object? And it was downloaded by 5000 people?<BR>
<BR>
Who is Who?  Who is the organizer and who is the publisher?<BR>
<BR>
<BR>
<BR>
And what about the sporting event example in RFC 2445?  Where is the tag fo=
r the &quot;real&quot; organizer of the game?  How is this valuable property=
 to be inherited by the numerous calendar objects created by various publish=
ers to publicize the game.<BR>
<BR>
Unfortunately this is only the beginning.  RFC 2445 consistently avoids dec=
laring the DIT or DOT status of properties within the Change Management and =
Relationship Component Properties.  Many of the tags which we have introduce=
d in Draft-many-iCal-ski, are there for the purpose of  making that status c=
lear.<BR>
<BR>
    See Subject: Comments: Draft-many-ical-ski - DIPROLE vs PARTSTAT<BR>
<BR>
</FONT>
</BODY>
</HTML>

--MS_Mac_OE_3022803713_114458_MIME_Part--



From owner-ietf-calendar@imc.org  Fri Oct 15 00:13:21 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19635
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 00:13:20 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id UAA11616
	for ietf-calendar-bks; Thu, 14 Oct 1999 20:34:50 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA11609
	for <ietf-calendar@imc.org>; Thu, 14 Oct 1999 20:34:48 -0700 (PDT)
From: pregen@egenconsulting.com
To: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
Cc: ietf-calendar@imc.org
Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF8BDF5BD2.CAA5FA74-ON8525680B.001351C2@com>
Date: Thu, 14 Oct 1999 23:36:49 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 10/14/99 11:36:52 PM,
	Serialize complete at 10/14/99 11:36:52 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0013CD9A8525680B_="
Sender: owner-ietf-calendar@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 0013CD9A8525680B_=
Content-Type: text/plain; charset="us-ascii"

Greg, thank you for your comments.  I must, however, take exception to 
your comments regarding the Calsch group.  As you said, you came into this 
late in the game.  Therefore, I don't think it is appropriate for you to 
criticize the group.   Saying we should share the blame,  or that you 
stayed out of the fray to avoid our "predicament", etc, are all quite 
unnecessary.  Please keep to the topic at hand - determining whether or 
not your work is valid for inclusion on the CAP effort.   As we have 
stated, you are welcome to form a Working Group to proceed on your 
efforts.  The group, myself in particular, made efforts to ensure you had 
a chance to state your case in Olso.  Remember, you always have the option 
of forming your own working group to proceed if you feel you are not 
getting the support you need from the members of this list.
--=_alternative 0013CD9A8525680B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Greg, thank you for your comments. &nbsp;I must, however, take exception to your comments regarding the Calsch group. &nbsp;As you said, you came into this late in the game. &nbsp;Therefore, I don't think it is appropriate for you to criticize the group. &nbsp; Saying we should share the blame, &nbsp;or that you stayed out of the fray to avoid our &quot;predicament&quot;, etc, are all quite unnecessary. &nbsp;Please keep to the topic at hand - determining whether or not your work is valid for inclusion on the CAP effort. &nbsp; As we have stated, you are welcome to form a Working Group to proceed on your efforts. &nbsp;The group, myself in particular, made efforts to ensure you had a chance to state your case in Olso. &nbsp;Remember, you always have the option of forming your own working group to proceed if you feel you are not getting the support you need from the members of this list.</font>
--=_alternative 0013CD9A8525680B_=--


From owner-ietf-calendar@imc.org  Fri Oct 15 04:05:50 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02319
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 04:05:49 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id AAA18106
	for ietf-calendar-bks; Fri, 15 Oct 1999 00:28:40 -0700 (PDT)
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA18099
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 00:28:37 -0700 (PDT)
Received: from [212.151.236.16] (d212-151-236-16.swipnet.se [212.151.236.16]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id JAA02679; 
          Fri, 15 Oct 1999 09:30:38 +0200 (MET DST)
Message-Id: <199910150730.JAA02679@mb05.swip.net>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Fri, 15 Oct 1999 09:48:07 +0100
Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position
From: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
To: pregen@egenconsulting.com,
        greg fitzpatrick <greg.fitzpatrick@mailbox.swipnet.se>
CC: ietf-calendar@imc.org
Mime-version: 1.0
X-Priority: 3
Content-type: multipart/alternative; boundary="MS_Mac_OE_3022825688_25996_MIME_Part"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

> THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--MS_Mac_OE_3022825688_25996_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Pat and other friends.
Oh, I am so sorry - I never meant this as a criticism of the group. 
Elements of RFC 2445 yes - the group, no!  I love the group, they tend to be
a bit rough at meetings with new kids who don't know the ropes, but we have
had so much help from Frank and Doug and others who have come with help and
advice.  And I am sincerely thankful for time we were given in Oslo and your
personal effort towards that. This is a terrible misunderstanding.
"Share the blame" 
With this I mean, that not just the SKiCal people are tempted to expand the
circumference of iCal and that this shows up in the examples I named.  And
yes these examples inspired us.  Sharing the blame = sharing the vision!    
 
"The predicament"
We feel that there are a few conceptual faults and quite a few important
omissions in RFC 2445, but there is also a general impatience to get CAP
wrapped up.  At this stage there is an understandable reluctance to monkey
around with RFC2445, since it would entail changes in several other RFCs and
slowdown CAP. This is definitely a predicament for all.
We are very aware that we are talking about a new standard here.  But it
seems reasonable that the new standard, be it iCal 2 or SKiCal, has
to/should evolve dialectically out of RFC2445. 
Doug was commenting on the SKiCal draft and I was replying to those
comments.  He was helping us.  He pointed out several valid weaknesses which
we must speedily address.  And I am trying to clarify those ideas which we
have such a hard time communicating to Doug and others. 
Greg
Pat wrote:
Greg, thank you for your comments.  I must, however, take exception to your
comments regarding the Calsch group.  As you said, you came into this late
in the game.  Therefore, I don't think it is appropriate for you to
criticize the group.   Saying we should share the blame,  or that you stayed
out of the fray to avoid our "predicament", etc, are all quite unnecessary. 
Please keep to the topic at hand - determining whether or not your work is
valid for inclusion on the CAP effort.   As we have stated, you are welcome
to form a Working Group to proceed on your efforts.  The group, myself in
particular, made efforts to ensure you had a chance to state your case in
Olso.  Remember, you always have the option of forming your own working
group to proceed if you feel you are not getting the support you need from
the members of this list. 

--MS_Mac_OE_3022825688_25996_MIME_Part
Content-type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Subject: Comments: Draft-many-ical-ski -SKiCal position</TITLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
Pat and other friends.<BR>
Oh, I am so sorry - I never meant this as a criticism of the group.  Elemen=
ts of RFC 2445 yes - the group, no!  I love the group, they tend to be a bit=
 rough at meetings with new kids who don't know the ropes, but we have had s=
o much help from Frank and Doug and others who have come with help and advic=
e.  And I am sincerely thankful for time we were given in Oslo and your pers=
onal effort towards that. This is a terrible misunderstanding.<BR>
&quot;Share the blame&quot; <BR>
With this I mean, that not just the SKiCal people are tempted to expand the=
 circumference of iCal and that this shows up in the examples I named.  And =
yes these examples inspired us.  Sharing the blame =3D sharing the vision!    =
  <BR>
&quot;The predicament&quot;<BR>
We feel that there are a few conceptual faults and quite a few important om=
issions in RFC 2445, but there is also a general impatience to get CAP wrapp=
ed up.  At this stage there is an understandable reluctance to monkey around=
 with RFC2445, since it would entail changes in several other RFCs and slowd=
own CAP. This is definitely a predicament for all.<BR>
We are very aware that we are talking about a new standard here.  But it se=
ems reasonable that the new standard, be it iCal 2 or SKiCal, has to/should =
evolve dialectically out of RFC2445. <BR>
Doug was commenting on the SKiCal draft and I was replying to those comment=
s.  He was helping us.  He pointed out several valid weaknesses which we mus=
t speedily address.  And I am trying to clarify those ideas which we have su=
ch a hard time communicating to Doug and others. <BR>
Greg<BR>
Pat wrote:<BR>
<FONT SIZE=3D"2">Greg, thank you for your comments.  I must, however, take ex=
ception to your comments regarding the Calsch group.  As you said, you came =
into this late in the game.  Therefore, I don't think it is appropriate for =
you to criticize the group.   Saying we should share the blame,  or that you=
 stayed out of the fray to avoid our &quot;predicament&quot;, etc, are all q=
uite unnecessary.  Please keep to the topic at hand - determining whether or=
 not your work is valid for inclusion on the CAP effort.   As we have stated=
, you are welcome to form a Working Group to proceed on your efforts.  The g=
roup, myself in particular, made efforts to ensure you had a chance to state=
 your case in Olso.  Remember, you always have the option of forming your ow=
n working group to proceed if you feel you are not getting the support you n=
eed from the members of this list.</FONT> <BR>
</BODY>
</HTML>

--MS_Mac_OE_3022825688_25996_MIME_Part--



From owner-ietf-calendar@imc.org  Fri Oct 15 05:55:08 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03039
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 05:55:07 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id CAA21649
	for ietf-calendar-bks; Fri, 15 Oct 1999 02:13:45 -0700 (PDT)
Received: from dront.nada.kth.se (d92-pla@dront.nada.kth.se [130.237.227.21])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id CAA21644
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 02:13:43 -0700 (PDT)
Received: (from d92-pla@localhost)
	by dront.nada.kth.se (8.8.7/8.8.7) id LAA06077;
	Fri, 15 Oct 1999 11:15:48 +0200 (MET DST)
Date: Fri, 15 Oct 1999 11:15:47 +0200 (MET DST)
From: Pär Lannerö <d92-pla@nada.kth.se>
To: ietf-calendar@imc.org
cc: Niklas Hjelm <niklas@medialab.se>
Subject: TITLE (Re: Comments: Draft-many-ical-ski)
Message-ID: <Pine.SUN.3.91N2x.991015102526.5679A-100000@dront.nada.kth.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-ietf-calendar@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


On Thu, 14 Oct 1999, Doug Royer wrote:
> I have read the draft and I just don't see any need for most
> of what is in the draft. Here are my comments;

The SKiCal team has read and carefully considered your comments,
which are greatly appreciated. We agree about the weaknesses of the
draft document itself, but we are still convinced that there is a
need for all or most of the additions suggested in our draft. That
is, if iCalendar is to move out of the office and be used for publishing
culture events, sports games, movie shows etc.

As a non-native speaker of english though, I (who did most of the 
actual writing) could perhaps use some writing help. Right now we are 
working on version 01 of the draft. Any volunteer co-editor?

Just a few answers to your comments for now.

> (3.1) X-SKI-TITLE:
>  Why is this different than SUMMARY?
SUMMARY should be a describing text. Many events have a title which
is not very descriptive by itself. TITLE provides a place to put this
information. Just to pick an example: Right now there is a photo
exhibition called "Excuse Me While I Kiss the Sky" in New York City.
In a SKi file this could be described as follows:

SUMMARY:Collier Schorr photos on exhibit in NYC
TITLE:Excuse Me While I Kiss the Sky

We believe that the need for TITLE is strong, and perhaps there should be 
a parameter to indicate whether the title is copyrighted or not.

> (2.1) DIPROLE:
>  Why not add to PARTSTAT? Why a new parameter?

Understandable comment considering the formulation in draft 00.
The new SKiCal draft (01) though, due to needs expressed by tourist
organizations, has redefined the value of DIPROLE from one word
picked from an enumeration ("PERFORMER", "CREATOR" and "PRESENT") to
be any (free text) word describing the role. Therefore PARTSTAT
probably will not be appropriate.

>  [9] Is some non-standard file format - unreadable so I don't know
>  what a 'DIP' is.

Sorry, the file is an MS Powerpoint (.PPT) document - we will make it
available as HTML pages.

More answers to Doug Royers comments and suggestions will be posted 
separately.



Pär










From owner-ietf-calendar@imc.org  Fri Oct 15 07:19:39 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04678
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 07:19:39 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id DAA25716
	for ietf-calendar-bks; Fri, 15 Oct 1999 03:53:27 -0700 (PDT)
Received: from ljudo.shortlist.se (ljudo.shortlist.se [193.14.119.253])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id DAA25712
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 03:53:24 -0700 (PDT)
Received: from joyce (unknown [193.14.119.216])
	by ljudo.shortlist.se (Postfix) with SMTP id C10C95F9A
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 12:53:18 +0200 (CEST)
From: "Greg FitzPatrick" <gf@medianet.org>
To: <ietf-calendar@imc.org>
Subject: RE: Comments: Draft-many-ical-ski - natural times
Date: Fri, 15 Oct 1999 12:59:51 +0200
Keywords: SKI
Message-ID: <001e01bf16fc$677d5560$d8770ec1@joyce.musiknet>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <3805FD35.A360F7D5@Software.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-calendar@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



Doug Royer quoted and commented:
>
> (3.2.3) Geo related natural times.
>
> 	What (who?) is a "geographic location. altitude, and
> 	compass course cross-referencing authority registries..." ?

Greg: should have said "authoritative" not "authority"
>
> 	What is "Natural time/date"?
>
> 	With regard to:
>
> 			Sunrise, Sunset, High tide, low tide,
> 			full moon, solar eclipses etc...
>
> 	Do you mean that you want to be able to describe these
> 	events given a geo location? As in a query to a server
> 	provides these and you want to be able to represent them
> 	in a iCal way?

Greg's reply:

Natural time/date may be a poor choice of names.  It does sound a bit New
Ageism.  Perhaps cyclic times would be more appropriate.

Perhaps the big cheeses at Sun and other companies don't plan their meetings
for Sundown, but quite a few tourist attractions do.

Yes, we are looking for a mechanism, whereas an event can be publish as
occurring at e.g. Sundown, without the publisher having to work out exactly
when sundown occurs every day of the year.

The Swedish meteorological office is being asked to publish a machine
readable schema or mechanism which will facilitate this for this country.
It is already done here in a non-machine readable format.

Sundown, as well as the other examples named are dependent upon geographical
positioning.

By defining the terminology for these "natural times" we will allow calendar
users to access this information.

I am pretty sure that many WAP users would appreciate this useful, if
slightly esoteric, function.
And quick references for boat owners as to the tides should surely be
interesting.

But more important is to establish mechanisms which bridge the timing of
natural cyclic events to our man made clocks.

Greg

Ps.  Dont loose any sleep on this one:-) People living as far north as we
do, in a country which is so vertically loooong, think allot about these
kind of things.



From owner-ietf-calendar@imc.org  Fri Oct 15 09:07:03 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09117
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 09:07:02 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id FAA26793
	for ietf-calendar-bks; Fri, 15 Oct 1999 05:31:53 -0700 (PDT)
Received: from ljudo.shortlist.se (ljudo.shortlist.se [193.14.119.253])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA26789
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 05:31:52 -0700 (PDT)
Received: from joyce (unknown [193.14.119.216])
	by ljudo.shortlist.se (Postfix) with SMTP id 00FAA5F9A
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 14:31:55 +0200 (CEST)
From: "Greg FitzPatrick" <gf@medianet.org>
To: <ietf-calendar@imc.org>
Subject: RE: Comments: Draft-many-ical-ski - Media addresses
Date: Fri, 15 Oct 1999 14:38:29 +0200
Keywords: SKI
Message-ID: <000001bf170a$2edcd740$d8770ec1@joyce.musiknet>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <3805FD35.A360F7D5@Software.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-calendar@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

Doug Royer wrote:
>
> (3.4.3) Media Address.
>
> 	I do not follow what this has to do with iCal or SKiCal.
>
> 	Address of what? As in what TV channel? What radio
> 	frequency to listen to?


Both iCal and SKiCal are going to need this property or the synthesis of
this property once it has been thoroughly worked out.

If we were to schedule some sort of video conference today in iCal, we could
probably throw in some URLs in the location field, but we have no mechanisms
to take us further.

When we think about "WHERE" we think about physical rooms (or spaces.)
buildings, parks, auditoriums and so forth.  But as we are aware more and
more activities are happening in environments which are not well described
by street addresses or even Geos.

Media addresses, though geographical, when it comes to Satellite and
antennae ranges and cable installations, also deal with frequencies,
channels, media servers just as you surmised above.

When we were informed by the Swedish National Broadcasting Corporation here
that they were involved in EU attempts at the standardization of these
parameters ( within the area of television and radio), we were relieved,
since we did not have the resources to do this ourselves.

We are eagerly awaiting the results of this work and have prepared ourselves
by leaving room for this in our draft.

As for Internet media addresses, such as the location and type of servers,
we have not either begun to get into this, but we are keeping a eye open to
MPEG 4 and MPEG 7 proceedings.  There are only 24 hours in a day.

Greg



From owner-ietf-calendar@imc.org  Fri Oct 15 10:03:29 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11643
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 10:03:28 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id GAA27614
	for ietf-calendar-bks; Fri, 15 Oct 1999 06:36:24 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA27610
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 06:36:22 -0700 (PDT)
From: pregen@egenconsulting.com
To: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
Cc: ietf-calendar@imc.org
Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OFACE9A50E.C6D759F9-ON8525680B.004AC5E4@com>
Date: Fri, 15 Oct 1999 09:38:24 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 10/15/99 09:38:27 AM,
	Serialize complete at 10/15/99 09:38:27 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 004AE52E8525680B_="
Sender: owner-ietf-calendar@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 004AE52E8525680B_=
Content-Type: text/plain; charset="us-ascii"

OK, now I feel better. I knew we were trying to help and I can understand 
the language issues raised by Par.  We have the same issues trying to 
understand Swedish.  Maybe we can figure out some way to help out.  I wish 
we got more comments from other people besides Frank and Doug.  It's hard 
to judge the response to a draft if no one makes suggestions.
--=_alternative 004AE52E8525680B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">OK, now I feel better. I knew we were trying to help and I can understand the language issues raised by Par. &nbsp;We have the same issues trying to understand Swedish. &nbsp;Maybe we can figure out some way to help out. &nbsp;I wish we got more comments from other people besides Frank and Doug. &nbsp;It's hard to judge the response to a draft if no one makes suggestions.</font>
--=_alternative 004AE52E8525680B_=--


From owner-ietf-calendar@imc.org  Fri Oct 15 12:07:32 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16011
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 12:07:31 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id IAA29525
	for ietf-calendar-bks; Fri, 15 Oct 1999 08:41:42 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA29521
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 08:41:41 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id IAA10499
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 08:43:20 -0700 (PDT)
Received: from netscape.com ([205.217.243.10]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FJNIC700.KDM; Fri, 15 Oct 1999 08:43:19 -0700 
Message-ID: <38074A94.A90C564@netscape.com>
Date: Fri, 15 Oct 1999 08:39:00 -0700
From: sman@netscape.com (Steve Mansour)
Organization: Netscape
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
CC: pregen@egenconsulting.com,
        greg fitzpatrick <greg.fitzpatrick@mailbox.swipnet.se>
Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position
References: <OFACE9A50E.C6D759F9-ON8525680B.004AC5E4@com>
Content-Type: multipart/mixed;
 boundary="------------12FCFD57EC936B82D190226E"
Sender: owner-ietf-calendar@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.
--------------12FCFD57EC936B82D190226E
Content-Type: multipart/alternative;
 boundary="------------8802AFE80E229B627F5A9332"


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

pregen@egenconsulting.com wrote:

> OK, now I feel better. I knew we were trying to help and I can
> understand the language issues raised by Par.  We have the same issues
> trying to understand Swedish.  Maybe we can figure out some way to
> help out.  I wish we got more comments from other people besides Frank
> and Doug.  It's hard to judge the response to a draft if no one makes
> suggestions.

I've been following this thread loosely. I've skimmed the SKiCal draft,
but I have not had the time to give it a thorough review -I will try to
do so before the upcoming IETF meeting.

Here's another perspective on the question of "do we need this stuff in
iCal".  In the last couple of months, I have spoken with a bunch of
event content providers.  Today, they all publish event information in
their own formats (typically some variant of CSV). I have been pushing
them to adopt iCalendar as a standard way to distribute their
information. They are interested at first, I point them to RFC 2445, but
there are _always_ calls a few days later asking how to map fields which
they consider important into the iCalendar schema. It usually turns out
that information is dropped because there's no good way to represent it,
or it gets crammed into a field like DESCRIPTION.  But even that doesn't
always work. Sometimes there are events which will happen "sometime
during the week of October 11 - 15, and it will be 2 hours long, we'll
get back to you when we know the exact date and time". For events like
this, they want to let people know it's coming, and they want to update
it later when they actually know when it is, and after they look at
iCalendar they're not sure how to do it.

The iCalendar schema has worked fine for much of the calendaring and
group scheduling problems with which many of us are familiar. However,
based on the feedback I've been getting from event content providers, it
is not a great fit for their needs --we can shoe-horn the information
into iCalendar but it is a lossy conversion. ICalendar was not designed
with these kind of events in mind. That may have been intentional, or it
may be that event content vendors are just now becoming interested in
standardizing.

I think it would be a good thing for the calendar industry if there were
some standard to accommodate these types of events. At the 50,000 ft
level, it seems like iCalendar is a good place. But I want to do a
detailed review of SKiCal before making a recommendation.

-Steve

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
pregen@egenconsulting.com wrote:
<blockquote TYPE=CITE><font face="sans-serif"><font size=-1>OK, now I feel
better. I knew we were trying to help and I can understand the language
issues raised by Par.&nbsp; We have the same issues trying to understand
Swedish.&nbsp; Maybe we can figure out some way to help out.&nbsp; I wish
we got more comments from other people besides Frank and Doug.&nbsp; It's
hard to judge the response to a draft if no one makes suggestions.</font></font></blockquote>
I've been following this thread loosely. I've skimmed the SKiCal draft,
but I have not had the time to give it a thorough review -I will try to
do so before the upcoming IETF meeting.
<p>Here's another perspective on the question of "do we need this stuff
in iCal".&nbsp; In the last couple of months, I have spoken with a bunch
of event content providers.&nbsp; Today, they all publish event information
in their own formats (typically some variant of CSV). I have been pushing
them to adopt iCalendar as a standard way to distribute their information.
They are interested at first, I point them to RFC 2445, but there are _always_
calls a few days later asking how to map fields which they consider important
into the iCalendar schema. It usually turns out that information is dropped
because there's no good way to represent it, or it gets crammed into a
field like DESCRIPTION.&nbsp; But even that doesn't always work. Sometimes
there are events which will happen "sometime during the week of October
11 - 15, and it will be 2 hours long, we'll get back to you when we know
the exact date and time". For events like this, they want to let people
know it's coming, and they want to update it later when they actually know
when it is, and after they look at iCalendar they're not sure how to do
it.
<p>The iCalendar schema has worked fine for much of the calendaring and
group scheduling problems with which many of us are familiar. However,
based on the feedback I've been getting from event content providers, it
is not a great fit for their needs --we can shoe-horn the information into
iCalendar but it is a lossy conversion. ICalendar was not designed with
these kind of events in mind. That may have been intentional, or it may
be that event content vendors are just now becoming interested in standardizing.
<p>I think it would be a good thing for the calendar industry if there
were some standard to accommodate these types of events. At the 50,000
ft level, it seems like iCalendar is a good place. But I want to do a detailed
review of SKiCal before making a recommendation.
<p>-Steve</html>

--------------8802AFE80E229B627F5A9332--

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

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

--------------12FCFD57EC936B82D190226E--



From owner-ietf-calendar@imc.org  Fri Oct 15 12:15:09 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16230
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 12:15:09 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id IAA29499
	for ietf-calendar-bks; Fri, 15 Oct 1999 08:39:30 -0700 (PDT)
Received: from kyros.telecommotion.com (root@mummyg3.telecommotion.com [194.242.136.100])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA29495
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 08:39:28 -0700 (PDT)
X-NiNLog: [peter@kyros.co.uk] [] [199910151541.QAA17946]
Date: Fri, 15 Oct 1999 16:27:05 +0100
From: Peter Dickson <peter@kyros.co.uk>
To: pregen@egenconsulting.com,
        greg fitzpatrick <greg.fitzpatrick@mailbox.swipnet.se>
cc: ietf-calendar@imc.org
Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position
Message-ID: <3701954582.940004825@[10.10.10.5]>
In-Reply-To: <OFACE9A50E.C6D759F9-ON8525680B.004AC5E4@com>
Originator-Info: login-id=peter; server=net-inter-net
X-Mailer: Mulberry (Win32) [1.4.4, s/n P005-300900-001]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-calendar@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 would like to get involved but have not participated in this sort of
thing before.

I run a software company in the UK and we want to develop a
calendar/scheduling application (as part of a suite) that uses standard
protocols. I discovered this IETF working group through following links on
Cyrusoft's Mulberry (email client) web site.

How can I get up to speed with what's been happening and, more to the
point, how can I help with taking things forward?

Kind regards


Peter Dickson


--On 15 October 1999, 09:38 -0400 pregen@egenconsulting.com wrote:

> 
> OK, now I feel better. I knew we were trying to help and I can understand
> the language issues raised by Par.  We have the same issues trying to
> understand Swedish.  Maybe we can figure out some way to help out.  I
> wish we got more comments from other people besides Frank and Doug.  It's
> hard to judge the response to a draft if no one makes suggestions.





~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<mailto:peter@kyros.co.uk>

Kyros Solutions Ltd           Direct Tel: 0121 683 1329
110 The Custard Factory       Direct Fax: 0870 088 3199
Gibb Street
Birmingham
B9 4AA

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kyros Solutions - passionate about helping people use
information technology effectively  <http://www.kyros.co.uk>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From owner-ietf-calendar@imc.org  Fri Oct 15 13:09:22 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17743
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 13:09:21 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id JAA01018
	for ietf-calendar-bks; Fri, 15 Oct 1999 09:39:47 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA01014
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 09:39:45 -0700 (PDT)
Received: from Software.com ([207.175.94.201]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991015164114.CBWL872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 11:41:14 -0500
Message-ID: <38075913.28EEDC0B@Software.com>
Date: Fri, 15 Oct 1999 09:40:52 -0700
From: Doug Royer <Doug.Royer@software.com>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
CC: ietf-calendar@imc.org
Subject: Re: Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT
References: <199910150125.DAA03682@mb05.swip.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBA67C7FEC46FB3D3EE5F17E8"
Sender: owner-ietf-calendar@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.

--------------msBA67C7FEC46FB3D3EE5F17E8
Content-Type: multipart/mixed;
 boundary="------------5D168145A613C1D46AF57CAB"

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



greg fitzpatrick wrote:

> A DIT is a "by Description Identifiable Thing" and a DIP is a "by Description
> Identifiable Person". A DIPROLE is the role of a person or person present at
> an event, e.g. actor, award respondent, MC, Parade Marshall, ... hostess,
> salesperson etc.
> 
> A DITROLE is the role of a thing at an event and should among other things
> convey whether the DIT is actually present at the event, e.g. "'99 model cars"
> or referred to in its absence, e.g. the "Holy Grail", "the works of Picasso".
> DITROLE tells us if the DIT is being played on or x-rayed, blown-up, being
> sold, on-display, unveiled, launched etc.
> 
> Now Doug suggests partstat which is defined as:
>
> Perhaps Doug meant ROLE, but there is still a problem with the definition of
> ROLE;

Yes I did - thanks.

> (from RFC 2445) ROLE - Purpose: To specify the participation role for the
> calendar user specified by the property.
> 
> We see these parameters as part of the calendar mechanism, which should be
> reserved for the purposes of reservations, bookings and confirmations and not
> for describing the "cast" or the "orchestra" or "the football team"
> 
> Neither do we feel that ATTENDEE should be stretched to cover what we intend
> DIP to cover.

One of the mechanisms in iCalendar and the ATTENDEE is that it is a
list of who is to be notified of changes to the event (Date/Time, place, ...).

Would they be notified of changes? If the answer is NO, then I see
your point. If however it is YES, then they also need to be an ATTENDEE
or they will not be notified of changes.
--------------5D168145A613C1D46AF57CAB
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------5D168145A613C1D46AF57CAB--

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

MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh
PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI
IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi
ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx
NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh
NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2
4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o
/X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB
AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI
T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG
CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH
AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd
08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9
yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8
MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxNTE2NDA1M1owIwYJKoZIhvcNAQkEMRYEFMpM
PQrUV10F3CJftoalBn0/QVJ9MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAseh/5FTFZJKMmyxi9AmdmJRsGQenDlRBSHXAxC43LXDt/YndnLmJoEL1
SFsVJEfanKZST/s2m1HXFueL2AMDG444pibACWtOoyUxjf4I4rIJnTrVavu/bbv4SvgvasIU
WOZSV5qyZtUrSvrDfRKJlPOxU5H5gE8WNZg+sH158As=
--------------msBA67C7FEC46FB3D3EE5F17E8--



From owner-ietf-calendar@imc.org  Fri Oct 15 13:12:34 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17860
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 13:12:34 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id JAA00891
	for ietf-calendar-bks; Fri, 15 Oct 1999 09:31:26 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA00886
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 09:31:24 -0700 (PDT)
Received: from Software.com ([207.175.94.201]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991015163252.CBTN872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 11:32:52 -0500
Message-ID: <3807571D.F7CDAB4B@Software.com>
Date: Fri, 15 Oct 1999 09:32:29 -0700
From: Doug Royer <Doug.Royer@software.com>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
CC: ietf-calendar@imc.org
Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position
References: <3701954582.940004825@[10.10.10.5]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD49F8A9175FF29E5B8218720"
Sender: owner-ietf-calendar@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.

--------------msD49F8A9175FF29E5B8218720
Content-Type: multipart/mixed;
 boundary="------------F9354BAD37D8B5BD2B593755"

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



Peter Dickson wrote:
> 
> I would like to get involved but have not participated in this sort of
> thing before.

The best way is to just jump in :-)

> I run a software company in the UK and we want to develop a
> calendar/scheduling application (as part of a suite) that uses standard
> protocols. I discovered this IETF working group through following links on
> Cyrusoft's Mulberry (email client) web site.
> 
> How can I get up to speed with what's been happening and, more to the
> point, how can I help with taking things forward?

Comment on the drafts and provide feedback. They REALLY ARE DRAFTS, not
standards. So please provide feedback. That includes questions on 
what you think is broken or not well defined.

RFC2445, RFC2446, and RFC1447 are the base for the CAP draft. I among
others think that there will be more extensions to RFC2445-7. And
they will include work like the SKiCal project.

One thing we (all of us) need to do is to capture the spirit of
RFC2445 in our implementations. There has been some criticism
when extensions are proposed. The objections are often 'my server
will break - I don't know that extension'. Well in my opinion
their server is busted. The iCalendar project will evolve past
RFC2445 and they (we) should design our products knowing that
our applications might not know what all of the extensions mean
all of the time. Yet if a VEVENT PUBLISH is done per RFC2446, it should
not matter if other fields are in the object. It should matter
that the VEVENT PUBLISH meets the minimum requirements of RFC2445 and
RFC2446, the extensions were planned. And implementations should plan
on extensions - not say "I do not know what that property or parameter
does".

If you can attend the IETF meetings that helps, but it is not necessary.

As to getting up to speed - there is never any shortcut. Read and dig in :-)

> Kind regards
> 
> Peter Dickson
--------------F9354BAD37D8B5BD2B593755
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------F9354BAD37D8B5BD2B593755--

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

MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh
PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI
IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi
ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx
NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh
NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2
4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o
/X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB
AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI
T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG
CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH
AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd
08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9
yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8
MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxNTE2MzIzMVowIwYJKoZIhvcNAQkEMRYEFLMq
Zu9EcryYO3AyS1C09o3wijGZMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAHPqotOjUaYp42bdhyi+h854BYQu7PQZJJoRqQ2u3jXzgcNX0gFfTjD/c
tt00CTpVxbKBn+JNciqVRHz9ybDW4OolLERISKuTrs+3Sn1En50Pg5If3P97atXJ0W00O01o
fzRfkr1DqfHZhxt6TOGpuO2ruUtrfS7Z1KPEBg6xXzs=
--------------msD49F8A9175FF29E5B8218720--



From owner-ietf-calendar@imc.org  Fri Oct 15 13:56:51 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18861
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 13:56:50 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id KAA02036
	for ietf-calendar-bks; Fri, 15 Oct 1999 10:30:58 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA02032
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 10:30:57 -0700 (PDT)
From: pregen@egenconsulting.com
To: Peter Dickson <peter@kyros.co.uk>
Cc: greg.fitzpatrick@mailbox.swipnet.se, ietf-calendar@imc.org
Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OFA20A643C.AEB4AD58-ON8525680B.005FA903@com>
Date: Fri, 15 Oct 1999 13:33:03 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 10/15/99 01:33:03 PM,
	Serialize complete at 10/15/99 01:33:03 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006061158525680B_="
Sender: owner-ietf-calendar@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 006061158525680B_=
Content-Type: text/plain; charset="us-ascii"

Hi, Peter. We'd love to have the help.  Here's what you can do for a 
start.  Go to the IETF Calendar web site at 
http://www.imc.org/ietf-calendar/.  There are pointers to archives on that 
site.  Also, you may want to review the different RFCs and drafts that are 
available.  The same URL has links to these drafts. 

This is a pointer to a new draft we are working on called Guide To 
Internet Calendaring Implementors (http://www.ietf.org/internet-drafts/draft-ietf-calsch-imp-guide-00.txt)

Once you read the drafts and the archive (unfortnately, that may take a 
while), then you can start replying on the mailing list with your 
comments.  That's how most work should be accomplished.  The other thing 
you may want to do is join us at the IETF meeting in Washington on 
November 8th.  You can get the info about participation at the meeting at 
http://www.ietf.org/meetings/IETF-46.html.  We have a 2 hour session 
planned on Monday of that week.  You can meet the editors of most of the 
drafts as well as other interested parties. 
- - - - - - -
Peter Dickson wrote:
 
I would like to get involved but have not participated in this sort of
thing before.

I run a software company in the UK and we want to develop a
calendar/scheduling application (as part of a suite) that uses standard
protocols. I discovered this IETF working group through following links on
Cyrusoft's Mulberry (email client) web site.

How can I get up to speed with what's been happening and, more to the
point, how can I help with taking things forward?

Kind regards



--=_alternative 006061158525680B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2><tt>Hi, Peter. We'd love to have the help. &nbsp;Here's what you can do for a start. &nbsp;Go to the IETF Calendar web site at http://www.imc.org/ietf-calendar/. &nbsp;There are pointers to archives on that site. &nbsp;Also, you may want to review the different RFCs and drafts that are available. &nbsp;The same URL has links to these drafts. &nbsp;</tt></font>
<br>
<br><font size=2><tt>This is a pointer to a new draft we are working on called Guide To Internet Calendaring Implementors (http://www.ietf.org/internet-drafts/draft-ietf-calsch-imp-guide-00.txt)<br>
</tt></font>
<br><font size=2><tt>Once you read the drafts and the archive (unfortnately, that may take a while), then you can start replying on the mailing list with your comments. &nbsp;That's how most work should be accomplished. &nbsp;The other thing you may want to do is join us at the IETF meeting in Washington on November 8th. &nbsp;You can get the info about participation at the meeting at http://www.ietf.org/meetings/IETF-46.html. &nbsp;We have a 2 hour session planned on Monday of that week. &nbsp;You can meet the editors of most of the drafts as well as other interested parties. &nbsp;<br>
- - - - - - -</tt></font>
<br><font size=2><tt>Peter Dickson wrote:</tt></font>
<br><font size=2><tt>&nbsp;</tt></font>
<br><font size=2><tt>I would like to get involved but have not participated in this sort of<br>
thing before.<br>
<br>
I run a software company in the UK and we want to develop a<br>
calendar/scheduling application (as part of a suite) that uses standard<br>
protocols. I discovered this IETF working group through following links on<br>
Cyrusoft's Mulberry (email client) web site.<br>
<br>
How can I get up to speed with what's been happening and, more to the<br>
point, how can I help with taking things forward?<br>
<br>
Kind regards<br>
<br>
<br>
</tt></font>
--=_alternative 006061158525680B_=--


From owner-ietf-calendar@imc.org  Fri Oct 15 15:55:27 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21152
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 15:55:26 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id MAA03878
	for ietf-calendar-bks; Fri, 15 Oct 1999 12:30:50 -0700 (PDT)
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA03874
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 12:30:48 -0700 (PDT)
Received: from [212.151.160.247] (d212-151-160-247.swipnet.se [212.151.160.247]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA21838 for <ietf-calendar@imc.org>; 
          Fri, 15 Oct 1999 21:32:56 +0200 (MET DST)
Message-Id: <199910151932.VAA21838@mb05.swip.net>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Fri, 15 Oct 1999 21:48:11 +0100
Subject: Re: Subject: Comments: Draft-many-ical-ski -language
From: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
To: ietf-calendar@imc.org
Mime-version: 1.0
X-Priority: 3
Content-type: multipart/alternative; boundary="MS_Mac_OE_3022868891_325234_MIME_Part"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

> THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--MS_Mac_OE_3022868891_325234_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

There is one property which has not been criticized in the SKiCal draft and
that is:
LANGUAGE

If 2445 has any ambition of being an international standard, we must be able
to convey in what language a meeting (note - i am restricting myself to
meetings) will be carried out.

If their are no objections, then please add this property to RFC 2445.

Greg

--MS_Mac_OE_3022868891_325234_MIME_Part
Content-type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Subject: Comments: Draft-many-ical-ski -language</TITLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
There is one property which has not been criticized in the SKiCal draft and=
 that is:<BR>
LANGUAGE<BR>
<BR>
If 2445 has any ambition of being an international standard, we must be abl=
e to convey in what language a meeting (note - i am restricting myself to me=
etings) will be carried out.<BR>
<BR>
If their are no objections, then please add this property to RFC 2445.<BR>
<BR>
Greg
</BODY>
</HTML>

--MS_Mac_OE_3022868891_325234_MIME_Part--



From owner-ietf-calendar@imc.org  Fri Oct 15 15:56:29 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21164
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 15:56:28 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id MAA03871
	for ietf-calendar-bks; Fri, 15 Oct 1999 12:30:44 -0700 (PDT)
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA03867
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 12:30:43 -0700 (PDT)
Received: from [212.151.160.247] (d212-151-160-247.swipnet.se [212.151.160.247]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA21703; 
          Fri, 15 Oct 1999 21:32:49 +0200 (MET DST)
Message-Id: <199910151932.VAA21703@mb05.swip.net>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Fri, 15 Oct 1999 21:39:59 +0100
Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position
From: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
To: pregen@egenconsulting.com
CC: ietf-calendar@imc.org
Mime-version: 1.0
X-Priority: 3
Content-type: multipart/alternative; boundary="MS_Mac_OE_3022868399_295638_MIME_Part"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

> THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--MS_Mac_OE_3022868399_295638_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Thanks Pat
The last thing I want is for anyone to think we are not grateful - we are.  
Our representative in Washington will be Johan Groth.  He is the sharpest
knife in our drawer, a doctor in Theoretical Physics :-) and the head of
ISOC in this country.  I hope you can arrange an informal social
get-together which he can take part in.
Greg
  
OK, now I feel better. I knew we were trying to help and I can understand
the language issues raised by Par.  We have the same issues trying to
understand Swedish.  Maybe we can figure out some way to help out.  I wish
we got more comments from other people besides Frank and Doug.  It's hard to
judge the response to a draft if no one makes suggestions. 

--MS_Mac_OE_3022868399_295638_MIME_Part
Content-type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Subject: Comments: Draft-many-ical-ski -SKiCal position</TITLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
Thanks Pat<BR>
The last thing I want is for anyone to think we are not grateful - we are. =
 <BR>
Our representative in Washington will be Johan Groth.  He is the sharpest k=
nife in our drawer, a doctor in Theoretical Physics :-) and the head of ISOC=
 in this country.  I hope you can arrange an informal social get-together wh=
ich he can take part in.<BR>
Greg<BR>
  <BR>
<FONT SIZE=3D"2">OK, now I feel better. I knew we were trying to help and I c=
an understand the language issues raised by Par.  We have the same issues tr=
ying to understand Swedish.  Maybe we can figure out some way to help out.  =
I wish we got more comments from other people besides Frank and Doug.  It's =
hard to judge the response to a draft if no one makes suggestions.</FONT> <B=
R>
</BODY>
</HTML>

--MS_Mac_OE_3022868399_295638_MIME_Part--



From owner-ietf-calendar@imc.org  Fri Oct 15 15:56:44 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21175
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 15:56:43 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id MAA03888
	for ietf-calendar-bks; Fri, 15 Oct 1999 12:30:53 -0700 (PDT)
Received: from mb05.swip.net (mb05.swip.net [193.12.122.209])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA03882
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 12:30:51 -0700 (PDT)
Received: from [212.151.160.247] (d212-151-160-247.swipnet.se [212.151.160.247]) 
          by mb05.swip.net (8.8.8/8.8.8) with SMTP 
          id VAA21739; 
          Fri, 15 Oct 1999 21:32:52 +0200 (MET DST)
Message-Id: <199910151932.VAA21739@mb05.swip.net>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Fri, 15 Oct 1999 21:38:01 +0100
Subject: Re: Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT
From: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
To: Doug Royer <Doug.Royer@software.com>
CC: ietf-calendar@imc.org
Mime-version: 1.0
X-Priority: 3
Content-type: multipart/alternative; boundary="MS_Mac_OE_3022868281_288546_MIME_Part"
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

> THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--MS_Mac_OE_3022868281_288546_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Doug writes:
One of the mechanisms in iCalendar and the ATTENDEE is that it is a
>list of who is to be notified of changes to the event (Date/Time, place,
...).
>
>Would they be notified of changes? If the answer is NO, then I see
>your point. If however it is YES, then they also need to be an ATTENDEE
>or they will not be notified of changes.

Then we are in agreement.  These people are completely out of the calendar
chain.

And when it comes to ATTENDEE - I think it was Paul Hill, who had the
brilliant idea of using that property for event info subscription.  In a way
where prospective event goers could subscribe to updates.  What a field day
for promoters:-) 


----------
>From: Doug Royer <Doug.Royer@software.com>
>To: ietf-calendar@imc.org
>Cc: ietf-calendar@imc.org
>Subject: Re: Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT
>Date: fre 15 okt 1999 17.40
>

>
>
>greg fitzpatrick wrote:
>
>> A DIT is a "by Description Identifiable Thing" and a DIP is a "by
Description
>> Identifiable Person". A DIPROLE is the role of a person or person present
at
>> an event, e.g. actor, award respondent, MC, Parade Marshall, ... hostess,
>> salesperson etc.
>> 
>> A DITROLE is the role of a thing at an event and should among other
things
>> convey whether the DIT is actually present at the event, e.g. "'99 model
cars"
>> or referred to in its absence, e.g. the "Holy Grail", "the works of
Picasso".
>> DITROLE tells us if the DIT is being played on or x-rayed, blown-up,
being
>> sold, on-display, unveiled, launched etc.
>> 
>> Now Doug suggests partstat which is defined as:
>>
>> Perhaps Doug meant ROLE, but there is still a problem with the definition
of
>> ROLE;
>
>Yes I did - thanks.
>
>> (from RFC 2445) ROLE - Purpose: To specify the participation role for the
>> calendar user specified by the property.
>> 
>> We see these parameters as part of the calendar mechanism, which should
be
>> reserved for the purposes of reservations, bookings and confirmations and
not
>> for describing the "cast" or the "orchestra" or "the football team"
>> 
>> Neither do we feel that ATTENDEE should be stretched to cover what we
intend
>> DIP to cover.
>
>One of the mechanisms in iCalendar and the ATTENDEE is that it is a
>list of who is to be notified of changes to the event (Date/Time, place,
...).
>
>Would they be notified of changes? If the answer is NO, then I see
>your point. If however it is YES, then they also need to be an ATTENDEE
>or they will not be notified of changes.



--MS_Mac_OE_3022868281_288546_MIME_Part
Content-type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT</TITL=
E>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
Doug writes:<BR>
One of the mechanisms in iCalendar and the ATTENDEE is that it is a<BR>
&gt;list of who is to be notified of changes to the event (Date/Time, place=
, ...).<BR>
&gt;<BR>
&gt;Would they be notified of changes? If the answer is NO, then I see<BR>
&gt;your point. If however it is YES, then they also need to be an ATTENDEE=
<BR>
&gt;or they will not be notified of changes.<BR>
<BR>
Then we are in agreement.  These people are completely out of the calendar =
chain.<BR>
<BR>
And when it comes to ATTENDEE - I think it was Paul Hill, who had the brill=
iant idea of using that property for event info subscription.  In a way wher=
e prospective event goers could subscribe to updates.  What a field day for =
promoters:-) <BR>
<BR>
<BR>
----------<BR>
&gt;From: Doug Royer &lt;Doug.Royer@software.com&gt;<BR>
&gt;To: ietf-calendar@imc.org<BR>
&gt;Cc: ietf-calendar@imc.org<BR>
&gt;Subject: Re: Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT=
<BR>
&gt;Date: fre 15 okt 1999 17.40<BR>
&gt;<BR>
<BR>
&gt;<BR>
&gt;<BR>
&gt;greg fitzpatrick wrote:<BR>
&gt;<BR>
&gt;&gt; A DIT is a &quot;by Description Identifiable Thing&quot; and a DIP=
 is a &quot;by Description<BR>
&gt;&gt; Identifiable Person&quot;. A DIPROLE is the role of a person or pe=
rson present at<BR>
&gt;&gt; an event, e.g. actor, award respondent, MC, Parade Marshall, ... h=
ostess,<BR>
&gt;&gt; salesperson etc.<BR>
&gt;&gt; <BR>
&gt;&gt; A DITROLE is the role of a thing at an event and should among othe=
r things<BR>
&gt;&gt; convey whether the DIT is actually present at the event, e.g. &quo=
t;'99 model cars&quot;<BR>
&gt;&gt; or referred to in its absence, e.g. the &quot;Holy Grail&quot;, &q=
uot;the works of Picasso&quot;.<BR>
&gt;&gt; DITROLE tells us if the DIT is being played on or x-rayed, blown-u=
p, being<BR>
&gt;&gt; sold, on-display, unveiled, launched etc.<BR>
&gt;&gt; <BR>
&gt;&gt; Now Doug suggests partstat which is defined as:<BR>
&gt;&gt;<BR>
&gt;&gt; Perhaps Doug meant ROLE, but there is still a problem with the def=
inition of<BR>
&gt;&gt; ROLE;<BR>
&gt;<BR>
&gt;Yes I did - thanks.<BR>
&gt;<BR>
&gt;&gt; (from RFC 2445) ROLE - Purpose: To specify the participation role =
for the<BR>
&gt;&gt; calendar user specified by the property.<BR>
&gt;&gt; <BR>
&gt;&gt; We see these parameters as part of the calendar mechanism, which s=
hould be<BR>
&gt;&gt; reserved for the purposes of reservations, bookings and confirmati=
ons and not<BR>
&gt;&gt; for describing the &quot;cast&quot; or the &quot;orchestra&quot; o=
r &quot;the football team&quot;<BR>
&gt;&gt; <BR>
&gt;&gt; Neither do we feel that ATTENDEE should be stretched to cover what=
 we intend<BR>
&gt;&gt; DIP to cover.<BR>
&gt;<BR>
&gt;One of the mechanisms in iCalendar and the ATTENDEE is that it is a<BR>
&gt;list of who is to be notified of changes to the event (Date/Time, place=
, ...).<BR>
&gt;<BR>
&gt;Would they be notified of changes? If the answer is NO, then I see<BR>
&gt;your point. If however it is YES, then they also need to be an ATTENDEE=
<BR>
&gt;or they will not be notified of changes.<BR>
<BR>
<BR>
</BODY>
</HTML>

--MS_Mac_OE_3022868281_288546_MIME_Part--



From owner-ietf-calendar@imc.org  Fri Oct 15 16:52:59 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21818
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 16:52:58 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id NAA04652
	for ietf-calendar-bks; Fri, 15 Oct 1999 13:25:07 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA04648
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 13:25:06 -0700 (PDT)
Received: from Software.com ([207.175.94.201]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991015202636.CEZM872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 15:26:36 -0500
Message-ID: <38078DF4.AE553FA9@Software.com>
Date: Fri, 15 Oct 1999 13:26:28 -0700
From: Doug Royer <Doug.Royer@software.com>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: ietf-calendar@imc.org
Subject: Re: Subject: Comments: Draft-many-ical-ski -language
References: <199910151932.VAA21838@mb05.swip.net>
Content-Type: multipart/mixed;
 boundary="------------B50B5402846E69DBC76B653B"
Sender: owner-ietf-calendar@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.
--------------B50B5402846E69DBC76B653B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


RFC2445 is a MIME type - And I think that LANG exists in the MIME header.
No need to add it to the object. Also, it is a parameter for TEXT value
types so individual properties have override the MIME lang.

I thought that your proposal also defined a way to show
the presentation language of the event. X-SKI-EVENT-LANGUAGE - Correct?

-Doug


greg fitzpatrick wrote:
> 
> There is one property which has not been criticized in the SKiCal draft and
> that is:
> LANGUAGE
> 
> If 2445 has any ambition of being an international standard, we must be able
> to convey in what language a meeting (note - i am restricting myself to
> meetings) will be carried out.
> 
> If their are no objections, then please add this property to RFC 2445.
> 
> Greg
--------------B50B5402846E69DBC76B653B
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------B50B5402846E69DBC76B653B--



From owner-ietf-calendar@imc.org  Fri Oct 15 18:12:11 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22557
	for <calsch-archive@odin.ietf.org>; Fri, 15 Oct 1999 18:12:11 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id OAA05402
	for ietf-calendar-bks; Fri, 15 Oct 1999 14:34:33 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA05398
	for <ietf-calendar@imc.org>; Fri, 15 Oct 1999 14:34:32 -0700 (PDT)
From: pregen@egenconsulting.com
To: "greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
Cc: ietf-calendar@imc.org
Subject: Re: Subject: Comments: Draft-many-ical-ski -SKiCal position
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF3D81D305.1F720266-ON8525680B.0074CB66@com>
Date: Fri, 15 Oct 1999 17:16:38 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 10/15/99 05:36:39 PM,
	Serialize complete at 10/15/99 05:36:39 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0074DC4E8525680B_="
Sender: owner-ietf-calendar@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 0074DC4E8525680B_=
Content-Type: text/plain; charset="us-ascii"

I got a note previously from Johan.  I'll make sure he gets invited to 
plenty of dinners so by the time he leaves he will know our group!




"greg fitzpatrick" <greg.fitzpatrick@mailbox.swipnet.se>
10/15/99 04:39 PM

 
        To:     pregen@egenconsulting.com
        cc:     ietf-calendar@imc.org
        Subject:        Re: Subject: Comments: Draft-many-ical-ski -SKiCal position

Thanks Pat
The last thing I want is for anyone to think we are not grateful - we are. 

Our representative in Washington will be Johan Groth. He is the sharpest 
knife in our drawer, a doctor in Theoretical Physics :-) and the head of 
ISOC in this country. I hope you can arrange an informal social 
get-together which he can take part in.
Greg

OK, now I feel better. I knew we were trying to help and I can understand 
the language issues raised by Par. We have the same issues trying to 
understand Swedish. Maybe we can figure out some way to help out. I wish 
we got more comments from other people besides Frank and Doug. It's hard 
to judge the response to a draft if no one makes suggestions. 


--=_alternative 0074DC4E8525680B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">I got a note previously from Johan. &nbsp;I'll make sure he gets invited to plenty of dinners so by the time he leaves he will know our group!</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;greg fitzpatrick&quot; &lt;greg.fitzpatrick@mailbox.swipnet.se&gt;</b></font>
<p><font size=1 face="sans-serif">10/15/99 04:39 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;ietf-calendar@imc.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Subject: Comments: Draft-many-ical-ski -SKiCal position</font></table>
<br>
<br><font size=3 face="Times New Roman">Thanks Pat<br>
The last thing I want is for anyone to think we are not grateful - we are. <br>
Our representative in Washington will be Johan Groth. He is the sharpest knife in our drawer, a doctor in Theoretical Physics :-) and the head of ISOC in this country. I hope you can arrange an informal social get-together which he can take part in.<br>
Greg<br>
</font><font size=2 face="Times New Roman"><br>
OK, now I feel better. I knew we were trying to help and I can understand the language issues raised by Par. We have the same issues trying to understand Swedish. Maybe we can figure out some way to help out. I wish we got more comments from other people besides Frank and Doug. It's hard to judge the response to a draft if no one makes suggestions.</font><font size=3 face="Times New Roman"> </font>
<br>
<br>
--=_alternative 0074DC4E8525680B_=--


From owner-ietf-calendar@imc.org  Sun Oct 17 04:20:44 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05787
	for <calsch-archive@odin.ietf.org>; Sun, 17 Oct 1999 04:20:43 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id AAA19961
	for ietf-calendar-bks; Sun, 17 Oct 1999 00:41:02 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA19957
	for <ietf-calendar@imc.org>; Sun, 17 Oct 1999 00:41:00 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA12325
	for ietf-calendar@imc.org; Sun, 17 Oct 1999 00:00:03 -0700 (PDT)
Date: Sun, 17 Oct 1999 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <199910170700.AAA12325@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@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		U
     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

 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.	U
     [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				U
 
 W-14 CAP VEVENT Schema				U
 
 W-15 CAP VTODO Schema				U
 
 W-16 CAP VJOURNAL Schema			U
 
 W-17 CAP VCAR Schema				U

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

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

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			U

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

 W-24 CAP Calendar CHARSET property issues	U

 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				U
      (CAP-00 - 12.2)
      Will there need to be one?		U
      Optional?					U


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

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

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


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@imc.org  Mon Oct 18 18:35:48 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20576
	for <calsch-archive@odin.ietf.org>; Mon, 18 Oct 1999 18:35:47 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id OAA05112
	for ietf-calendar-bks; Mon, 18 Oct 1999 14:58:16 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA05108
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 14:58:15 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991018220010.CWKN872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 17:00:10 -0500
Message-ID: <380B9861.B2ADD07B@Software.com>
Date: Mon, 18 Oct 1999 15:00:01 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: My CAP proposal for 2.7
Content-Type: multipart/mixed;
 boundary="------------4A81B5998567B43B10BECEE5"
Sender: owner-ietf-calendar@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.
--------------4A81B5998567B43B10BECEE5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Here is my proposal for section 2.7.2 (DNS after DC).


2.7.1 DNS
<TBD>

2.7.2 SLP
[EDITORS NOTE: This section still needs some work, but you
will get the idea]

This section assumes that the reader is familiar with RFC2608
and RFC2609. The Service Location Protocol (SLP) as defined in [RFC2608]:
 
   "The Service Location Protocol provides a scalable framework for the
   discovery and selection of network services.  Using this protocol,
   computers using the Internet need little or no static configuration
   of network services for network based applications.  This is
   especially important as computers become more portable, and users
   less tolerant or able to fulfill the demands of network system
   administration."

Each service defines itself so that client applications may locate
the service using predefined parameters that apply to that specific
service. Below are the definitions for the CAP "Service Template"
as defined in [RFC2609].

	Name of submitter: "Doug Royer" <Doug.Royer@Software.com>
	Language of service template: en
	Security Considerations: <TBD>

	Template Text:
	------------------------template begins here--------------------
	template-type=Calendar-Access-Protocol

	# The version will be updated to 1.0 as CAP becomes an RFC.
	template-version=0.0

	template-description=
	The Calendar-Access-Protocol service provides the location
	of iCalendar services.

	# Services can be located or defined with one or more
	# of the following parameters:
	#
	#		<port> Port number CAP service is listening to.
	#
	#		<calendar> Find calendar by calendar name.
	#
	#		<user> User name associated with the service.
	#		Aids in locating a calendar or calendars
	#		associated with a user name <string>.
	#	
	#		<scheme> CAP is the only SCHEME supported
	#
	#		<email> Find calendars associated with an
	#		email address.
	#
	#		<upn> Find calendars associated with a UPN.
	#		
	template-url-syntax=
		url-options	=	url-port / url-calendar /
					url-user / url-scheme /
					url-email / url-upn

		# The port number(s) the CAP server listens on.
		url-port	=	"ports=" ports-list
		ports-list	=	port / port "," ports-list
		port		=	1*DIGIT
	
		# The CalID for the calendar.
		url-calendar	=	"CalID=" calid-list
		calid-list	=	CalID / CalID "," CalID

		# A user associated with a calendar user.
		url-user	=	"user=" user-list
		user-list	=	user / user "," user-list
		user		=	# A CU as defined by
					# the CS implementation,

		# Which URL-scheme's are supported by the CS:
		url-scheme	=	"scheme=" scheme-list
		scheme-list	=	scheme / scheme "," scheme-list
		scheme		=	CAP # Only CAP supported at
					    # this time.

		# Names of calendars associated with an email address.
		url-email	=	"mailto=" email-list
		email-list	=	email / email "," email-list
		email		=	# An RFC822 email address

		# Names of calendars associated with a UPN.
		url-upn		=	"mailto=" upn-list
		upn-list	=	upn / upn "," upn-list
		upn		=	# An RFC822 upn address
				

	-------------------------template ends here---------------------

Example of SLP advertisement:

	URL = service:Calendar-Access-Protocol://cal.example.com/ports=1234
	Attributes = (location-description=Net iCal server1),
	(CalID=Doug.Royer,Steve.Mansour,Conference-RM1),
	(user="Doug Royer", "Steve Mansour", "Conference Room 1"),
	(scheme=CAP),
	(email="Doug.Royer@Software.com","Doug@Royer.com","droyer@software.com,
	"sman@netscape.com","ConfRoom1@example.com"),
	(upn=droyer@software.com,sman@netscape.com),
	(template-url-syntax=\0D
	url-options = url-port / url-calendar /	url-user \0D
	/ url-scheme /	url-email / url-upn \0D
	url-port = "ports=" ports-list \0D
	ports-list = port / port "," ports-list \0D
	port = 1*DIGIT \0D
	url-calendar = "CalID=" calid-list \0D
	calid-list = CalID / CalID "," CalID \0D
	url-user = "user=" user-list \0D
	user-list = user / user "," user-list \0D
	url-scheme = "scheme=" scheme-list \0D
	scheme-list = scheme / scheme "," scheme-list \0D
	scheme = CAP \0D
	url-email = "mailto=" email-list \0D
	email-list = email / email "," email-list \0D
	url-upn = "mailto=" upn-list \0D
	upn-list = upn / upn "," upn-list\0D)
	

++++++++++++++++++++++++

[RFC2608] Guttman, Perkins, Veizades, Day, "Service Location
protocol, Version 2", RFC2608, June 1999.

[RFC2609] Guttman, Perkins, Kempf, "Service Templates and
Service: Schemes", RFC2609, June 1999.
--------------4A81B5998567B43B10BECEE5
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------4A81B5998567B43B10BECEE5--



From owner-ietf-calendar@imc.org  Mon Oct 18 23:32:38 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25006
	for <calsch-archive@odin.ietf.org>; Mon, 18 Oct 1999 23:32:37 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id TAA12830
	for ietf-calendar-bks; Mon, 18 Oct 1999 19:54:37 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id TAA12826
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 19:54:33 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id TAA05456
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 19:56:26 -0700 (PDT)
Received: from netscape.com ([205.217.243.10]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FJTXI100.NM0 for <ietf-calendar@imc.org>; Mon, 18 Oct 1999
          19:56:25 -0700 
Message-ID: <380BDCBE.7F7A3B2F@netscape.com>
Date: Mon, 18 Oct 1999 19:51:42 -0700
From: sman@netscape.com (Steve Mansour)
Organization: Netscape
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: W-19 - open item - can we defer it?
Content-Type: multipart/mixed;
 boundary="------------1EF024D68648E88F8D6B3BA3"
Sender: owner-ietf-calendar@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.
--------------1EF024D68648E88F8D6B3BA3
Content-Type: multipart/alternative;
 boundary="------------87B83C86C3C1B6F54C7483B2"


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

Folks,

Regarding item W-19,

     CAP Group definitions, dynamic and static and how groups are
     used in VCARs. Policy definitions, in a VCAR format.

I thought we had decided that we're not going to tackle group-related
features like this in the first pass of CAP. This would seem to have
directory service implications as well. Should this item be on the list
at all? Can we defer this to a follow-on version of CAP?

-Steve

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Folks,
<p>Regarding item W-19,
<blockquote>CAP Group definitions, dynamic and static and how groups are
used in VCARs. Policy definitions, in a VCAR format.</blockquote>
I thought we had decided that we're not going to tackle group-related features
like this in the first pass of CAP. This would seem to have directory service
implications as well. Should this item be on the list at all? Can we defer
this to a follow-on version of CAP?
<p>-Steve</html>

--------------87B83C86C3C1B6F54C7483B2--

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

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

--------------1EF024D68648E88F8D6B3BA3--



From owner-ietf-calendar@imc.org  Tue Oct 19 00:16:15 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25318
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 00:16:15 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id UAA13719
	for ietf-calendar-bks; Mon, 18 Oct 1999 20:47:07 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id UAA13715
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 20:47:06 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id UAA09328
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 20:49:03 -0700 (PDT)
Received: from netscape.com ([205.217.243.10]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FJTZXR00.HQW for <ietf-calendar@imc.org>; Mon, 18 Oct 1999
          20:49:03 -0700 
Message-ID: <380BE916.1F1EF4D4@netscape.com>
Date: Mon, 18 Oct 1999 20:44:22 -0700
From: sman@netscape.com (Steve Mansour)
Organization: Netscape
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: CALSCH items C-5 through C-12
Content-Type: multipart/mixed;
 boundary="------------D8FD8BB70AE6D129A65C18DC"
Sender: owner-ietf-calendar@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.
--------------D8FD8BB70AE6D129A65C18DC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks,

I think that items C-5 through C-12 are not issues. I believe we had
already decided that ITIP messages are stored in a virtual scheduling
queue. There was only the question of how we were going to query for
queued scheduled items. I _think_ by the end of our last IETF meeting we
had reached the conclusion that this would be done by looking for
components where the METHOD value is not CREATE or MODIFY.  Plus, we
won't need to add more commands to CAP if we ever add new ITIP methods.

Does anyone recall anything different?

-Steve

--------------D8FD8BB70AE6D129A65C18DC
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, Executioner
adr;quoted-printable:;;501 East Middlefield Road=0D=0A;Mountain View;CA;94043;
x-mozilla-cpt:;-12672
fn:Steve Mansour
end:vcard

--------------D8FD8BB70AE6D129A65C18DC--



From owner-ietf-calendar@imc.org  Tue Oct 19 00:42:02 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25553
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 00:42:01 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id VAA13947
	for ietf-calendar-bks; Mon, 18 Oct 1999 21:12:23 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA13943
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 21:12:22 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id VAA19561
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 21:14:18 -0700 (PDT)
Received: from netscape.com ([205.217.243.10]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FJU13U00.GUD for <ietf-calendar@imc.org>; Mon, 18 Oct 1999
          21:14:18 -0700 
Message-ID: <380BEF01.441970AA@netscape.com>
Date: Mon, 18 Oct 1999 21:09:37 -0700
From: sman@netscape.com (Steve Mansour)
Organization: Netscape
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: queries for unbounded recurring components
Content-Type: multipart/mixed;
 boundary="------------ADECC256203DC44C7CEF41CF"
Sender: owner-ietf-calendar@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.
--------------ADECC256203DC44C7CEF41CF
Content-Type: multipart/alternative;
 boundary="------------2393DE378B5879E70A68E71E"


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

Suppose we have a component that recurs like this:

     ...
     UID:12345
     RRULE:FREQ=DAILY
     ...

Now a query is made to the CAP server to return all instances of the
event. That is,

     WHERE (UID EQ 12345)

What should be returned? Should the server attempt to unravel it and
clip it after some number of instances?  Should we return one event with
the RRULE and let the requester unravel it (that's *really* bad)?
Something else?

-Steve

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Suppose we have a component that recurs like this:
<blockquote>...
<br>UID:12345
<br>RRULE:FREQ=DAILY
<br>...</blockquote>
Now a query is made to the CAP server to return all instances of the event.
That is,
<blockquote>WHERE (UID EQ 12345)</blockquote>
What should be returned? Should the server attempt to unravel it and clip
it after some number of instances?&nbsp; Should we return one event with
the RRULE and let the requester unravel it (that's *really* bad)? Something
else?
<p>-Steve</html>

--------------2393DE378B5879E70A68E71E--

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

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

--------------ADECC256203DC44C7CEF41CF--



From owner-ietf-calendar@imc.org  Tue Oct 19 01:24:38 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27904
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 01:24:37 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id VAA14472
	for ietf-calendar-bks; Mon, 18 Oct 1999 21:51:49 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA14465
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 21:51:48 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id VAA22741
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 21:53:44 -0700 (PDT)
Received: from netscape.com ([205.217.243.10]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FJU2XK00.PSQ for <ietf-calendar@imc.org>; Mon, 18 Oct 1999
          21:53:44 -0700 
Message-ID: <380BF844.D5DA2A95@netscape.com>
Date: Mon, 18 Oct 1999 21:49:08 -0700
From: sman@netscape.com (Steve Mansour)
Organization: Netscape
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: SCHEDULABLE-HOURS
Content-Type: multipart/mixed;
 boundary="------------25FBA8DC1B62F0FC915BD204"
Sender: owner-ietf-calendar@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.
--------------25FBA8DC1B62F0FC915BD204
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Does anyone have a suggestion on what the value for the
SCHEDULABLE-HOURS calendar property would be?

Seems like we would need start/end times plus recurrence/exception
rules. It is not a simple property.

-Steve

--------------25FBA8DC1B62F0FC915BD204
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, Executioner
adr;quoted-printable:;;501 East Middlefield Road=0D=0A;Mountain View;CA;94043;
x-mozilla-cpt:;-12672
fn:Steve Mansour
end:vcard

--------------25FBA8DC1B62F0FC915BD204--



From owner-ietf-calendar@imc.org  Tue Oct 19 01:26:07 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28123
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 01:26:06 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id WAA14598
	for ietf-calendar-bks; Mon, 18 Oct 1999 22:01:28 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA14594
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 22:01:27 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id BAA08745;
	Tue, 19 Oct 1999 01:16:31 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id BAA24386;
	Tue, 19 Oct 1999 01:02:08 -0400 (EDT)
To: sman@netscape.com (Steve Mansour)
Cc: ietf-calendar@imc.org
Subject: Re: CALSCH items C-5 through C-12
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF847E5C0F.C6DCB35A-ON8525680F.001CD439@Lotus.com>
Date: Tue, 19 Oct 1999 01:15:36 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/19/99 01:15:41 AM,
	Serialize complete at 10/19/99 01:15:41 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 001C839A8525680F_="
Sender: owner-ietf-calendar@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 001C839A8525680F_=
Content-Type: text/plain; charset="us-ascii"

I agree. Query by METHOD value on the VEVENT, VTODO or VJOURNAL conceptual 
container.
-- Frank

--=_alternative 001C839A8525680F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">I agree. Query by METHOD value on the VEVENT, VTODO or VJOURNAL conceptual container.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 001C839A8525680F_=--


From owner-ietf-calendar@imc.org  Tue Oct 19 01:30:27 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28684
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 01:30:26 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id WAA14622
	for ietf-calendar-bks; Mon, 18 Oct 1999 22:03:34 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA14617
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 22:03:33 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id BAA08812;
	Tue, 19 Oct 1999 01:18:36 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id BAA24473;
	Tue, 19 Oct 1999 01:04:13 -0400 (EDT)
To: sman@netscape.com (Steve Mansour)
Cc: ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OFE9E35840.9FABBC8B-ON8525680F.001CFFCF@Lotus.com>
Date: Tue, 19 Oct 1999 01:17:43 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/19/99 01:17:46 AM,
	Serialize complete at 10/19/99 01:17:46 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 001CB56A8525680F_="
Sender: owner-ietf-calendar@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 001CB56A8525680F_=
Content-Type: text/plain; charset="us-ascii"

You are asking for _all_ the occurrences. However, that is defined by the 
parent VEVENT definition with the RRULE. Just return that primary one.
-- Frank

--=_alternative 001CB56A8525680F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">You are asking for _all_ the occurrences. However, that is defined by the parent VEVENT definition with the RRULE. Just return that primary one.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 001CB56A8525680F_=--


From owner-ietf-calendar@imc.org  Tue Oct 19 01:34:31 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29171
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 01:34:30 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id WAA14664
	for ietf-calendar-bks; Mon, 18 Oct 1999 22:08:48 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA14660
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 22:08:46 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id BAA08933;
	Tue, 19 Oct 1999 01:23:49 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id BAA24714;
	Tue, 19 Oct 1999 01:09:27 -0400 (EDT)
To: sman@netscape.com (Steve Mansour)
Cc: ietf-calendar@imc.org
Subject: Re: SCHEDULABLE-HOURS
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF3B268033.4FA00C47-ON8525680F.001D641D@Lotus.com>
Date: Tue, 19 Oct 1999 01:22:56 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/19/99 01:23:00 AM,
	Serialize complete at 10/19/99 01:23:00 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 001D2FA98525680F_="
Sender: owner-ietf-calendar@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 001D2FA98525680F_=
Content-Type: text/plain; charset="us-ascii"

Steve:
Go back to the ISO ESRA draft specs handed out at the Atlanta working 
group meeting. There was an ASN.1 specification for SCHEDULABLE-HOURS that 
supported both cyclic and non-cyclic schedules. Anything less is not 
satisfactory for the customers that we have in the transport and health 
services industry. This is what we need here. You are right, it is not 
just a simple scalar value!
-- Frank

--=_alternative 001D2FA98525680F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Steve:</font>
<p><font size=3 face="Courier New">Go back to the ISO ESRA draft specs handed out at the Atlanta working group meeting. There was an ASN.1 specification for SCHEDULABLE-HOURS that supported both cyclic and non-cyclic schedules. Anything less is not satisfactory for the customers that we have in the transport and health services industry. This is what we need here. You are right, it is not just a simple scalar value!</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 001D2FA98525680F_=--


From owner-ietf-calendar@imc.org  Tue Oct 19 01:48:27 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00723
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 01:48:26 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id WAA14753
	for ietf-calendar-bks; Mon, 18 Oct 1999 22:17:17 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA14749
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 22:17:16 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id WAA15257
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 22:19:12 -0700 (PDT)
Received: from netscape.com ([205.217.243.10]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FJU44000.VRS; Mon, 18 Oct 1999 22:19:12 -0700 
Message-ID: <380BFE37.65FD83D6@netscape.com>
Date: Mon, 18 Oct 1999 22:14:31 -0700
From: sman@netscape.com (Steve Mansour)
Organization: Netscape
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
References: <OFE9E35840.9FABBC8B-ON8525680F.001CFFCF@Lotus.com>
Content-Type: multipart/mixed;
 boundary="------------799DA09FEAF59EE24DBA06F1"
Sender: owner-ietf-calendar@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.
--------------799DA09FEAF59EE24DBA06F1
Content-Type: multipart/alternative;
 boundary="------------CF7A79F11EB31CEE8E28ACA4"


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

Hmmm... I think it's more involved than that.  Are you suggesting that
all clients/requesters should know how to expand the RRULE?  A
light-weight client app may want all the instances of a recurring event.
Must it expand the RRULEs / EXRULEs ?  Yow!

-Steve

Frank_Dawson@lotus.com wrote:

>
> You are asking for _all_ the occurrences. However, that is defined by
> the parent VEVENT definition with the RRULE. Just return that primary
> one.
>
> -- Frank
>
>

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hmmm... I think it's more involved than that.&nbsp; Are you suggesting
that all clients/requesters should know how to expand the RRULE?&nbsp;
A light-weight client app may want all the instances of a recurring event.
Must it expand the RRULEs / EXRULEs ?&nbsp; Yow!
<p>-Steve
<p>Frank_Dawson@lotus.com wrote:
<blockquote TYPE=CITE>&nbsp;
<br><font face="Courier New"><font size=+0>You are asking for _all_ the
occurrences. However, that is defined by the parent VEVENT definition with
the RRULE. Just return that primary one.</font></font>
<p><font face="Courier New"><font size=+0>-- Frank</font></font>
<br>&nbsp;
<br>&nbsp;</blockquote>
</html>

--------------CF7A79F11EB31CEE8E28ACA4--

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

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

--------------799DA09FEAF59EE24DBA06F1--



From owner-ietf-calendar@imc.org  Tue Oct 19 01:53:11 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00724
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 01:48:26 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id WAA14805
	for ietf-calendar-bks; Mon, 18 Oct 1999 22:22:18 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA14799
	for <ietf-calendar@imc.org>; Mon, 18 Oct 1999 22:22:17 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id BAA09365;
	Tue, 19 Oct 1999 01:37:20 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id BAA25488;
	Tue, 19 Oct 1999 01:22:59 -0400 (EDT)
To: sman@netscape.com (Steve Mansour)
Cc: ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF42E6DC15.20A30DC5-ON8525680F.001EA4C4@Lotus.com>
Date: Tue, 19 Oct 1999 01:36:27 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/19/99 01:36:31 AM,
	Serialize complete at 10/19/99 01:36:31 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 001E6C768525680F_="
Sender: owner-ietf-calendar@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 001E6C768525680F_=
Content-Type: text/plain; charset="us-ascii"

Steve:
No, it is not an unusual expectation at all. Guess who created the 
recurring event definition? A CUA. How did it know what RRULE and EXRULE 
to use? Well, it had the ability to zip up the desired recurrences into a 
rule, then it certainly has the where with all to unzip them.
-- Frank

--=_alternative 001E6C768525680F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Steve:</font>
<p><font size=3 face="Courier New">No, it is not an unusual expectation at all. Guess who created the recurring event definition? A CUA. How did it know what RRULE and EXRULE to use? Well, it had the ability to zip up the desired recurrences into a rule, then it certainly has the where with all to unzip them.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 001E6C768525680F_=--


From owner-ietf-calendar@imc.org  Tue Oct 19 03:59:28 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07349
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 03:59:27 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id AAA16273
	for ietf-calendar-bks; Tue, 19 Oct 1999 00:27:41 -0700 (PDT)
Received: from ljudo.shortlist.se (ljudo.shortlist.se [193.14.119.253])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id AAA16269
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 00:27:38 -0700 (PDT)
Received: from joyce (unknown [193.14.119.216])
	by ljudo.shortlist.se (Postfix) with SMTP
	id 4641B5F9C; Tue, 19 Oct 1999 09:27:58 +0200 (CEST)
From: "Greg FitzPatrick" <gf@medianet.org>
To: "Doug Royer" <Doug.Royer@software.com>
Cc: <ietf-calendar@imc.org>
Subject: RE: Subject: Comments: Draft-many-ical-ski -language
Date: Tue, 19 Oct 1999 09:34:37 +0200
Keywords: SKI
Message-ID: <002801bf1a04$6569ff20$d8770ec1@joyce.musiknet>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <38078DF4.AE553FA9@Software.com>
Sender: owner-ietf-calendar@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

Confusion - yes our proposal defines a way to show the presentation language
for the event.  That is what we are talking about.  Why is  this property
not included in 2445?  For  European companies with many languages being
spoken within the firm, this is a valuable piece of information.

Greg

> -----Original Message-----
> From: owner-ietf-calendar@imc.org [mailto:owner-ietf-calendar@imc.org]On
> Behalf Of Doug Royer
> Sent: den 15 oktober 1999 22:26
> Cc: ietf-calendar@imc.org
> Subject: Re: Subject: Comments: Draft-many-ical-ski -language
>
>
>
> RFC2445 is a MIME type - And I think that LANG exists in the MIME header.
> No need to add it to the object. Also, it is a parameter for TEXT value
> types so individual properties have override the MIME lang.
>
> I thought that your proposal also defined a way to show
> the presentation language of the event. X-SKI-EVENT-LANGUAGE - Correct?
>
> -Doug
>
>
> greg fitzpatrick wrote:
> >
> > There is one property which has not been criticized in the
> SKiCal draft and
> > that is:
> > LANGUAGE
> >
> > If 2445 has any ambition of being an international standard, we
> must be able
> > to convey in what language a meeting (note - i am restricting myself to
> > meetings) will be carried out.
> >
> > If their are no objections, then please add this property to RFC 2445.
> >
> > Greg



From owner-ietf-calendar@imc.org  Tue Oct 19 12:31:22 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25142
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 12:31:22 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id IAA01168
	for ietf-calendar-bks; Tue, 19 Oct 1999 08:49:52 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA01163
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 08:49:47 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id IAA29929
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 08:51:46 -0700 (PDT)
Received: from netscape.com ([207.1.153.96]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FJUXEA00.043; Tue, 19 Oct 1999 08:51:46 -0700 
Message-ID: <380C942E.FE1DA696@netscape.com>
Date: Tue, 19 Oct 1999 08:54:22 -0700
From: sman@netscape.com (Steve Mansour)
Organization: Netscape
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
References: <OF42E6DC15.20A30DC5-ON8525680F.001EA4C4@Lotus.com>
Content-Type: multipart/mixed;
 boundary="------------1CE643FD31402985E0F2DB20"
Sender: owner-ietf-calendar@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.
--------------1CE643FD31402985E0F2DB20
Content-Type: multipart/alternative;
 boundary="------------0B85C03E463359BAFF6D64D6"


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

Frank_Dawson@lotus.com wrote:

> Steve:
>
> No, it is not an unusual expectation at all. Guess who created the
> recurring event definition? A CUA. How did it know what RRULE and
> EXRULE to use? Well, it had the ability to zip up the desired
> recurrences into a rule, then it certainly has the where with all to
> unzip them.

That's not always true... I create an unbounded recurring event with CUA
A and then CUA B asks for all instances of that event. What you're
saying is that all CUAs need to be able to unzip recurring events.

I suppose the other way to look at this is that CUAs that are not
capable of unzipping recurring events had better be careful of what they
ask for.

-Steve



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Frank_Dawson@lotus.com wrote:
<blockquote TYPE=CITE><font face="Courier New"><font size=+0>Steve:</font></font>
<p><font face="Courier New"><font size=+0>No, it is not an unusual expectation
at all. Guess who created the recurring event definition? A CUA. How did
it know what RRULE and EXRULE to use? Well, it had the ability to zip up
the desired recurrences into a rule, then it certainly has the where with
all to unzip them.</font></font></blockquote>
That's not always true... I create an unbounded recurring event with CUA
A and then CUA B asks for all instances of that event. What you're saying
is that all CUAs need to be able to unzip recurring events.
<p>I suppose the other way to look at this is that CUAs that are not capable
of unzipping recurring events had better be careful of what they ask for.
<p>-Steve
<br>&nbsp;
<br>&nbsp;</html>

--------------0B85C03E463359BAFF6D64D6--

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

begin:vcard 
n:Mansour;Steve
tel;pager:1471528@mobilemessage.com
tel;fax:(650) 428-4059
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=0A;Mountain View;CA;94043;
x-mozilla-cpt:;26848
fn:Steve Mansour
end:vcard

--------------1CE643FD31402985E0F2DB20--



From owner-ietf-calendar@imc.org  Tue Oct 19 13:43:17 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27511
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 13:43:16 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id KAA02329
	for ietf-calendar-bks; Tue, 19 Oct 1999 10:10:40 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA02325
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 10:10:37 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991019171236.DEKJ872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 12:12:36 -0500
Message-ID: <380CA674.BB9BFBDD@Software.com>
Date: Tue, 19 Oct 1999 10:12:20 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: CalSched IETF <ietf-calendar@imc.org>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: W-19 - open item - can we defer it?
References: <380BDCBE.7F7A3B2F@netscape.com>
Content-Type: multipart/mixed;
 boundary="------------3C5092282B8B5F6DF9E63FCC"
Sender: owner-ietf-calendar@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.
--------------3C5092282B8B5F6DF9E63FCC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



I agree. We did say that group operations will not be addressed at 
this time.

-Doug

Steve Mansour wrote:
> 
> Folks,
> 
> Regarding item W-19,
> 
>      CAP Group definitions, dynamic and static and how groups are used in
>      VCARs. Policy definitions, in a VCAR format.
> 
> I thought we had decided that we're not going to tackle group-related features
> like this in the first pass of CAP. This would seem to have directory service
> implications as well. Should this item be on the list at all? Can we defer
> this to a follow-on version of CAP?
> 
> -Steve
--------------3C5092282B8B5F6DF9E63FCC
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------3C5092282B8B5F6DF9E63FCC--



From owner-ietf-calendar@imc.org  Tue Oct 19 13:44:59 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27594
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 13:44:58 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id KAA02443
	for ietf-calendar-bks; Tue, 19 Oct 1999 10:16:14 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA02439
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 10:16:13 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991019171812.DENB872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 12:18:12 -0500
Message-ID: <380CA7C5.31A55E5C@Software.com>
Date: Tue, 19 Oct 1999 10:17:57 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: SCHEDULABLE-HOURS
References: <OF3B268033.4FA00C47-ON8525680F.001D641D@Lotus.com>
Content-Type: multipart/mixed;
 boundary="------------5804B1239AEF93E966F7DDE3"
Sender: owner-ietf-calendar@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.
--------------5804B1239AEF93E966F7DDE3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I say we drop this.

There are other ways to solve this for now. I think we are going to
support OVERLAP at the calendar and component level.

So, create a VEVENT that is private, no-OVERLAP and set it to
the times you wish no one to book. Crude, but okay for CAP #1?
Then we can choose to address this later in another draft?

Frank_Dawson@lotus.com wrote:
> 
> Steve:
> 
> Go back to the ISO ESRA draft specs handed out at the Atlanta working group
> meeting. There was an ASN.1 specification for SCHEDULABLE-HOURS that supported
> both cyclic and non-cyclic schedules. Anything less is not satisfactory for
> the customers that we have in the transport and health services industry. This
> is what we need here. You are right, it is not just a simple scalar value!
> 
> -- Frank
--------------5804B1239AEF93E966F7DDE3
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------5804B1239AEF93E966F7DDE3--



From owner-ietf-calendar@imc.org  Tue Oct 19 13:45:08 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27610
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 13:45:07 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id KAA02383
	for ietf-calendar-bks; Tue, 19 Oct 1999 10:13:12 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA02379
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 10:13:10 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991019171510.DELN872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 12:15:10 -0500
Message-ID: <380CA70E.4C960E6B@Software.com>
Date: Tue, 19 Oct 1999 10:14:54 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: CalSched IETF <ietf-calendar@imc.org>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: queries for unbounded recurring components
References: <380BEF01.441970AA@netscape.com>
Content-Type: multipart/mixed;
 boundary="------------32706D448D3F0498D0B4CEC8"
Sender: owner-ietf-calendar@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.
--------------32706D448D3F0498D0B4CEC8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


We need to define if the CS is going to unwind components by
default or not. I would say that we need to be able to specify
ether way. I think there was an agreement that both needed to
be supported so that thin clients / dumb clients could work and
think smarter clients.

-Doug

Steve Mansour wrote:
> 
> Suppose we have a component that recurs like this:
> 
>      ...
>      UID:12345
>      RRULE:FREQ=DAILY
>      ...
> 
> Now a query is made to the CAP server to return all instances of the event.
> That is,
> 
>      WHERE (UID EQ 12345)
> 
> What should be returned? Should the server attempt to unravel it and clip it
> after some number of instances?  Should we return one event with the RRULE and
> let the requester unravel it (that's *really* bad)? Something else?
> 
> -Steve
--------------32706D448D3F0498D0B4CEC8
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------32706D448D3F0498D0B4CEC8--



From owner-ietf-calendar@imc.org  Tue Oct 19 14:44:42 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29340
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 14:44:41 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id LAA03568
	for ietf-calendar-bks; Tue, 19 Oct 1999 11:15:24 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA03564
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 11:15:23 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA27795
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 14:30:30 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id OAA13012
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 14:16:03 -0400 (EDT)
To: ietf-calendar@imc.org
Subject: Re: SCHEDULABLE-HOURS
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF9C914049.02F2C2D0-ON8525680F.0065208C@Lotus.com>
Date: Tue, 19 Oct 1999 14:29:33 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/19/99 02:29:45 PM,
	Serialize complete at 10/19/99 02:29:45 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006531AC8525680F_="
Sender: owner-ietf-calendar@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 006531AC8525680F_=
Content-Type: text/plain; charset="us-ascii"

I could live with deferring this to either a separate or later draft.
-- Frank
--=_alternative 006531AC8525680F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">I could live with deferring this to either a separate or later draft.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 006531AC8525680F_=--


From owner-ietf-calendar@imc.org  Tue Oct 19 14:47:18 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29387
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 14:47:17 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id LAA03549
	for ietf-calendar-bks; Tue, 19 Oct 1999 11:14:19 -0700 (PDT)
Received: from piinbh1.ms.com (piinbh1.ms.com [199.89.64.71])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA03545
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 11:14:17 -0700 (PDT)
Received: (from uucp@localhost)
        by piinbh1.ms.com (8.8.6/fw v1.22) id OAA19001
        for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 14:16:45 -0400 (EDT)
Received: from unknown(144.14.193.5) by piinbh1 via smap (4.1)
	id xma017978; Tue, 19 Oct 99 14:16:29 -0400
Received: from ms.com (vector.morgan.com [144.14.16.149])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.3) with ESMTP id OAA16702
        for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 14:16:29 -0400 (EDT)
Message-ID: <380CB57D.72400311@ms.com>
Date: Tue, 19 Oct 1999 14:16:29 -0400
From: David Madeo <dmadeo@ms.com>
Reply-To: dmadeo@ms.com
Organization: Morgan Stanley Dean Witter & Co.
X-Mailer: Mozilla 4.7C-CCK-MCD  [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Overlapped Bookings
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

Hi,

I haven't seen any discussion of Overlapped bookings in a while, so I
read through all the email, collected all the ideas and wrote some
text.  Hope you find this
useful.  

Thanks, dmadeo


[ PS Bruce mentioned the possibility of removing the component
property and instead expanding the values for TRANSP.  So instead of
just having TRANSP:OPAQUE and TRANSP:TRANS, you could have (and I'm
paraphrasing), TRANSP:TRANS, TRANSP:TRANS-NOCONFLICT, TRANSP:OPAQUE,
and TRANSP:OPAQUE-NOCONFLICT.  If the calendar property is set to
CONFLICTS:FALSE, then the two OPAQUE (and TRANS) entries are treated
identically, but still defined differently.  Since the calendar
property may be changed back, the component properties do not lose
their settings.  This makes as much sense to me as a specific
component entry for CONFLICTS.  Comments welcome]


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


W-23 CAP Calendar property to allow/disallow                 Y
     booking overlapped or conflicting OPAQUE entries?



1.3 definitions

Overlapped Booking

A policy which indicates whether or not OPAQUE events can overlap one
another.  
When the policy is applied to a calendar it indicates whether or
not any OPAQUE events in the calendar can overlap. When applied to an
individual event, it indicates whether or not it can be overlapped by
any
other OPAQUE event.


2.8 extensions to iCalendar (I'm not sure how this is different than
section 12)

CONFLICTS   A component level property which controls whether overlapped
booking is allowed with this particular component.  This component
property can be changed at any time, regardless of the Calendar
property setting.  Only if the Calendar and the component properties
are set to CONFLICTS:TRUE, will opaque components be allowed to be
overlapped.  The default setting is CONFLICTS:TRUE


6.2 Access Control and CONFLICTS discrepancies

Even if access control allows a CUA to store an event, the CONFLICTS
Calendar or component setting may prevent it, returning an error code
"6.3"

7.2.1.1.1
Result: 6.3  Conflicts not allowed

9.1
(in the VCALENDAR, VEVENT, VTODO, and VJOURNAL sections add the
following)

CONFLICTS

12.2

CONFLICTS N Whether overlapped booking is allowed in this
Calendar. Only if both the Calendar and the component have
CONFLICTS:TRUE will the CS allow another overlapping OPAQUE component to
be scheduled.  If the Calendar CONFLICTS property is changed,
previously scheduled conflicting components are left alone.  Only if
one of the conflicting components is rescheduled to a new time, will
the Calendar setting apply.  The default setting is CONFLICTS:TRUE



dmadeo


From owner-ietf-calendar@imc.org  Tue Oct 19 15:41:02 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00721
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 15:41:01 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id MAA04485
	for ietf-calendar-bks; Tue, 19 Oct 1999 12:11:04 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA04481
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 12:11:01 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: CalSched IETF <ietf-calendar@imc.org>
Cc: Doug.Royer@software.com, ietf-calendar@imc.org
Subject: Re: W-19 - open item - can we defer it?
X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999
Message-ID: <OF6C2076F4.F943CAA5-ON8525680F.0068F655@iris.com>
Date: Tue, 19 Oct 1999 15:13:26 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.1b|September 30, 1999) at 10/19/99
 03:14:00 PM,
	Serialize complete at 10/19/99 03:14:00 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006A30678525680F_="
Sender: owner-ietf-calendar@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 006A30678525680F_=
Content-Type: text/plain; charset="us-ascii"

Doug replied:
>I agree. We did say that group operations will not be addressed at 
>this time.

That agreement was not the WG and it was not everyone...

The concept of groups is really two pronged: they can be static or 
dynamic.  Doing static groups (ie: explode them out at the time you use 
them) is not a viable solution for any real system.  Just too many poor 
usability issues to deal with (ie: new members to the group must be 
manually added everywhere the group was exploded by all CUs!  Ugh!!).  The 
use of dynamic groups is the only really likeable choice from a CUs 
perspecitive.  They dont have to make manual changes on all the places the 
original group was used.

However this puts the cart before the horse: Do we want to preclude the 
use of groups entirely is what needs to be answered first.  Being one of 
the guys who is gonna have to build this engine I certainly whince at the 
thought of what this entails for my implementation.  However as a CU I 
most certanly would want to have groups just like I currently have in 
eMail and in iCalendar.

Since iCalendar is "group enabled", why would we want to preclude the use 
of groups in CAP??  This kinda reminds me of the Volkswaggen commercial 
where the guys tie the mattress onto their roof before the light changes 
but manage to tie their doors shut...

Perhaps it would help others to decide either way if someone could post 
the argument for why _not_ to have groups in CAP?  I certainly dont recall the reason why not to 
have them...

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




<br><font size=2 face="sans-serif">Doug replied:</font>
<br><font size=2 face="Courier New">&gt;I agree. We did say that group operations will not be addressed at <br>
&gt;this time.</font>
<br>
<br><font size=2 face="sans-serif">That agreement was not the WG and it was not everyone...</font>
<br>
<br><font size=2 face="sans-serif">The concept of groups is really two pronged: they can be static or dynamic. &nbsp;Doing static groups (ie: explode them out at the time you use them) is not a viable solution for any real system. &nbsp;Just too many poor usability issues to deal with (ie: new members to the group must be manually added everywhere the group was exploded by all CUs! &nbsp;Ugh!!). &nbsp;The use of dynamic groups is the only really likeable choice from a CUs perspecitive. &nbsp;They dont have to make manual changes on all the places the original group was used.</font>
<br>
<br><font size=2 face="sans-serif">However this puts the cart before the horse: Do we want to preclude the use of groups entirely is what needs to be answered first. &nbsp;Being one of the guys who is gonna have to build this engine I certainly whince at the thought of what this entails for my implementation. &nbsp;However as a CU I most certanly would want to have groups just like I currently have in eMail and in iCalendar.</font>
<br>
<br><font size=2 face="sans-serif">Since iCalendar is &quot;group enabled&quot;, why would we want to preclude the use of groups in CAP?? &nbsp;This kinda reminds me of the Volkswaggen commercial where the guys tie the mattress onto their roof before the light changes but manage to tie their doors shut...</font>
<br>
<br><font size=2 face="sans-serif">Perhaps it would help others to decide either way if someone could post the argument for why <u>_not</u>_ to have groups in CAP? &nbsp;I certainly dont recall the reason why not to have them...</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 006A30678525680F_=--


From owner-ietf-calendar@imc.org  Tue Oct 19 15:57:12 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01063
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 15:57:10 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id MAA04643
	for ietf-calendar-bks; Tue, 19 Oct 1999 12:21:15 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA04639
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 12:21:14 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991019192314.DGKX872.mta1biz.bizmailsrvcs.net@Software.com>;
          Tue, 19 Oct 1999 14:23:14 -0500
Message-ID: <380CC510.667A2AEB@Software.com>
Date: Tue, 19 Oct 1999 12:22:56 -0700
From: Doug Royer <Doug.Royer@software.com>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce_Kahn@iris.com
CC: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: W-19 - open item - can we defer it?
References: <OF6C2076F4.F943CAA5-ON8525680F.0068F655@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCC5B6D8BDF890358D18A01C8"
Sender: owner-ietf-calendar@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.

--------------msCC5B6D8BDF890358D18A01C8
Content-Type: multipart/mixed;
 boundary="------------67B579FAC8D7FC74A26153CD"

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


>From draft-ietf-calsch-capreq-03.txt (the latest):

4.3.1   Deferred Requirements for Operations on a Calendar
 
   CAP is not required to specify:
 
     - How to copy a calendar on a CS or between CSs.
 
     - How a group operations on a set of calendars.
 
     - How to undelete a calendar.
 
     - Auto processing on scheduled components in a calendar that need
     action.
 
       For example, if someone tries to create a meeting on a calendar
       for a user who is on vacation, the CS may automatically delegate
       the meeting to another user.
 

Bruce_Kahn@iris.com wrote:
> 
> Doug replied:
> >I agree. We did say that group operations will not be addressed at
> >this time.
> 
> That agreement was not the WG and it was not everyone...
> 
> The concept of groups is really two pronged: they can be static or dynamic.
>  Doing static groups (ie: explode them out at the time you use them) is not a
> viable solution for any real system.  Just too many poor usability issues to
> deal with (ie: new members to the group must be manually added everywhere the
> group was exploded by all CUs!  Ugh!!).  The use of dynamic groups is the only
> really likeable choice from a CUs perspecitive.  They dont have to make manual
> changes on all the places the original group was used.
> 
> However this puts the cart before the horse: Do we want to preclude the use of
> groups entirely is what needs to be answered first.  Being one of the guys who
> is gonna have to build this engine I certainly whince at the thought of what
> this entails for my implementation.  However as a CU I most certanly would
> want to have groups just like I currently have in eMail and in iCalendar.
> 
> Since iCalendar is "group enabled", why would we want to preclude the use of
> groups in CAP??  This kinda reminds me of the Volkswaggen commercial where the
> guys tie the mattress onto their roof before the light changes but manage to
> tie their doors shut...
> 
> Perhaps it would help others to decide either way if someone could post the
> argument for why _not_ to have groups in CAP?  I certainly dont recall the
> reason why not to have them...
> 
> Bruce
> ===========================================================================
> Bruce Kahn                                INet: Bruce_Kahn@iris.com
> Iris Associates                          Phone: 978.392.5335
> Westford, MA, USA 01886                    FAX: and nothing but the FAX...
> Standard disclaimers apply, even where prohibited by law...
--------------67B579FAC8D7FC74A26153CD
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------67B579FAC8D7FC74A26153CD--

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

MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh
PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI
IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi
ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx
NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh
NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2
4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o
/X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB
AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI
T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG
CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH
AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd
08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9
yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8
MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxOTE5MjI1N1owIwYJKoZIhvcNAQkEMRYEFFI/
PfYKxk0xpySiBBsHJXBdzE8VMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGArbCaYPnbNAnlJQ3+6vQq9gA8khi2OsIEl6mx/yhJ4uXH5wYmToVXR1Xp
3CJigqf506r+wvfsyM2mpSKG9Hn0xElL6GPbtKW3UURPzyhMX5PLlSDvsLt8iZTow4GkOI3z
J1JW6QDp1QbKAtJoRvxzddzsc4XIW+c9BOrmERrmQis=
--------------msCC5B6D8BDF890358D18A01C8--



From owner-ietf-calendar@imc.org  Tue Oct 19 16:23:55 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01571
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 16:23:54 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id MAA05257
	for ietf-calendar-bks; Tue, 19 Oct 1999 12:52:32 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA05253
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 12:52:31 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42])
	by netscape.com (8.8.5/8.8.5) with ESMTP id MAA20800
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 12:54:31 -0700 (PDT)
Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com
          (Netscape Messaging Server 4.1) with ESMTP id FJV8MW00.OZJ for
          <ietf-calendar@imc.org>; Tue, 19 Oct 1999 12:54:32 -0700 
Message-ID: <380CCC98.D54F6D6B@netscape.com>
Date: Tue, 19 Oct 1999 12:55:04 -0700
From: rans@netscape.com (Richard Shusterman)
Organization: Netscape Communications Corp.
X-Mailer: Mozilla 4.61 [en]C-NSCP  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: W-19 - open item - can we defer it?
References: <OF6C2076F4.F943CAA5-ON8525680F.0068F655@iris.com> <380CC510.667A2AEB@Software.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

Since I submitted this work item, I think I should pipe in here.

The term "group" here was meant for "groups of users" not group operations on a set
of calendars. There is a difference. And as Steve pointed out, there are "directory
service implications" since there is no common directory implementation of groups.
But as Bruce points out, how useful is CAP without groups or more specifically, how
useful is a VCAR that can't specify a dynamic group of users?

Doug Royer wrote:

> >From draft-ietf-calsch-capreq-03.txt (the latest):
>
> 4.3.1   Deferred Requirements for Operations on a Calendar
>
>    CAP is not required to specify:
>
>      - How to copy a calendar on a CS or between CSs.
>
>      - How a group operations on a set of calendars.
>
>      - How to undelete a calendar.
>
>      - Auto processing on scheduled components in a calendar that need
>      action.
>
>        For example, if someone tries to create a meeting on a calendar
>        for a user who is on vacation, the CS may automatically delegate
>        the meeting to another user.
>
>
> Bruce_Kahn@iris.com wrote:
> >
> > Doug replied:
> > >I agree. We did say that group operations will not be addressed at
> > >this time.
> >
> > That agreement was not the WG and it was not everyone...
> >
> > The concept of groups is really two pronged: they can be static or dynamic.
> >  Doing static groups (ie: explode them out at the time you use them) is not a
> > viable solution for any real system.  Just too many poor usability issues to
> > deal with (ie: new members to the group must be manually added everywhere the
> > group was exploded by all CUs!  Ugh!!).  The use of dynamic groups is the only
> > really likeable choice from a CUs perspecitive.  They dont have to make manual
> > changes on all the places the original group was used.
> >
> > However this puts the cart before the horse: Do we want to preclude the use of
> > groups entirely is what needs to be answered first.  Being one of the guys who
> > is gonna have to build this engine I certainly whince at the thought of what
> > this entails for my implementation.  However as a CU I most certanly would
> > want to have groups just like I currently have in eMail and in iCalendar.
> >
> > Since iCalendar is "group enabled", why would we want to preclude the use of
> > groups in CAP??  This kinda reminds me of the Volkswaggen commercial where the
> > guys tie the mattress onto their roof before the light changes but manage to
> > tie their doors shut...
> >
> > Perhaps it would help others to decide either way if someone could post the
> > argument for why _not_ to have groups in CAP?  I certainly dont recall the
> > reason why not to have them...
>



From owner-ietf-calendar@imc.org  Tue Oct 19 16:46:47 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02029
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 16:46:46 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id NAA05586
	for ietf-calendar-bks; Tue, 19 Oct 1999 13:03:09 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA05582
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 13:03:07 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991019200507.BOLP959.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 15:05:07 -0500
Message-ID: <380CCEDD.655DCB1F@Software.com>
Date: Tue, 19 Oct 1999 13:04:45 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Overlapped Bookings
References: <380CB57D.72400311@ms.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms47B13AB9AC14E04DBF84BD94"
Sender: owner-ietf-calendar@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.

--------------ms47B13AB9AC14E04DBF84BD94
Content-Type: multipart/mixed;
 boundary="------------F040C13581176CC5A0E44547"

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


As I have heard others say over the last few emails/months:

	TRANSP is the way to go.

Questions:

	1) At the calendar level, should TRANS-NOCONFLICT or TRANS-CONFLICT
	   be the only ones allowed?

	2) Should TRANSP: be allowed as a STORE property? As a default?
	   overrideable?

David Madeo wrote:
> 
> Hi,
> 
> I haven't seen any discussion of Overlapped bookings in a while, so I
> read through all the email, collected all the ideas and wrote some
> text.  Hope you find this
> useful.
> 
> Thanks, dmadeo
> 
> [ PS Bruce mentioned the possibility of removing the component
> property and instead expanding the values for TRANSP.  So instead of
> just having TRANSP:OPAQUE and TRANSP:TRANS, you could have (and I'm
> paraphrasing), TRANSP:TRANS, TRANSP:TRANS-NOCONFLICT, TRANSP:OPAQUE,
> and TRANSP:OPAQUE-NOCONFLICT.  If the calendar property is set to
> CONFLICTS:FALSE, then the two OPAQUE (and TRANS) entries are treated
> identically, but still defined differently.  Since the calendar
> property may be changed back, the component properties do not lose
> their settings.  This makes as much sense to me as a specific
> component entry for CONFLICTS.  Comments welcome]
> 
> ----------------------------------------
> 
> W-23 CAP Calendar property to allow/disallow                 Y
>      booking overlapped or conflicting OPAQUE entries?
> 
> 1.3 definitions
> 
> Overlapped Booking
> 
> A policy which indicates whether or not OPAQUE events can overlap one
> another.
> When the policy is applied to a calendar it indicates whether or
> not any OPAQUE events in the calendar can overlap. When applied to an
> individual event, it indicates whether or not it can be overlapped by
> any
> other OPAQUE event.
> 
> 2.8 extensions to iCalendar (I'm not sure how this is different than
> section 12)
> 
> CONFLICTS   A component level property which controls whether overlapped
> booking is allowed with this particular component.  This component
> property can be changed at any time, regardless of the Calendar
> property setting.  Only if the Calendar and the component properties
> are set to CONFLICTS:TRUE, will opaque components be allowed to be
> overlapped.  The default setting is CONFLICTS:TRUE
> 
> 6.2 Access Control and CONFLICTS discrepancies
> 
> Even if access control allows a CUA to store an event, the CONFLICTS
> Calendar or component setting may prevent it, returning an error code
> "6.3"
> 
> 7.2.1.1.1
> Result: 6.3  Conflicts not allowed
> 
> 9.1
> (in the VCALENDAR, VEVENT, VTODO, and VJOURNAL sections add the
> following)
> 
> CONFLICTS
> 
> 12.2
> 
> CONFLICTS N Whether overlapped booking is allowed in this
> Calendar. Only if both the Calendar and the component have
> CONFLICTS:TRUE will the CS allow another overlapping OPAQUE component to
> be scheduled.  If the Calendar CONFLICTS property is changed,
> previously scheduled conflicting components are left alone.  Only if
> one of the conflicting components is rescheduled to a new time, will
> the Calendar setting apply.  The default setting is CONFLICTS:TRUE
> 
> dmadeo
--------------F040C13581176CC5A0E44547
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------F040C13581176CC5A0E44547--

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

MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh
PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI
IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi
ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx
NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh
NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2
4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o
/X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB
AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI
T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG
CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH
AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd
08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9
yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8
MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxOTIwMDQ0NlowIwYJKoZIhvcNAQkEMRYEFD8D
E6EpAzFjEoMp/htcxpECMi23MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAwjONyYAvQMcaZ6MnLUvB+Bm75qq6uKeqbZ641xSqEP5iai+MYOF8xQp1
DJix0Biq4VVc4vxAqZwDu82H1yEcjajOTahuKEg9aZ9SEUSkSs2csdrZfNiRcAy0guX7qcuS
ot9+ZFnKpNPIxZnKJjHyvRmgtEksB66DggOdCix5FMA=
--------------ms47B13AB9AC14E04DBF84BD94--



From owner-ietf-calendar@imc.org  Tue Oct 19 17:18:28 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02555
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 17:18:26 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id NAA06488
	for ietf-calendar-bks; Tue, 19 Oct 1999 13:38:05 -0700 (PDT)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA06484
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 13:38:04 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <19991019204004.BOSV959.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 15:40:04 -0500
Message-ID: <380CD711.B213970C@Software.com>
Date: Tue, 19 Oct 1999 13:39:46 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: CalSched IETF <ietf-calendar@imc.org>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: W-19 - open item - can we defer it?
References: <OF6C2076F4.F943CAA5-ON8525680F.0068F655@iris.com> <380CC510.667A2AEB@Software.com> <380CCC98.D54F6D6B@netscape.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms56873ACFAE054B018B7503BE"
Sender: owner-ietf-calendar@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.

--------------ms56873ACFAE054B018B7503BE
Content-Type: multipart/mixed;
 boundary="------------41FB20D6422EA64133061A3A"

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



Richard Shusterman wrote:
> 
> Since I submitted this work item, I think I should pipe in here.
> 
> The term "group" here was meant for "groups of users" not group operations on a set
> of calendars. There is a difference. And as Steve pointed out, there are "directory
> service implications" since there is no common directory implementation of groups.
> But as Bruce points out, how useful is CAP without groups or more specifically, how
> useful is a VCAR that can't specify a dynamic group of users?

A VCAR can specify a list of users:

BEGIN:VCAR
CARID:Permisssions for group 'A'
GRANT:UPN=<user1>...
GRANT:UPN=<user2>...
END:VCAR
--------------41FB20D6422EA64133061A3A
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------41FB20D6422EA64133061A3A--

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

MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh
PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI
IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi
ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx
NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh
NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2
4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o
/X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB
AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI
T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG
CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH
AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd
08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9
yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8
MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxOTIwMzk0N1owIwYJKoZIhvcNAQkEMRYEFL/l
7Y+88Exek7ie8w5rp4cb1KgxMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAMflCjofpv7wYjDUGUVshMEDBrJV5SKlkRcaiYo1ykGnCqVTpTGfB+pQ5
fiwlcZqf35xCENSoVEyyKPv4gmD7JXcrq8dX8KEeS9v6RMVpww/H8ms9BTzUXXytrNUBPGSc
PQ/5HyRpExR45P/G1w2CYt/GgSWOq0WojvGUxAfhoTg=
--------------ms56873ACFAE054B018B7503BE--



From owner-ietf-calendar@imc.org  Tue Oct 19 17:25:36 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02644
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 17:25:35 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id NAA06971
	for ietf-calendar-bks; Tue, 19 Oct 1999 13:50:53 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA06967
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 13:50:51 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: Doug Royer <Doug.Royer@software.com>
Cc: ietf-calendar@imc.org
Subject: Re: W-19 - open item - can we defer it?
X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999
Message-ID: <OF0FA116E8.9778150E-ON8525680F.00724BA3@iris.com>
Date: Tue, 19 Oct 1999 16:52:49 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.1b|September 30, 1999) at 10/19/99
 04:53:51 PM,
	Serialize complete at 10/19/99 04:53:51 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 007349BE8525680F_="
Sender: owner-ietf-calendar@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 007349BE8525680F_=
Content-Type: text/plain; charset="us-ascii"

Doug provided the citation:

>>From draft-ietf-calsch-capreq-03.txt (the latest):
>
>4.3.1   Deferred Requirements for Operations on a Calendar
> 
>   CAP is not required to specify:
> 
>     - How to copy a calendar on a CS or between CSs.
> 
>     - How a group operations on a set of calendars.
[Snip]

Please reread that last one carefully.  It does _not_ preclude us having groups on ACLs, it discusses "operations on a set of calendars".  The work item was quoted as "CAP Group definitions, dynamic and static and how groups are used in 
VCARs. Policy definitions, in a VCAR format." and not referring to groupings of calendars.

As a user, I would view the lack of 'groups' on VCARs as a functional hole 
in CAP since I my choice of mail clients and servers that handle it just 
fine.  Yes, there are some added intricacies to calendars that do not 
exist in mail but users dont care how hard it is for us to iron out now; 
they just have a set of existing expectations that I dont think can be 
tossed out lightly...  (Im somewhat surprised that David Madeo and other 
end user reps are not tossing their hats into the ring on this yet.  Have 
they all timed out??)

My previous question still stands:  could post the argument for why _not_ to have groups in 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 007349BE8525680F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Doug provided the citation:</font>
<br>
<br><font size=2 face="Courier New">&gt;&gt;From draft-ietf-calsch-capreq-03.txt (the latest):<br>
&gt;<br>
&gt;4.3.1 &nbsp; Deferred Requirements for Operations on a Calendar<br>
&gt; <br>
&gt; &nbsp; CAP is not required to specify:<br>
&gt; <br>
&gt; &nbsp; &nbsp; - How to copy a calendar on a CS or between CSs.<br>
&gt; <br>
&gt; &nbsp; &nbsp; - How a group operations on a set of calendars.</font>
<br><font size=2 face="sans-serif">[Snip]</font>
<br>
<br><font size=2 face="sans-serif">Please reread that last one carefully. &nbsp;It does _<u>not</u>_ preclude us having groups on ACLs, it discusses &quot;</font><font size=2 face="Courier New">operations on a </font><font size=2 color=red face="Courier New">set of calendars</font><font size=2 face="sans-serif">&quot;. &nbsp;The work item was quoted as &quot;</font><font size=3 face="Times New Roman">CAP Group definitions, dynamic and static and how groups are used in VCARs. Policy definitions, in a VCAR format.</font><font size=2 face="sans-serif">&quot; and not referring to groupings of calendars.</font>
<br>
<br><font size=2 face="sans-serif">As a user, I would view the lack of 'groups' on VCARs as a functional hole in CAP since I my choice of mail clients and servers that handle it just fine. &nbsp;Yes, there are some added intricacies to calendars that do not exist in mail but users dont care how hard it is for us to iron out now; they just have a set of existing expectations that I dont think can be tossed out lightly... &nbsp;(Im somewhat surprised that David Madeo and other end user reps are not tossing their hats into the ring on this yet. &nbsp;Have they all timed out??)</font>
<br>
<br><font size=2 face="sans-serif">My previous question still stands: &nbsp;could post the argument for why <u>_not</u>_ to have groups in 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 007349BE8525680F_=--


From owner-ietf-calendar@imc.org  Tue Oct 19 17:58:05 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02980
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 17:58:04 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id OAA08102
	for ietf-calendar-bks; Tue, 19 Oct 1999 14:24:50 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA08093
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 14:24:39 -0700 (PDT)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id OAA17003
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 14:26:19 -0700 (PDT)
Received: from netscape.com ([207.1.153.212]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FJVCVV00.OY5; Tue, 19 Oct 1999 14:26:19 -0700 
Message-ID: <380CE1CE.22E65488@netscape.com>
Date: Tue, 19 Oct 1999 14:25:34 -0700
From: sman@netscape.com (Steve Mansour)
Organization: Netscape
X-Mailer: Mozilla 4.7 [en]C-NSCP  (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce_Kahn@iris.com
CC: Doug Royer <Doug.Royer@software.com>, ietf-calendar@imc.org
Subject: Re: W-19 - open item - can we defer it?
References: <OF0FA116E8.9778150E-ON8525680F.00724BA3@iris.com>
Content-Type: multipart/mixed;
 boundary="------------83DD125B23A9F0A6E7319D98"
Sender: owner-ietf-calendar@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.
--------------83DD125B23A9F0A6E7319D98
Content-Type: multipart/alternative;
 boundary="------------09C765F1BCF381BC55A780A1"


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

Bruce_Kahn@iris.com wrote:

> My previous question still stands:  could post the argument for why
> _not_ to have groups in CAP?

The short answer is that it simplifies things a lot.

Sounds like you have something in mind. Could you explain what you're
thinking:

   * How are the members of the group resolved/expanded?
   * Are you thinking that the CAP server maintains some notion of
     groups of UPNs or that these groups are managed by something else?
   * Is it just left to the server implemenation?

There are many issues with all these things, but it would help to
understand better how you had envisioned this group capability would
function.

-Steve








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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Bruce_Kahn@iris.com wrote:
<blockquote TYPE=CITE><font face="sans-serif"><font size=-1>My previous
question still stands:&nbsp; could post the argument for why <u>_not</u>_
to have groups in CAP?</font></font></blockquote>
The short answer is that it simplifies things a lot.
<p>Sounds like you have something in mind. Could you explain what you're
thinking:
<ul>
<li>
How are the members of the group resolved/expanded?</li>

<li>
Are you thinking that the CAP server maintains some notion of groups of
UPNs or that these groups are managed by something else?</li>

<li>
Is it just left to the server implemenation?</li>
</ul>
There are many issues with all these things, but it would help to understand
better how you had envisioned this group capability would function.
<p>-Steve
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</html>

--------------09C765F1BCF381BC55A780A1--

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

begin:vcard 
adr;dom:;;;Mountain View;CA;94043;
n:Mansour;Steve
x-mozilla-html:FALSE
org:Netscape
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
tel;fax:650-937-2103
tel;work:650-937-2378
x-mozilla-cpt:;0
fn:Steve Mansour
end:vcard

--------------83DD125B23A9F0A6E7319D98--



From owner-ietf-calendar@imc.org  Tue Oct 19 18:07:13 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03154
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 18:07:12 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id OAA08472
	for ietf-calendar-bks; Tue, 19 Oct 1999 14:38:34 -0700 (PDT)
Received: from hqinbh1.ms.com (hqinbh1-e1.ms.com [205.228.12.65] (may be forged))
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id OAA08467
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 14:38:33 -0700 (PDT)
Received: (from uucp@localhost)
        by hqinbh1.ms.com (8.8.6/fw v1.30) id RAA17298
        for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 17:40:58 -0400 (EDT)
Received: from unknown(144.14.193.5) by hqinbh1 via smap (4.1)
	id xma017205; Tue, 19 Oct 99 17:40:50 -0400
Received: from ms.com (vector.morgan.com [144.14.16.149])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.3) with ESMTP id RAA20587
        for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 17:40:50 -0400 (EDT)
Message-ID: <380CE562.E2A074DA@ms.com>
Date: Tue, 19 Oct 1999 17:40:50 -0400
From: David Madeo <dmadeo@ms.com>
Organization: Morgan Stanley Dean Witter & Co.
X-Mailer: Mozilla 4.7C-CCK-MCD  [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: New Topic: Export of calendar data and metadata
References: <OF6C2076F4.F943CAA5-ON8525680F.0068F655@iris.com> <380CC510.667A2AEB@Software.com> <380CCC98.D54F6D6B@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

> > 4.3.1   Deferred Requirements for Operations on a Calendar
> >
> >    CAP is not required to specify:
> >
> >      - How to copy a calendar on a CS or between CSs.

As an aside, I think I have an issue with this.  I tell my users one of the main
benefits of the interoperability work is that they won't be trapped again in a
proprietary data format.  The last time we switched products, we had to throw away a
lot of data due to a products inability to export it's data.  I'm not sure how many
more episodes like that my career can survive.

While I can certainly appreciate the complexity of a real moveuser tool, I'd like to
see an agreement on at least the details of an export and import of a Calendar.
I just skimmed the CAP document quickly to look for references on how to extract not
only components, but the calendar properties and the VCAR's.  While it certainly looks
like you can do it, I'd appreciate a paragraph explicity explaining what we expect.

Comments?

dmadeo



From owner-ietf-calendar@imc.org  Tue Oct 19 20:00:24 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04360
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 20:00:23 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id QAA11078
	for ietf-calendar-bks; Tue, 19 Oct 1999 16:21:40 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA11073
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 16:21:38 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991019232339.DJJM872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 18:23:39 -0500
Message-ID: <380CFD68.CB22B38E@Software.com>
Date: Tue, 19 Oct 1999 16:23:20 -0700
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-19 - open item - can we defer it?
References: <OF0FA116E8.9778150E-ON8525680F.00724BA3@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF4D228F766292834FA1ACFBE"
Sender: owner-ietf-calendar@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.

--------------msF4D228F766292834FA1ACFBE
Content-Type: multipart/mixed;
 boundary="------------20F35ADDF85DE3221FD012E5"

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


> My previous question still stands:  could post the argument for why _not_ to
> have groups in CAP?

I think the word 'group' needs to be defined. And I am not sure
which usage you mean (or the requirements doc means).

I thought we all agreed that transaction locking was out. Which is
something that is need to operate on a set of calendars (a group?).
The complications arise when we try to back out changes. (What if
x of y calendars can not take the appointment [quota issue or something]?)
How do you back out any inserts into any other calendars?

So as I read the requirements doc, a statement that describes
that the problem exists, covers the issue. I am open to other ideas
or to see what others think. That is just what I thought.

I *REALLY* am not trying to force any issue. I *AM* trying to
drive issues to closure by stating what I think, and as in
this case - find out that I may be wrong.

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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------20F35ADDF85DE3221FD012E5--

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

MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh
PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI
IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi
ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx
NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh
NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2
4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o
/X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB
AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI
T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG
CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH
AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd
08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9
yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8
MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxOTIzMjMyMVowIwYJKoZIhvcNAQkEMRYEFN48
c6kimdCBhroT3Lh5rvPaSpRrMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAdcxd4MxtujQfAbSZIbNTgtGFenulg3GOWgbhdDqGP5wF2+3kNYJaFE8x
LwpxgAiMU703N0xNEkwGeJ2o2tsDPkWD0hDg5AE0+OhiuG0m/S+q31FDZqWIzQ0xK1F3PjPf
F5eOM8dvDR02KA7JUXLLufNLq/1vtsbBTmLMFf6SoV0=
--------------msF4D228F766292834FA1ACFBE--



From owner-ietf-calendar@imc.org  Tue Oct 19 20:07:40 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04457
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 20:07:37 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id QAA11464
	for ietf-calendar-bks; Tue, 19 Oct 1999 16:29:42 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA11460
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 16:29:41 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991019233142.DJMQ872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 18:31:42 -0500
Message-ID: <380CFF4B.F929854E@Software.com>
Date: Tue, 19 Oct 1999 16:31:23 -0700
From: Doug Royer <Doug.Royer@software.com>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
CC: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: New Topic: Export of calendar data and metadata
References: <OF6C2076F4.F943CAA5-ON8525680F.0068F655@iris.com> <380CC510.667A2AEB@Software.com> <380CCC98.D54F6D6B@netscape.com> <380CE562.E2A074DA@ms.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms571668F81826FAF53992F4F1"
Sender: owner-ietf-calendar@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.

--------------ms571668F81826FAF53992F4F1
Content-Type: multipart/mixed;
 boundary="------------50BAB0F39B31A84BA3678DD0"

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



David Madeo wrote:

> ...
> While I can certainly appreciate the complexity of a real moveuser tool, I'd
> like to see an agreement on at least the details of an export and import of
> a Calendar. I just skimmed the CAP document quickly to look for  references
> on how to extract not only components, but the calendar properties and the
> VCAR's.  While it certainly looks like you can do it, I'd appreciate a
> paragraph explicity explaining what we expect.
> 
> Comments?

Great issue. I have added it as 'W-29 import/export".

I agree with you, it will be needed. Also for calendar synchronization
with disconnected devices. There will need to be a way for a intermediate
tool to pull calendars from 2 or more sources, compare, and perhaps
with a users input - merge. The tool it self is not in scope, but
I think it will be a need that we must address (in addition to
import/export). And I think that import/export will also address
the issue.

I do however remember discussions (I forget the results) where this
was discussed and some problems with supporting synchronization were
deemed out of scope. Just supporting import/export may solve the
issue and address the both needs.

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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------50BAB0F39B31A84BA3678DD0--

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

MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh
PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI
IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi
ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx
NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh
NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2
4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o
/X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB
AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI
T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG
CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH
AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd
08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9
yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8
MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAxOTIzMzEyNFowIwYJKoZIhvcNAQkEMRYEFNsN
9jcOtQ95xYPATEh0nlsw+T16MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGATbnhfXl3CuvvHPlYFngFmt1dQrTd0JduY7A71InRc4kv0R4fVLboZpUa
KuGJABkRY2OmGoYuxYfJcAQZxJSr8vmhCWUWzuyf8bWCuRzeKjPVrrhSeNy+AF675VaGgWml
FdRzFz6X4DKrM3m47Sjj5J5alHyf/JxPnmG4CHKIdBc=
--------------ms571668F81826FAF53992F4F1--



From owner-ietf-calendar@imc.org  Tue Oct 19 21:00:28 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04832
	for <calsch-archive@odin.ietf.org>; Tue, 19 Oct 1999 21:00:27 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id RAA12588
	for ietf-calendar-bks; Tue, 19 Oct 1999 17:24:54 -0700 (PDT)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA12584
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 17:24:52 -0700 (PDT)
Received: from Software.com ([207.175.94.123]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <19991020002653.DKAT872.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 19:26:53 -0500
Message-ID: <380D0C3A.7DA1B29E@Software.com>
Date: Tue, 19 Oct 1999 17:26:34 -0700
From: Doug Royer <Doug.Royer@software.com>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar <ietf-calendar@imc.org>,
        ietf-calendar <ietf-calendar@imc.org>
Subject: CHARSET and LANGUAGE
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5F21065B87CA15E7F7F0F2AE"
Sender: owner-ietf-calendar@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.

--------------ms5F21065B87CA15E7F7F0F2AE
Content-Type: multipart/mixed;
 boundary="------------3252657BEEA5A0B06C8012CF"

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


Because it is on the action item list (W-24?) and the SKi project
concerns. Here are issues that I think the were brought up (Please
correct me if I am wrong):

	1) Language of the iCalendar component object.
	2) Charset of the iCalendar component object.
	3) Language participants of an event are expected to understand.

(1) RFC 2445 addresses the issue.

    (iCal 4.2.10) The LANGUAGE parameter
    can be added to TEXT value type properties, overriding the 
    default language. (Specified in MIME header)

    (and later down..)
    For transport in a MIME entity, the Content-Language header field can
    be used to set the default language for the entire body part.
    Otherwise, no default language is assumed.
 
(2) RFC 2445 addresses this issue in the MIME header. If not specified
    in the MIME header, then the object is UTF-8. (iCal 4.1.4).

(3) Not covered in RFC2445 at all.
    I think this is the point of the comments from the SKi project.

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

begin:vcard 
n:Royer;Doug
tel;pager:pager@royer.com or 650-274-8960
tel;cell:650-274-8960
tel;fax:805-957-1544
tel;work:805-957-1790 x541
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:Software.com
version:2.1
email;internet:Doug.Royer@Software.com
title:Architect
adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A
fn:Doug Royer
end:vcard

--------------3252657BEEA5A0B06C8012CF--

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

MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh
PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI
IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs
BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3
dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB
ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5
NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi
ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx
NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh
NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu
Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2
4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o
/X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB
AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1
OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu
Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx
IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25
8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI
T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG
CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH
AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd
08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9
yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8
MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y
eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl
ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MTAyMDAwMjYzNVowIwYJKoZIhvcNAQkEMRYEFJ6m
NDBnA8i6BvA/AW+bD2daxEYKMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGACB91AKywiMqdV0qeI4bspyUzUVCtzXRSixoDjVdc2mdkmxuy73MzVLzm
Yv4WbyBQEb7Tk7o/y6FXSjIKtfRDAsZVvFl14sojG5GhyiovG+b9ACjgZzvOEbpTrUt4pVPp
dBU6n3+5zDJQEamBU7DXe6yJRxNteERb62/VOnMA7SU=
--------------ms5F21065B87CA15E7F7F0F2AE--



From owner-ietf-calendar@imc.org  Wed Oct 20 01:52:54 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14624
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 01:52:53 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id WAA26992
	for ietf-calendar-bks; Tue, 19 Oct 1999 22:04:18 -0700 (PDT)
Received: from hqinbh2.ms.com (hqinbh2.ms.com [205.228.12.72])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id WAA26988
	for <ietf-calendar@imc.org>; Tue, 19 Oct 1999 22:04:16 -0700 (PDT)
Received: (from uucp@localhost)
        by hqinbh2.ms.com (8.8.6/fw v1.30) id BAA23874
        for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 01:06:43 -0400 (EDT)
Received: from unknown(144.14.193.5) by hqinbh2 via smap (4.1)
	id xma023106; Wed, 20 Oct 99 01:06:21 -0400
Received: from ms.com (hqdsl26.morgan.com [205.228.1.26])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.3) with ESMTP id BAA08223
        for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 01:06:21 -0400 (EDT)
Message-ID: <380D4DCE.D424F5B1@ms.com>
Date: Wed, 20 Oct 1999 01:06:22 -0400
From: David Madeo <dmadeo@ms.com>
Reply-To: dmadeo@ms.com
Organization: Morgan Stanley Dean Witter & Co.
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: W-19 - open item - can we defer it?
References: <OF0FA116E8.9778150E-ON8525680F.00724BA3@iris.com>
Content-Type: multipart/mixed;
 boundary="------------B13CDA9B7BE1264CD33E4E2D"
Sender: owner-ietf-calendar@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.
--------------B13CDA9B7BE1264CD33E4E2D
Content-Type: multipart/alternative;
 boundary="------------C0FDB42D6428019DA8D904A9"


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

Bruce_Kahn@iris.com wrote:

>
> Doug provided the citation:
>
> >>From draft-ietf-calsch-capreq-03.txt (the latest):
> >
> >4.3.1   Deferred Requirements for Operations on a Calendar
> >
> >   CAP is not required to specify
> >     - How to copy a calendar on a CS or between CSs.
> >     - How a group operations on a set of calendars.
> [Snip]
>
> Please reread that last one carefully.  It does _not_ preclude us
> having groups on ACLs, it discusses "operations on a set of
> calendars".  The work item was quoted as "CAP Group definitions,
> dynamic and static and how groups are used in VCARs. Policy
> definitions, in a VCAR format." and not referring to groupings of
> calendars.
>
> As a user, I would view the lack of 'groups' on VCARs as a functional
> hole in CAP since I my choice of mail clients and servers that handle
> it just fine.  Yes, there are some added intricacies to calendars that
> do not exist in mail but users dont care how hard it is for us to iron
> out now; they just have a set of existing expectations that I dont
> think can be tossed out lightly...  (Im somewhat surprised that David
> Madeo and other end user reps are not tossing their hats into the ring
> on this yet.  Have they all timed out??)

I think (as others are suggesting) that "groups" is an overloaded term
which we'd do well to either flesh out definitions for, or avoid the use
of.

There are "operations on more than calendar" which Doug refers to, the
"lists of users" groups which Bruce is discussing, and I suspect more
than one person is thinking of a "non-human" calendar that a group of
people use as a "group calendar".

I think Doug's area is a complex topic where it's all or nothing,
requiring either transaction locks, or two passes to verify that
everyone or noone was scheduled.  I'll completely avoid this one, since
I suspect it's either a narrow niche I don't care about, or extremely
useful  in a way I'm not able to comprehend right now.


The "lists of users" type of groups is more interesting to me.  One of
my other projects right now involves setting ACL's based on either users
or groups defined in LDAP.    The ability to define an ACL based on an
LDAP group entry which includes uniquemembers and which happens to be an
internal  mailgroup is priceless.

My users already keep the mailgroups based on organizational units up to
date.  The HR department is automatically populating groups of people
based on cost centers.   The end users know how to add themselves to
topic oriented mailgroups (such as our internal "yankeestickets"
mailgroup).  As a result, I don't have to do any work in setting up
ACL's:  the users do it for me.  They pick which mailgroups they'd like
to grant access to, and the rest happens automagically.  95% of the
ACL's are defined with groups rather than users.  So there's little or
no need to constantly update VCAR's to list new individuals, or remove
old ones.

So yes, I'd strongly argue for allowing VCAR's to store LDAP DN's as an
entity, which can be expanded when required, rather than when saving the
VCAR.  The downside is of course that we have 30,000 "group" entries in
our LDAP database, so a cache may well be warranted.  And if the (thin)
client doesn't know or want to know about LDAP.


The last definition of a group calendar is merely a misunderstanding
that we should make sure is cleared up.

Satisfied Bruce? :-)

dmadeo

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Bruce_Kahn@iris.com wrote:
<blockquote TYPE=CITE>&nbsp;
<br><font face="sans-serif"><font size=-1>Doug provided the citation:</font></font>
<p><font face="Courier New"><font size=-1>>>From draft-ietf-calsch-capreq-03.txt
(the latest):</font></font>
<br><font face="Courier New"><font size=-1>></font></font>
<br><font face="Courier New"><font size=-1>>4.3.1&nbsp;&nbsp; Deferred
Requirements for Operations on a Calendar</font></font>
<br><font face="Courier New"><font size=-1>></font></font>
<br><font face="Courier New"><font size=-1>>&nbsp;&nbsp; CAP is not required
to specify</font></font>
<br><font face="Courier New"><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; -
How to copy a calendar on a CS or between CSs.</font></font>
<br><font face="Courier New"><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp; -
How a group operations on a set of calendars.</font></font>
<br><font face="sans-serif"><font size=-1>[Snip]</font></font>
<p><font size=-1><font face="sans-serif">Please reread that last one carefully.&nbsp;
It does _<u>not</u>_ preclude us having groups on ACLs, it discusses "</font><font face="Courier New">operations
on a <font color="#FF0000">set of calendars</font></font><font face="sans-serif">".&nbsp;
The work item was quoted as "</font></font><font face="Times New Roman"><font size=+0>CAP
Group definitions, dynamic and static and how groups are used in VCARs.
Policy definitions, in a VCAR format.</font></font><font face="sans-serif"><font size=-1>"
and not referring to groupings of calendars.</font></font>
<p><font face="sans-serif"><font size=-1>As a user, I would view the lack
of 'groups' on VCARs as a functional hole in CAP since I my choice of mail
clients and servers that handle it just fine.&nbsp; Yes, there are some
added intricacies to calendars that do not exist in mail but users dont
care how hard it is for us to iron out now; they just have a set of existing
expectations that I dont think can be tossed out lightly...&nbsp; (Im somewhat
surprised that David Madeo and other end user reps are not tossing their
hats into the ring on this yet.&nbsp; Have they all timed out??)</font></font></blockquote>
I think (as others are suggesting) that "groups" is an overloaded term
which we'd do well to either flesh out definitions for, or avoid the use
of.
<p>There are "operations on more than calendar" which Doug refers to, the
"lists of users" groups which Bruce is discussing, and I suspect more than
one person is thinking of a "non-human" calendar that a group of people
use as a "group calendar".
<p>I think Doug's area is a complex topic where it's all or nothing, requiring
either transaction locks, or two passes to verify that everyone or noone
was scheduled.&nbsp; I'll completely avoid this one, since I suspect it's
either a narrow niche I don't care about, or extremely useful&nbsp; in
a way I'm not able to comprehend right now.
<br>&nbsp;
<p>The "lists of users" type of groups is more interesting to me.&nbsp;
One of my other projects right now involves setting ACL's based on either
users or groups defined in LDAP.&nbsp;&nbsp;&nbsp; The ability to define
an ACL based on an LDAP group entry which includes uniquemembers and which
happens to be an internal&nbsp; mailgroup is <b>priceless</b>.
<p>My users already keep the mailgroups based on organizational units up
to date.&nbsp; The HR department is automatically populating groups of
people based on cost centers.&nbsp;&nbsp; The end users know how to add
themselves to topic oriented mailgroups (such as our internal "yankeestickets"
mailgroup).&nbsp; As a result, I don't have to do any work in setting up
ACL's:&nbsp; the users do it for me.&nbsp; They pick which mailgroups they'd
like to grant access to, and the rest happens automagically.&nbsp; 95%
of the ACL's are defined with groups rather than users.&nbsp; So there's
little or no need to constantly update VCAR's to list new individuals,
or remove old ones.
<p>So yes, I'd strongly argue for allowing VCAR's to store LDAP DN's as
an entity, which can be expanded when required, rather than when saving
the VCAR.&nbsp; The downside is of course that we have 30,000 "group" entries
in our LDAP database, so a cache may well be warranted.&nbsp; And if the
(thin) client doesn't know or want to know about LDAP.
<br>&nbsp;
<p>The last definition of a group calendar is merely a misunderstanding
that we should make sure is cleared up.
<p>Satisfied Bruce? :-)
<p>dmadeo</html>

--------------C0FDB42D6428019DA8D904A9--

--------------B13CDA9B7BE1264CD33E4E2D
Content-Type: text/x-vcard; charset=us-ascii;
 name="dmadeo.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Madeo
Content-Disposition: attachment;
 filename="dmadeo.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Madeo;David
tel;fax:212-762-1009
tel;work:212-762-2348
x-mozilla-html:FALSE
url:www.ms.com
org:Morgan Stanley Dean Witter and Discover;Information Technology
version:2.1
email;internet:dmadeo@ms.com
adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA
x-mozilla-cpt:;0
fn:David Madeo
end:vcard

--------------B13CDA9B7BE1264CD33E4E2D--



From owner-ietf-calendar@imc.org  Wed Oct 20 10:39:28 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04704
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 10:39:27 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id GAA10054
	for ietf-calendar-bks; Wed, 20 Oct 1999 06:53:05 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA10050
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 06:53:03 -0700 (PDT)
From: pregen@egenconsulting.com
To: Doug Royer <Doug.Royer@software.com>
Cc: ietf-calendar@imc.org
Subject: Re: New Topic: Export of calendar data and metadata
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF2A4CB9AA.D967D921-ON85256810.004C572A@com>
Date: Wed, 20 Oct 1999 09:55:34 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 10/20/99 09:55:38 AM
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_mixed 004C8EE885256810_="
Sender: owner-ietf-calendar@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>

--=_mixed 004C8EE885256810_=
Content-Type: multipart/alternative; boundary="=_alternative 004C8EE885256810_="


--=_alternative 004C8EE885256810_=
Content-Type: text/plain; charset="us-ascii"

Maybe I'm missing something here, but should it not be the responsibility 
of the client to ensure that there is an export capability.  It seems to 
me that all we need to declare is that an import/export capability be in 
place.  Maybe we say it needs to be, at a minimum, ASCII format.  But, I 
believe all we need to state is the capability must be there and it is 
handled by the client software.




Doug Royer <Doug.Royer@software.com>
Sent by: owner-ietf-calendar@imc.org
10/19/99 07:31 PM

 
        To:     CalSched IETF <ietf-calendar@imc.org>
        cc:     CalSched IETF <ietf-calendar@imc.org>
        Subject:        Re: New Topic: Export of calendar data and metadata



David Madeo wrote:

> ...
> While I can certainly appreciate the complexity of a real moveuser tool, 
I'd
> like to see an agreement on at least the details of an export and import 
of
> a Calendar. I just skimmed the CAP document quickly to look for 
references
> on how to extract not only components, but the calendar properties and 
the
> VCAR's.  While it certainly looks like you can do it, I'd appreciate a
> paragraph explicity explaining what we expect.
> 
> Comments?

Great issue. I have added it as 'W-29 import/export".

I agree with you, it will be needed. Also for calendar synchronization
with disconnected devices. There will need to be a way for a intermediate
tool to pull calendars from 2 or more sources, compare, and perhaps
with a users input - merge. The tool it self is not in scope, but
I think it will be a need that we must address (in addition to
import/export). And I think that import/export will also address
the issue.

I do however remember discussions (I forget the results) where this
was discussed and some problems with supporting synchronization were
deemed out of scope. Just supporting import/export may solve the
issue and address the both needs.

-Doug


--=_alternative 004C8EE885256810_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Maybe I'm missing something here, but should it not be the responsibility of the client to ensure that there is an export capability. &nbsp;It seems to me that all we need to declare is that an import/export capability be in place. &nbsp;Maybe we say it needs to be, at a minimum, ASCII format. &nbsp;But, I believe all we need to state is the capability must be there and it is handled by the client software.</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@imc.org</font>
<p><font size=1 face="sans-serif">10/19/99 07:31 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;CalSched IETF &lt;ietf-calendar@imc.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;CalSched IETF &lt;ietf-calendar@imc.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: New Topic: Export of calendar data and metadata</font></table>
<br>
<br><font size=2><tt><br>
<br>
David Madeo wrote:<br>
<br>
&gt; ...<br>
&gt; While I can certainly appreciate the complexity of a real moveuser tool, I'd<br>
&gt; like to see an agreement on at least the details of an export and import of<br>
&gt; a Calendar. I just skimmed the CAP document quickly to look for &nbsp;references<br>
&gt; on how to extract not only components, but the calendar properties and the<br>
&gt; VCAR's. &nbsp;While it certainly looks like you can do it, I'd appreciate a<br>
&gt; paragraph explicity explaining what we expect.<br>
&gt; <br>
&gt; Comments?<br>
<br>
Great issue. I have added it as 'W-29 import/export&quot;.<br>
<br>
I agree with you, it will be needed. Also for calendar synchronization<br>
with disconnected devices. There will need to be a way for a intermediate<br>
tool to pull calendars from 2 or more sources, compare, and perhaps<br>
with a users input - merge. The tool it self is not in scope, but<br>
I think it will be a need that we must address (in addition to<br>
import/export). And I think that import/export will also address<br>
the issue.<br>
<br>
I do however remember discussions (I forget the results) where this<br>
was discussed and some problems with supporting synchronization were<br>
deemed out of scope. Just supporting import/export may solve the<br>
issue and address the both needs.<br>
<br>
-Doug</tt></font>
<br>
<br>
--=_alternative 004C8EE885256810_=--
--=_mixed 004C8EE885256810_=
Content-Type: application/octet-stream; name="ATTQH7JO"
Content-Disposition: attachment; filename="ATTQH7JO"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

YmVnaW46dmNhcmQgDQpuOlJveWVyO0RvdWcNCnRlbDtwYWdlcjpwYWdlckByb3llci5jb20gb3Ig
NjUwLTI3NC04OTYwDQp0ZWw7Y2VsbDo2NTAtMjc0LTg5NjANCnRlbDtmYXg6ODA1LTk1Ny0xNTQ0
DQp0ZWw7d29yazo4MDUtOTU3LTE3OTAgeDU0MQ0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpo
dHRwOi8vUm95ZXIuY29tL1Blb3BsZS9Eb3VnDQpvcmc6U29mdHdhcmUuY29tDQp2ZXJzaW9uOjIu
MQ0KZW1haWw7aW50ZXJuZXQ6RG91Zy5Sb3llckBTb2Z0d2FyZS5jb20NCnRpdGxlOkFyY2hpdGVj
dA0KYWRyO3F1b3RlZC1wcmludGFibGU6Ozs1MzAgRS4gTW9udGVjaXRvIFN0Lj0wRD0wQTtTYW50
YSBCYXJiYXJhO0NBOzkzMTAzO1UuUy5BDQpmbjpEb3VnIFJveWVyDQplbmQ6dmNhcmQNCg==
--=_mixed 004C8EE885256810_=--


From owner-ietf-calendar@imc.org  Wed Oct 20 10:53:44 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05352
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 10:53:44 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id HAA10518
	for ietf-calendar-bks; Wed, 20 Oct 1999 07:16:11 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA10513
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 07:16:08 -0700 (PDT)
From: pregen@egenconsulting.com
To: CalSched IETF <ietf-calendar@imc.org>
Cc: ietf-calendar@imc.org
Subject: Re: W-19 - open item - can we defer it?
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OFA4F86104.13A9EC42-ON85256810.004E79A7@com>
Date: Wed, 20 Oct 1999 10:19:00 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 10/20/99 10:18:43 AM,
	Serialize complete at 10/20/99 10:18:43 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 004EACD085256810_="
Sender: owner-ietf-calendar@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 004EACD085256810_=
Content-Type: text/plain; charset="us-ascii"

That sounds pretty simple to me.  Can't we add a statement that says just 
this example and say this is how you handle permissions for a group?
Doug wrote in response to Richard Shusterman: 


A VCAR can specify a list of users:

BEGIN:VCAR
CARID:Permisssions for group 'A'
GRANT:UPN=<user1>...
GRANT:UPN=<user2>...
END:VCAR

--=_alternative 004EACD085256810_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">That sounds pretty simple to me. &nbsp;Can't we add a statement that says just this example and say this is how you handle permissions for a group?</font>
<br><font size=2 face="sans-serif">Doug wrote in response to Richard Shusterman: </font>
<br>
<br><font size=2><tt><br>
A VCAR can specify a list of users:<br>
<br>
BEGIN:VCAR<br>
CARID:Permisssions for group 'A'<br>
GRANT:UPN=&lt;user1&gt;...<br>
GRANT:UPN=&lt;user2&gt;...<br>
END:VCAR</tt></font>
<br>
--=_alternative 004EACD085256810_=--


From owner-ietf-calendar@imc.org  Wed Oct 20 11:16:56 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06753
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 11:16:56 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id GAA09700
	for ietf-calendar-bks; Wed, 20 Oct 1999 06:37:29 -0700 (PDT)
Received: from hqinbh2.ms.com (hqinbh2.ms.com [205.228.12.72])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id GAA09696
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 06:37:28 -0700 (PDT)
Received: (from uucp@localhost)
        by hqinbh2.ms.com (8.8.6/fw v1.30) id JAA18238;
        Wed, 20 Oct 1999 09:40:01 -0400 (EDT)
Received: from unknown(144.14.193.5) by hqinbh2 via smap (4.1)
	id xma017932; Wed, 20 Oct 99 09:39:36 -0400
Received: from ms.com (hqdsl26.morgan.com [205.228.1.26])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.3) with ESMTP id JAA04032;
        Wed, 20 Oct 1999 09:39:36 -0400 (EDT)
Message-ID: <380DC61A.AE8AF4A@ms.com>
Date: Wed, 20 Oct 1999 09:39:38 -0400
From: David Madeo <dmadeo@ms.com>
Reply-To: dmadeo@ms.com
Organization: Morgan Stanley Dean Witter & Co.
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: Doug Royer <Doug.Royer@software.com>
CC: ietf-calendar <ietf-calendar@imc.org>
Subject: Re: CHARSET and LANGUAGE
References: <380D0C3A.7DA1B29E@Software.com>
Content-Type: multipart/mixed;
 boundary="------------483B88F174ED11504AFF53A3"
Sender: owner-ietf-calendar@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.
--------------483B88F174ED11504AFF53A3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>         1) Language of the iCalendar component object.
>         2) Charset of the iCalendar component object.
>         3) Language participants of an event are expected to understand.
>
> (3) Not covered in RFC2445 at all.
>     I think this is the point of the comments from the SKi project.

I'd venture a guess that if the title of an event is in Spanish, that's what
I'll hear if I attend.  If I had a hard time reading the title,  because I
didn't recognize the language, then it really doesn't matter if I could find
out that it was Danish or Japanese.

Having said that, there are lots of cases where even if you don't understand
the spoken language, you can get by with alternate means.  If I go to the
latest French movie here in NYC, the audible sound I hear will be French,
with English subtitles.  When I go to the Opera, I hear Italian with
English/Spanish/French subtitles on the little digital display, a sign
language interpreter in the corner and headsets for the blind.  When flying
Air France, they'll say everything in French and repeat it in English.

So I'd agree this is important and useful.

dmadeo

--------------483B88F174ED11504AFF53A3
Content-Type: text/x-vcard; charset=us-ascii;
 name="dmadeo.vcf"
Content-Description: Card for David Madeo
Content-Disposition: attachment;
 filename="dmadeo.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Madeo;David
tel;fax:212-762-1009
tel;work:212-762-2348
x-mozilla-html:FALSE
url:www.ms.com
org:Morgan Stanley Dean Witter and Discover;Information Technology
version:2.1
email;internet:dmadeo@ms.com
adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA
x-mozilla-cpt:;0
fn:David Madeo
end:vcard

--------------483B88F174ED11504AFF53A3--



From owner-ietf-calendar@imc.org  Wed Oct 20 11:40:55 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08230
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 11:40:53 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id HAA11315
	for ietf-calendar-bks; Wed, 20 Oct 1999 07:56:27 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA11311
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 07:56:25 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: ietf-calendar@imc.org
Cc: Doug.Royer@software.com
Subject: Re: W-19 - open item - can we defer it?
X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999
Message-ID: <OF284F7B97.D0B50023-ON85256810.005139C2@iris.com>
Date: Wed, 20 Oct 1999 10:58:07 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.1b|September 30, 1999) at 10/20/99
 10:59:30 AM,
	Serialize complete at 10/20/99 10:59:30 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0052D26B85256810_="
Sender: owner-ietf-calendar@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 0052D26B85256810_=
Content-Type: text/plain; charset="us-ascii"

Doug replied:
>> My previous question still stands:  could post the argument for why 
_not_ to
>> have groups in CAP?
>
>I think the word 'group' needs to be defined. And I am not sure
>which usage you mean (or the requirements doc means).

Fair enough.  Could be we really are all on the same page... But I think 
we are talking @ 2 different levels.

>I thought we all agreed that transaction locking was out.

100% agreement here!  Next...

My use of "groups" is talking about groups of CUs rather than calendars 
themselves.  When I say "Im in the group called Developers" I mean I am a 
member of a list of CUs that is labeled "Developers".  The text in the 
work item was (in part) "CAP Group definitions, dynamic and static and how 
groups are used in VCARs. ".  I never took this to mean "groups of 
calendars" but rather "groups of users" since VCARs are applied on 
calendars _against_ CUs to grant/deny access.

Richards posting indicates that he was also referring to groups of users 
so I dont feel toooo bad about being the instigator of this 
miscommunication.  Now that we are on the same page WRT terms, Id like to 
hear Dougs (and others) thoughts on the inclusion/exclusion of "groups of 
users" in access rights.

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




<br><font size=2 face="sans-serif">Doug replied:</font>
<br><font size=2 face="Courier New">&gt;&gt; My previous question still stands: &nbsp;could post the argument for why _not_ to<br>
&gt;&gt; have groups in CAP?<br>
&gt;<br>
&gt;I think the word 'group' needs to be defined. And I am not sure<br>
&gt;which usage you mean (or the requirements doc means).<br>
</font>
<br><font size=2 face="sans-serif">Fair enough. &nbsp;Could be we really are all on the same page... But I think we are talking @ 2 different levels.</font>
<br><font size=2 face="sans-serif"><br>
</font><font size=2 face="Courier New">&gt;I thought we all agreed that transaction locking was out.<br>
</font>
<br><font size=2 face="sans-serif">100% agreement here! &nbsp;Next...</font>
<br>
<br><font size=2 face="sans-serif">My use of &quot;groups&quot; is talking about groups of CUs rather than calendars themselves. &nbsp;When I say &quot;Im in the group called Developers&quot; I mean I am a member of a list of CUs that is labeled &quot;Developers&quot;. &nbsp;The text in the work item was (in part) &quot;CAP Group definitions, dynamic and static and how groups are used in VCARs. &quot;. &nbsp;I never took this to mean &quot;groups of calendars&quot; but rather &quot;groups of users&quot; since VCARs are applied on calendars _against_ CUs to grant/deny access.</font>
<br>
<br><font size=2 face="sans-serif">Richards posting indicates that he was also referring to groups of users so I dont feel toooo bad about being the instigator of this miscommunication. &nbsp;Now that we are on the same page WRT terms, Id like to hear Dougs (and others) thoughts on the inclusion/exclusion of &quot;groups of users&quot; in access rights.</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 0052D26B85256810_=--


From owner-ietf-calendar@imc.org  Wed Oct 20 11:55:38 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09147
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 11:55:38 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id IAA11712
	for ietf-calendar-bks; Wed, 20 Oct 1999 08:12:04 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA11701
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 08:11:59 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: W-19 - open item - can we defer it?
X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999
Message-ID: <OFE42705A3.784833BB-ON85256810.00529132@iris.com>
Date: Wed, 20 Oct 1999 11:14:28 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.1b|September 30, 1999) at 10/20/99
 11:15:03 AM,
	Serialize complete at 10/20/99 11:15:03 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005451A585256810_="
Sender: owner-ietf-calendar@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 005451A585256810_=
Content-Type: text/plain; charset="us-ascii"

Doug proposed:
>A VCAR can specify a list of users:
>
>BEGIN:VCAR
>CARID:Permisssions for group 'A'
>GRANT:UPN=<user1>...
>GRANT:UPN=<user2>...
>END:VCAR

Sure it can.  However this is the case of the statically exploded group of 
users (new term, add to your vocabs please!).  It will not help me when I 
have a new user that I want to add to the  the original groups of users 
that you exploded.  Any CU who 'exploded' these groups of users originally 
will not get any new additions that occur after exploding.  This is bad! 
It really defeats the entire strength of groups of users; the ability to 
'inherit' (loaded term alert!  Intent = dynamically get the content of 
when needed/asked for).

Just how would all 1500+ of us manage our VCARs for 
"IETF-CalSched@imc.org" if we exploded them at the time we created the 
VCAR?  You would not get the new subscribers or lose the ones that are not 
on it any more!

Sure, dynamic expansion of groups of user will require some cycles to do 
but it is not nuclear physics.  However I think that implementation 
details need not enter into this discussion now (just like they didnt for 
ATTENDEE;TYPE=GROUP or ATTENDEE;MEMBER=IETF-CalSched).

Bruce
PS: Who here honestly would stand up in front of a User Group meeting or 
conference and _honestly_ say that doing dynamic groups of users expansion 
was too hard to do and that static expansion is really the better choice?? 
 ( Ill be in the front row of that talk! ;^) )
===========================================================================
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 005451A585256810_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Doug proposed:</font>
<br><font size=2 face="Courier New">&gt;A VCAR can specify a list of users:<br>
&gt;<br>
&gt;BEGIN:VCAR<br>
&gt;CARID:Permisssions for group 'A'<br>
&gt;GRANT:UPN=&lt;user1&gt;...<br>
&gt;GRANT:UPN=&lt;user2&gt;...<br>
&gt;END:VCAR</font>
<br>
<br><font size=2 face="sans-serif">Sure it can. &nbsp;However this is the case of the statically exploded group of users (new term, add to your vocabs please!). &nbsp;It will not help me when I have a new user that I want to add to the &nbsp;the original groups of users that you exploded. &nbsp;Any CU who 'exploded' these groups of users originally will not get any new additions that occur after exploding. &nbsp;This is bad! &nbsp;It really defeats the entire strength of groups of users; the ability to 'inherit' (loaded term alert! &nbsp;Intent = dynamically get the content of when needed/asked for).</font>
<br>
<br><font size=2 face="sans-serif">Just how would all 1500+ of us manage our VCARs for &quot;IETF-CalSched@imc.org&quot; if we exploded them at the time we created the VCAR? &nbsp;You would not get the new subscribers or lose the ones that are not on it any more!</font>
<br>
<br><font size=2 face="sans-serif">Sure, dynamic expansion of groups of user will require some cycles to do but it is not nuclear physics. &nbsp;However I think that implementation details need not enter into this discussion now (just like they didnt for ATTENDEE;TYPE=GROUP or ATTENDEE;MEMBER=IETF-CalSched).</font>
<br>
<br><font size=2 face="sans-serif">Bruce</font>
<br><font size=2 face="sans-serif">PS: Who here honestly would stand up in front of a User Group meeting or conference and _honestly_ say that doing dynamic groups of users expansion was too hard to do and that static expansion is really the better choice?? &nbsp;( Ill be in the front row of that talk! ;^) )</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 005451A585256810_=--


From owner-ietf-calendar@imc.org  Wed Oct 20 11:56:30 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09277
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 11:56:29 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id IAA11755
	for ietf-calendar-bks; Wed, 20 Oct 1999 08:13:37 -0700 (PDT)
Received: from hqinbh2.ms.com (hqinbh2.ms.com [205.228.12.72])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA11749
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 08:13:35 -0700 (PDT)
Received: (from uucp@localhost)
        by hqinbh2.ms.com (8.8.6/fw v1.30) id LAA18782;
        Wed, 20 Oct 1999 11:16:08 -0400 (EDT)
Received: from unknown(144.14.193.5) by hqinbh2 via smap (4.1)
	id xma018432; Wed, 20 Oct 99 11:15:54 -0400
Received: from ms.com (hqdsl26.morgan.com [205.228.1.26])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.3) with ESMTP id LAA07651;
        Wed, 20 Oct 1999 11:15:53 -0400 (EDT)
Message-ID: <380DDCAA.CF4AD140@ms.com>
Date: Wed, 20 Oct 1999 11:15:54 -0400
From: David Madeo <dmadeo@ms.com>
Reply-To: dmadeo@ms.com
Organization: Morgan Stanley Dean Witter & Co.
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: pregen@egenconsulting.com
CC: Doug Royer <Doug.Royer@software.com>, ietf-calendar@imc.org
Subject: Re: New Topic: Export of calendar data and metadata
References: <OF2A4CB9AA.D967D921-ON85256810.004C572A@com>
Content-Type: multipart/mixed;
 boundary="------------FE567408CDF0743825E1EA15"
Sender: owner-ietf-calendar@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.
--------------FE567408CDF0743825E1EA15
Content-Type: multipart/alternative;
 boundary="------------AFAAB3AB549AD392349394C3"


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

pregen@egenconsulting.com wrote:

>
> Maybe I'm missing something here, but should it not be the
> responsibility of the client to ensure that there is an export
> capability.  It seems to me that all we need to declare is that an
> import/export capability be in place.  Maybe we say it needs to be, at
> a minimum, ASCII format.  But, I believe all we need to state is the
> capability must be there and it is handled by the client software.

I'd like to make sure that we define what an "export" is, regardless of
which client you happen to use.     CUA-1 exports just the calendar
data, but not the metadata.  CUA-2 exports both.    I've lost data if
I'm using CUA-1

I don't think this is a new function "EXPORT" or anything, though I'm
interested if others think that is the way to go.  Personally, I suspect
it will be a paragraph explaining what it means to export/import a
calendar, and a list of queries.  The queries will extract a single
calendar with both the calendar data as well as the metadata.  If
everyone uses the same queries, then every product would produce
identical export/import files, which is a good thing.

dmadeo

PS: I'd hope that the servers which export data behind the scenes would
also use the same queries.

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
pregen@egenconsulting.com wrote:
<blockquote TYPE=CITE>&nbsp;
<br><font face="sans-serif"><font size=-1>Maybe I'm missing something here,
but should it not be the responsibility of the client to ensure that there
is an export capability.&nbsp; It seems to me that all we need to declare
is that an import/export capability be in place.&nbsp; Maybe we say it
needs to be, at a minimum, ASCII format.&nbsp; But, I believe all we need
to state is the capability must be there and it is handled by the client
software.</font></font></blockquote>

<p><br>I'd like to make sure that we define what an "export" is, regardless
of which client you happen to use.&nbsp;&nbsp;&nbsp;&nbsp; CUA-1 exports
just the calendar data, but not the metadata.&nbsp; CUA-2 exports both.&nbsp;&nbsp;&nbsp;
I've lost data if I'm using CUA-1
<p>I don't think this is a new function "EXPORT" or anything, though I'm
interested if others think that is the way to go.&nbsp; Personally, I suspect
it will be a paragraph explaining what it means to export/import a calendar,
and a list of queries.&nbsp; The queries will extract a single calendar
with both the calendar data as well as the metadata.&nbsp; If everyone
uses the same queries, then every product would produce identical export/import
files, which is a good thing.
<p>dmadeo
<p>PS: I'd hope that the servers which export data behind the scenes would
also use the same queries.</html>

--------------AFAAB3AB549AD392349394C3--

--------------FE567408CDF0743825E1EA15
Content-Type: text/x-vcard; charset=us-ascii;
 name="dmadeo.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Madeo
Content-Disposition: attachment;
 filename="dmadeo.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Madeo;David
tel;fax:212-762-1009
tel;work:212-762-2348
x-mozilla-html:FALSE
url:www.ms.com
org:Morgan Stanley Dean Witter and Discover;Information Technology
version:2.1
email;internet:dmadeo@ms.com
adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA
x-mozilla-cpt:;0
fn:David Madeo
end:vcard

--------------FE567408CDF0743825E1EA15--



From owner-ietf-calendar@imc.org  Wed Oct 20 12:34:26 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11617
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 12:34:25 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id JAA13007
	for ietf-calendar-bks; Wed, 20 Oct 1999 09:09:44 -0700 (PDT)
Received: from mail1.ecal.com (mailer.appoint.net [12.3.63.76] (may be forged))
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA13003
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 09:09:43 -0700 (PDT)
Received: from ariel.appoint.lan ([209.218.166.130]) by mail1.ecal.com
          (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35)
          with ESMTP id com for <ietf-calendar@imc.org>;
          Wed, 20 Oct 1999 12:12:39 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.appoint.lan (8.8.7/8.8.7) with ESMTP id MAA26190
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 12:11:33 -0400
Message-ID: <380DE9B5.E0C6E3E0@ecal.com>
Date: Wed, 20 Oct 1999 12:11:33 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar <ietf-calendar@imc.org>
Subject: Re: CHARSET and LANGUAGE
References: <380D0C3A.7DA1B29E@Software.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

Doug Royer wrote:

>         3) Language participants of an event are expected to understand.

There might be more than one, actually--for example, if you have a group of
people who are fluent in both English and German, and habitually speak both
interchangably, and they invite someone to their meeting, it would be nice
if it could be made clear what to expect.  Or, more plausibly, you might
have a play which switches languages frequently.

This is an edge case, but it seems like it should be pretty easy to support.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"The Reality Check's in the mail." --L. Peter|
|francis@ecal.com|Deutsch                                      |
\==============================================================/





From owner-ietf-calendar@imc.org  Wed Oct 20 12:43:06 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11984
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 12:43:05 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id JAA13133
	for ietf-calendar-bks; Wed, 20 Oct 1999 09:11:14 -0700 (PDT)
Received: from mail1.ecal.com (mailer.appoint.net [12.3.63.76] (may be forged))
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA13128
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 09:11:13 -0700 (PDT)
Received: from ariel.appoint.lan ([209.218.166.130]) by mail1.ecal.com
          (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35)
          with ESMTP id com for <ietf-calendar@imc.org>;
          Wed, 20 Oct 1999 12:14:10 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.appoint.lan (8.8.7/8.8.7) with ESMTP id MAA26198
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 12:13:04 -0400
Message-ID: <380DEA0F.C866DC41@ecal.com>
Date: Wed, 20 Oct 1999 12:13:04 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar <ietf-calendar@imc.org>
Subject: Re: CHARSET and LANGUAGE
References: <380D0C3A.7DA1B29E@Software.com> <380DC61A.AE8AF4A@ms.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

David Madeo wrote:

> I'd venture a guess that if the title of an event is in Spanish, that's what
> I'll hear if I attend.  If I had a hard time reading the title,  because I
> didn't recognize the language, then it really doesn't matter if I could find
> out that it was Danish or Japanese.

Ah, but it does matter, because you might be able to delegate to someone who
does know the language.

Plus, there's the problem of cognates: you might look at a title and think it's
in Spanish, but it's actually in Italian.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Round up the usual disclaimers.              |
|francis@ecal.com|                                             |
\==============================================================/





From owner-ietf-calendar@imc.org  Wed Oct 20 12:46:27 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12127
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 12:46:25 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id JAA12942
	for ietf-calendar-bks; Wed, 20 Oct 1999 09:07:13 -0700 (PDT)
Received: from mail1.ecal.com (mailer.appoint.net [12.3.63.76] (may be forged))
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA12937
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 09:07:11 -0700 (PDT)
Received: from ariel.appoint.lan ([209.218.166.130]) by mail1.ecal.com
          (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35)
          with ESMTP id com for <ietf-calendar@imc.org>;
          Wed, 20 Oct 1999 12:10:02 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.appoint.lan (8.8.7/8.8.7) with ESMTP id MAA26182
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 12:08:55 -0400
Message-ID: <380DE917.9E99896@ecal.com>
Date: Wed, 20 Oct 1999 12:08:55 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: calsch WG <ietf-calendar@imc.org>
Subject: Re: queries for unbounded recurring components
References: <OFE9E35840.9FABBC8B-ON8525680F.001CFFCF@Lotus.com> <380BFE37.65FD83D6@netscape.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

Steve Mansour wrote:

> Hmmm... I think it's more involved than that.  Are you
> suggesting that all clients/requesters should know how to
> expand the RRULE?  A light-weight client app may want all the
> instances of a recurring event.

Yes, but we have to think about bandwidth issues--especially
since one of the important places for thin clients is in non-PC
devices in the home, where you probably have 56k or less.

I would prefer to see a protocol where the server is never
required to do the expansion itself.  CPU time is so much cheaper
than bandwidth that it's unreasonable for the clients not to take
on the load.  (For that matter, why should the overworked server
CPU take on that work for its thousands of clients? Push the hard
parts to the edges; that's what makes the Internet run.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Help stamp out vi in our lifetime!           |
|francis@ecal.com|                                             |
\==============================================================/





From owner-ietf-calendar@imc.org  Wed Oct 20 12:49:14 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12277
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 12:49:13 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id JAA13174
	for ietf-calendar-bks; Wed, 20 Oct 1999 09:12:25 -0700 (PDT)
Received: from mail1.ecal.com (mailer.appoint.net [12.3.63.76] (may be forged))
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA13168
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 09:12:24 -0700 (PDT)
Received: from ariel.appoint.lan ([209.218.166.130]) by mail1.ecal.com
          (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35)
          with ESMTP id com for <ietf-calendar@imc.org>;
          Wed, 20 Oct 1999 12:15:21 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.appoint.lan (8.8.7/8.8.7) with ESMTP id MAA26202
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 12:14:14 -0400
Message-ID: <380DEA55.D836BFEF@ecal.com>
Date: Wed, 20 Oct 1999 12:14:13 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: W-19 - open item - can we defer it?
References: <OFE42705A3.784833BB-ON85256810.00529132@iris.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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:

> Sure it can.  However this is the case of the statically
> exploded group of users (new term, add to your vocabs please!).

I think I'll add the term "statically *expanded* group of users",
if you don't mind.  "Statically exploded" sounds like they
scuffed their shoes too hard.  :-)

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Q: What goes "Pieces of 7! Pieces of 7!"? A: A|
|francis@ecal.com|parroty error.                                |
\===============================================================/





From owner-ietf-calendar@imc.org  Wed Oct 20 14:06:06 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16700
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 14:06:05 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id JAA13536
	for ietf-calendar-bks; Wed, 20 Oct 1999 09:29:35 -0700 (PDT)
Received: from mail1.ecal.com (mailer.appoint.net [12.3.63.76] (may be forged))
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA13532
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 09:29:34 -0700 (PDT)
Received: from ariel.appoint.lan ([209.218.166.130]) by mail1.ecal.com
          (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35)
          with ESMTP id com for <ietf-calendar@imc.org>;
          Wed, 20 Oct 1999 12:32:30 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.appoint.lan (8.8.7/8.8.7) with ESMTP id LAA26161
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 11:59:57 -0400
Message-ID: <380DE6FD.1587D54F@ecal.com>
Date: Wed, 20 Oct 1999 11:59:57 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: W-19 - open item - can we defer it?
References: <OFA4F86104.13A9EC42-ON85256810.004E79A7@com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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:

> That sounds pretty simple to me.  Can't we add a statement that
> says just this example and say this is how you handle
> permissions for a group?
> Doug wrote in response to Richard Shusterman:
>
> A VCAR can specify a list of users:
>
> BEGIN:VCAR
> CARID:Permisssions for group 'A'
> GRANT:UPN=<user1>...
> GRANT:UPN=<user2>...
> END:VCAR

But this is a static group (to use Bruce's term); every time the
group membership changes, the VCAR will have to be updated.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |This is the .sig that says... Ni!            |
|francis@ecal.com|                                             |
\==============================================================/





From owner-ietf-calendar@imc.org  Wed Oct 20 14:14:00 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17056
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 14:13:59 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id KAA14721
	for ietf-calendar-bks; Wed, 20 Oct 1999 10:41:15 -0700 (PDT)
Received: from mail1.myriad.com (firewall.myriad.com [209.160.31.225])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id KAA14717
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 10:41:14 -0700 (PDT)
Received: from dr.myriad.com by mail1.myriad.com
          via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Oct 1999 17:43:49 UT
Received: from catalina.myriad.com (catalina [208.128.136.17])
	by dr.myriad.com (8.9.2/8.9.2) with ESMTP id LAA00006
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 11:43:48 -0600 (MDT)
Received: from myriad.com (dxdh_42 [10.2.4.42])
	by catalina.myriad.com (8.8.8+Sun/8.8.8) with ESMTP id LAA23882
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 11:43:15 -0600 (MDT)
Message-ID: <380DFFA3.42C90ADA@myriad.com>
Date: Wed, 20 Oct 1999 11:45:07 -0600
From: Paul Hill <phill@myriad.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar <ietf-calendar@imc.org>
Subject: Re: CHARSET and LANGUAGE
References: <380D0C3A.7DA1B29E@Software.com> <380DC61A.AE8AF4A@ms.com>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by dr.myriad.com id LAA00006
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.imc.org id KAA14718
Sender: owner-ietf-calendar@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

I have been a lurking on the ietf-calendar list for awhile, mostly because I don't
at this time deal with programming event/scheduling/calendar issues, but I thought
I'd jump in with a few comments on language.

Firstly FWIW, language codes are defined in ISO3166. My examples below do
not use those codes (i.e. ES for Espańol, EN for English).

David Madeo wrote:
> Having said that, there are lots of cases where even if you don't understand
> the spoken language, you can get by with alternate means.
>[...]
> So I'd agree this is important and useful.

Okay, so let me offer the following list of possible scenerios and those writing
the standard can work out how the standard covers or does not cover these examples.

1. A river trip in the wilds of Idaho where the language is English.

#1 is simple enough.

2. A ski week in Switzerland with guides availage in French, English, German etc.

The difference between 1 and 2 is that #2 includes many languages.

3. An Opera in Italian with supertitles in English (?, around here they project them on a little
strip _above_ the stage or hanging from the balcony etc.)

#3 has a single secondary language, but #2 has many primary languages

4. An Opera in Italian with Spanish, French, English available through a 'little
digital display'

#4 points out the need for a list of secondary languages and hints at a 'delivery
method' attribute.

5. An international conference where the Calendar entries have all been transalated
into various languages, so forget about guessing from the title (because
a particular calendar received a particular transalation), but the user would want to
know that the speaker is giving the talk in Catalan, but there will be a simultaneous
French and Spanish translation. This would be different than the proceeding of the
conference being published in French, English, Spanish and German (I assume the
languages of the proceedings are outside of this standard, but maybe not, see
next example) 

#5 shows that the language of the calendar entry is no indication of what
will happening with the primary and any secondary languages of the event.
There is a real DIT/DOT distinction (see discussion from last week)
going on here.

6. A board meeting of an American cooperation in L.A. where the presentation are
in English only, but printed versions of the talks are available in Japanese.

Hopefully, #6 is nearly the same as #3, with only the possible description
of the form of the secondary language.

(I'll leave out the scenerio of #5 that include "a presentation from Latin American division
President in Spanish". That could get us into an example of two primary languages
and one secondary)

The multi-lingual conference and the vacation week with multiple languages available,
both seem like real, but complex enough possibilities that would be good to
cover.

-Paul


From owner-ietf-calendar@imc.org  Wed Oct 20 14:38:20 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18218
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 14:38:18 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id LAA15361
	for ietf-calendar-bks; Wed, 20 Oct 1999 11:06:12 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA15357
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 11:06:11 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: sman@netscape.com (Steve Mansour)
Cc: ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999
Message-ID: <OFF01CC26B.82972A26-ON85256810.0063361B@iris.com>
Date: Wed, 20 Oct 1999 14:08:42 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.1b|September 30, 1999) at 10/20/99
 02:09:16 PM,
	Serialize complete at 10/20/99 02:09:16 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0064450985256810_="
Sender: owner-ietf-calendar@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 0064450985256810_=
Content-Type: text/plain; charset="us-ascii"

A bit late but...

Steve asked:
>Suppose we have a component that recurs like this: 
>... 
>UID:12345 
>RRULE:FREQ=DAILY 
>...
>Now a query is made to the CAP server to return all instances of the 
event. That is, 
>WHERE (UID EQ 12345)
>What should be returned?

Well, I would say that you could only return the 'parent' or main entry. 
Since the request does not ask for RECUR-ID, the CS should not send it 
back!  Since the request also neglects to ask for the RRULEs, EXRULEs, 
RDATEs and EXDATEs that may be there, the requestor obviously does not 
want to know about the recurrence set or info.

>Should the server attempt to unravel it and clip it after some number of 
instances?

Nope, that is not what the requestor asked for.

>Should we return one event with the RRULE and let the requester unravel 
it (that's *really* bad)?

Nope again.  They did not specify they wanted the RRULE back.  It was 
_THEIR_ choice; I didnt make 'em not request it (at least not directly :^o 
)

>Something else?

Nope.  You simply return what they asked for.  If they want the recurrence 
info, they have to ask for it.  We are building C&S here, not doing mind 
reading tricks.

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




<br><font size=2 face="sans-serif">A bit late but...</font>
<br>
<br><font size=2 face="sans-serif">Steve asked:</font>
<br><font size=3 face="Times New Roman">&gt;Suppose we have a component that recurs like this: </font>
<br><font size=3 face="Times New Roman">&gt;... <br>
&gt;UID:12345 <br>
&gt;RRULE:FREQ=DAILY <br>
&gt;...</font>
<br><font size=3 face="Times New Roman">&gt;Now a query is made to the CAP server to return all instances of the event. That is, </font>
<br><font size=3 face="Times New Roman">&gt;WHERE (UID EQ 12345)</font>
<br><font size=3 face="Times New Roman">&gt;What should be returned?</font>
<br>
<br><font size=2 face="sans-serif">Well, I would say that you could only return the 'parent' or main entry. &nbsp;Since the request does not ask for RECUR-ID, the CS should not send it back! &nbsp;Since the request also neglects to ask for the RRULEs, EXRULEs, RDATEs and EXDATEs that may be there, the requestor obviously does not want to know about the recurrence set or info.</font>
<br>
<br><font size=3 face="Times New Roman">&gt;Should the server attempt to unravel it and clip it after some number of instances?</font>
<br>
<br><font size=2 face="sans-serif">Nope, that is not what the requestor asked for.</font>
<br>
<br><font size=3 face="Times New Roman">&gt;Should we return one event with the RRULE and let the requester unravel it (that's *really* bad)?</font>
<br>
<br><font size=2 face="sans-serif">Nope again. &nbsp;They did not specify they wanted the RRULE back. &nbsp;It was _THEIR_ choice; I didnt make 'em not request it (at least not directly :^o )</font>
<br>
<br><font size=3 face="Times New Roman">&gt;Something else?</font>
<br>
<br><font size=2 face="sans-serif">Nope. &nbsp;You simply return what they asked for. &nbsp;If they want the recurrence info, they have to ask for it. &nbsp;We are building C&amp;S here, not doing mind reading tricks.</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 0064450985256810_=--


From owner-ietf-calendar@imc.org  Wed Oct 20 14:53:19 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18933
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 14:53:14 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id LAA15499
	for ietf-calendar-bks; Wed, 20 Oct 1999 11:15:48 -0700 (PDT)
Received: from home.royer.com. (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id LAA15495
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 11:15:46 -0700 (PDT)
Received: from home.Royer.com by home.royer.com. (SMI-8.6/SMI-SVR4)
	id LAA12449; Wed, 20 Oct 1999 11:18:47 -0700
Message-ID: <380E0784.D64EFC21@home.Royer.com>
Date: Wed, 20 Oct 1999 11:18:44 -0700
From: Doug Royer <Doug@home.Royer.com>
Reply-To: CalSched IETF <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: IETF CALSCH WG <ietf-calendar@imc.org>
Subject: Re: W-19 - open item - can we defer it?
References: <OFA4F86104.13A9EC42-ON85256810.004E79A7@com> <380DE6FD.1587D54F@ecal.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms9D8EE563A9CA9BDC088384F8"
Sender: owner-ietf-calendar@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.

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

John Stracke wrote:

> > A VCAR can specify a list of users:
> >
> > BEGIN:VCAR
> > CARID:Permisssions for group 'A'
> > GRANT:UPN=<user1>...
> > GRANT:UPN=<user2>...
> > END:VCAR
> 
> But this is a static group (to use Bruce's term); every time the
> group membership changes, the VCAR will have to be updated.

So this is the same idea as email aliases?

I do not remember there being a requirement that a CUA must be
able to get, set, and manipulate group lists. Without that requirement
they can't be used - correct?

I also do not remember a requirement that a CS must get, set, and
manipulate group lists. Without that requirement
they can't be used - correct?

I do not understand (yet) the UPN ~stuff~. Is somone prepared
to describe a group UPN? Or am I still missing the point?

-Doug
--------------ms9D8EE563A9CA9BDC088384F8
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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDIwMTgxODQ1WjAjBgkqhkiG9w0BCQQxFgQUnJ4h58nG
oCNS3H9a9aQH953LQmYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYC1p95/H7527l1mCoFrgU/ekYOC7lycCWnamLIB44xCjRBiDMhweDr0TVNb+3V/
vYJp7eYwSEkhyZgB0AaOUWbXvI8jc30YC2GrIuXSkDPlgO8sb1BjNBfnALB4JYnZJtZ1ph4S
qR/NRM68iZE5la9CFkoG9pSbW8JL0FeAD0/PzQ==
--------------ms9D8EE563A9CA9BDC088384F8--



From owner-ietf-calendar@imc.org  Wed Oct 20 14:53:35 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18952
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 14:53:34 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id LAA15467
	for ietf-calendar-bks; Wed, 20 Oct 1999 11:13:51 -0700 (PDT)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA15463
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 11:13:49 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: sman@netscape.com (Steve Mansour)
Cc: Frank_Dawson@lotus.com, ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999
Message-ID: <OF9E42AD7F.C0D79E55-ON85256810.0063CDF6@iris.com>
Date: Wed, 20 Oct 1999 14:16:18 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.1b|September 30, 1999) at 10/20/99
 02:16:53 PM,
	Serialize complete at 10/20/99 02:16:53 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0064F74785256810_="
Sender: owner-ietf-calendar@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 0064F74785256810_=
Content-Type: text/plain; charset="us-ascii"

Steve wrote:
>A light-weight client app may want all the instances of a recurring 
event. Must it expand the RRULEs / EXRULEs ? 

Back to basics time.  If the client does not ask for the RECUR-ID or 
RRULE, RDATE, EXDATE or EXRULE properties then the CS MUST NOT send them 
back!!  The CS MUST only send back what the CUA requests.

Now think back to the creation of RFC 2445 and you may recall that we 
discussed what a CUA should do if it gets stuff it does not grok like 
RRULEs, etc.  The answer was that it could (should?) send back a 
REQUEST-STATUS property that indicated "I do not grok recurrence grammars 
so my response may not be 100% what you want" (in addition to the CUs 
"REQUEST-STATUS: 2.0; Ill be there"!)

However, if the CUA does not grok EX/RRULEs then it wont ask for them.  So 
this may be somewhat moot.  It does however raise the question about the 
search mechanism/language.  Could a CUA use the currently proposed 
mechanism/language to request "Give me the next 3 entries for UID:12345 
after 19991019T142100"?

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




<br><font size=2 face="sans-serif">Steve wrote:</font>
<br><font size=3 face="Times New Roman">&gt;A light-weight client app may want all the instances of a recurring event. Must it expand the RRULEs / EXRULEs ? </font>
<br>
<br><font size=2 face="sans-serif">Back to basics time. &nbsp;If the client does not ask for the RECUR-ID or RRULE, RDATE, EXDATE or EXRULE properties then the CS MUST NOT send them back!! &nbsp;The CS MUST only send back what the CUA requests.</font>
<br>
<br><font size=2 face="sans-serif">Now think back to the creation of RFC 2445 and you may recall that we discussed what a CUA should do if it gets stuff it does not grok like RRULEs, etc. &nbsp;The answer was that it could (should?) send back a REQUEST-STATUS property that indicated &quot;I do not grok recurrence grammars so my response may not be 100% what you want&quot; (in addition to the CUs &quot;REQUEST-STATUS: 2.0; Ill be there&quot;!)</font>
<br>
<br><font size=2 face="sans-serif">However, if the CUA does not grok EX/RRULEs then it wont ask for them. &nbsp;So this may be somewhat moot. &nbsp;It does however raise the question about the search mechanism/language. &nbsp;Could a CUA use the currently proposed mechanism/language to request &quot;Give me the next 3 entries for UID:12345 after 19991019T142100&quot;?</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 0064F74785256810_=--


From owner-ietf-calendar@imc.org  Wed Oct 20 15:07:28 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19644
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 15:07:27 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id LAA15651
	for ietf-calendar-bks; Wed, 20 Oct 1999 11:27:35 -0700 (PDT)
Received: from home.royer.com. (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id LAA15647
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 11:27:34 -0700 (PDT)
Received: from home.Royer.com by home.royer.com. (SMI-8.6/SMI-SVR4)
	id LAA12453; Wed, 20 Oct 1999 11:30:34 -0700
Message-ID: <380E0A47.EDBD38D7@home.Royer.com>
Date: Wed, 20 Oct 1999 11:30:31 -0700
From: Doug Royer <Doug@home.Royer.com>
Reply-To: ietf-calendar <ietf-calendar@imc.org>
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
CC: IETF CALSCH WG <ietf-calendar@imc.org>
Subject: Re: CHARSET and LANGUAGE
References: <380D0C3A.7DA1B29E@Software.com> <380DC61A.AE8AF4A@ms.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC845ACFD27969397F14FA773"
Sender: owner-ietf-calendar@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.

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

David Madeo wrote:
> 
> >         1) Language of the iCalendar component object.
> >         2) Charset of the iCalendar component object.
> >         3) Language participants of an event are expected to understand.
> >
> > (3) Not covered in RFC2445 at all.
> >     I think this is the point of the comments from the SKi project.
> 
> I'd venture a guess that if the title of an event is in Spanish, that's what
> I'll hear if I attend.  If I had a hard time reading the title,  because I
> didn't recognize the language, then it really doesn't matter if I could find
> out that it was Danish or Japanese.

1) This is a SKi topic - not an addition to CAP.

Not exactly the same point. If you speak 2 languages and understand
the SUMMARY and DESCRIPTION in Spanish. You might invite your Spanish
speaking friends - only to find out that when you show up that the event
is all in French. They are working on tourist information, not the same
issue as an ISP
or enterprise might face.
--------------msC845ACFD27969397F14FA773
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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDIwMTgzMDMyWjAjBgkqhkiG9w0BCQQxFgQUk+egB1cF
eIAuXuz5tKwhkN/2RZkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYBZucfZejFyPMWgaYVDjqBwCwfP4hsR3g8HiVfzP4rp/Eb7v0VljkSO22beg0Bl
ywCezOJNTT1IjgYKRqysS1v+s7OmLIMc6bwQHylqYep/nMMy1UqlEqUDioQqXEeEqs+0x5du
k8I7RbX3+VACfX4BgGlwWvJ5AqhI45UbP9tigA==
--------------msC845ACFD27969397F14FA773--



From owner-ietf-calendar@imc.org  Wed Oct 20 15:07:29 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19641
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 15:07:26 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id LAA15704
	for ietf-calendar-bks; Wed, 20 Oct 1999 11:30:19 -0700 (PDT)
Received: from home.royer.com. (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id LAA15700
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 11:30:18 -0700 (PDT)
Received: from home.Royer.com by home.royer.com. (SMI-8.6/SMI-SVR4)
	id LAA12457; Wed, 20 Oct 1999 11:33:19 -0700
Message-ID: <380E0AEB.302FEA89@home.Royer.com>
Date: Wed, 20 Oct 1999 11:33:15 -0700
From: Doug Royer <Doug@home.Royer.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF CALSCH WG <ietf-calendar@imc.org>
CC: ietf-calendar@imc.org
Subject: Re: New Topic: Export of calendar data and metadata
References: <OF2A4CB9AA.D967D921-ON85256810.004C572A@com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBD7AC98FE0675B02D517EE84"
Sender: owner-ietf-calendar@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.

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

pregen@egenconsulting.com wrote:
> 
> Maybe I'm missing something here, but should it not be the responsibility of
> the client to ensure that there is an export capability.  It seems to me that
> all we need to declare is that an import/export capability be in place.  Maybe
> we say it needs to be, at a minimum, ASCII format.  But, I believe all we need
> to state is the capability must be there and it is handled by the client
> software.

Yes - however we need to make sure that CUA can get ALL of the calendar
information. I can't think of anything they can't get via CAP.

When you move a calendar from ISP-1 to ISP-2, do you keep any, some,
or all of the VCARs? Are UPNs portable? Are VCARs portable? Are
there any other issues?
--------------msBD7AC98FE0675B02D517EE84
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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDIwMTgzMzE3WjAjBgkqhkiG9w0BCQQxFgQUDkMZCrJf
n69GOHWt0p/9HwgdlU0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYCPdxSNaKBGOf3NcBtGKDqMoMCBKAJiuXepYiw9BaswkdxdrnImnM3u5kzibEKu
Vf8BiPvhOSWAyaWSdlcd/CNj4UrSaW17nWUIrVMVlb0I+SJisx6SN5hQD2LqE4SjvIBjSuTJ
CIi3YtAy6hhhrq3YR4m3/rOG335K8z3/4d3dHg==
--------------msBD7AC98FE0675B02D517EE84--



From owner-ietf-calendar@imc.org  Wed Oct 20 17:54:55 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24483
	for <calsch-archive@odin.ietf.org>; Wed, 20 Oct 1999 17:54:54 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id OAA17957
	for ietf-calendar-bks; Wed, 20 Oct 1999 14:14:55 -0700 (PDT)
Received: from mail1.myriad.com (firewall.myriad.com [209.160.31.225])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id OAA17953
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 14:14:53 -0700 (PDT)
Received: from dr.myriad.com by mail1.myriad.com
          via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Oct 1999 21:17:30 UT
Received: from catalina.myriad.com (catalina [208.128.136.17])
	by dr.myriad.com (8.9.2/8.9.2) with ESMTP id PAA04467
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 15:17:29 -0600 (MDT)
Received: from myriad.com (dxdh_42 [10.2.4.42])
	by catalina.myriad.com (8.8.8+Sun/8.8.8) with ESMTP id PAA17328
	for <ietf-calendar@imc.org>; Wed, 20 Oct 1999 15:16:56 -0600 (MDT)
Message-ID: <380E31B8.7AE4067A@myriad.com>
Date: Wed, 20 Oct 1999 15:18:48 -0600
From: Paul Hill <phill@myriad.com>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar <ietf-calendar@imc.org>
Subject: Re: CHARSET and LANGUAGE
References: <380D0C3A.7DA1B29E@Software.com> <380DC61A.AE8AF4A@ms.com> <380DFFA3.42C90ADA@myriad.com>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by dr.myriad.com id PAA04467
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.imc.org id OAA17954
Sender: owner-ietf-calendar@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

Paul Hill wrote:
> Firstly FWIW, language codes are defined in ISO3166. My examples below do
> not use those codes (i.e. ES for Espańol, EN for English).

Oops, too many ISO standards to keep track of!
As John Klensin pointed out to me, ISO-3166 is not the right standard.
So let's make that ISO-639 see, for example, http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt
ISO-3166 is _country_ codes, see
http://userpage.chemie.fu-berlin.de/diverse/doc/ISO_3166.html
which no doubt would be used elsewhere in this standard.

FWIW, that would be es (Spanish) and en (English), which is not to be
confused with country codes GB (United Kingdom) or ES (Spain).

-Paul


From owner-ietf-calendar@imc.org  Thu Oct 21 05:19:48 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12980
	for <calsch-archive@odin.ietf.org>; Thu, 21 Oct 1999 05:19:48 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id BAA22709
	for ietf-calendar-bks; Thu, 21 Oct 1999 01:31:43 -0700 (PDT)
Received: from ljudo.shortlist.se (ljudo.shortlist.se [193.14.119.253])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA22702
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 01:31:41 -0700 (PDT)
Received: from joyce (unknown [193.14.119.216])
	by ljudo.shortlist.se (Postfix) with SMTP
	id 18D165F9B; Thu, 21 Oct 1999 10:32:05 +0200 (CEST)
From: "Greg FitzPatrick" <gf@medianet.org>
To: "Paul Hill" <phill@myriad.com>, "ietf-calendar" <ietf-calendar@imc.org>
Subject: RE: CHARSET and LANGUAGE
Date: Thu, 21 Oct 1999 10:38:44 +0200
Keywords: SKI
Message-ID: <002001bf1b9f$af7391c0$d8770ec1@joyce.musiknet>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <380DFFA3.42C90ADA@myriad.com>
Sender: owner-ietf-calendar@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

Great summary

We try to keep things simple by delegating interpreting, text rolls, printed
translations etc., to the RESOURCE property.

And use LANGUAGE as the declaration of the main language(s) utilized.  When
it comes down to it, 99% of events will be tagged (or defaulted) to one
language.


ex.

I attend twice a year EU meetings in one working group where we speak
Danish, Swedish and English.  To be honest, we would confine ourselves to
English if any one was to join us with out Scandinavian language skills, but
nevertheless  we would tag this as:

LANGUAGE: Swedish, English, Danish
(no charset implied in this example:-))

If this meeting was dignified enough to merit interpreters, we would tag
them as:

RESOURCE;Interpretation: German, French

and if printed translations of material presented were available we would
tag them as:

RESOURCE; "German, French translations of the marketing plan"



...and of course there is no way you can guarantee that the language of the
summary reflects the main language(s) of the event.
Who ever thinks that has never been to a large European conference.

Greg

> -----Original Message-----
> From: owner-ietf-calendar@imc.org [mailto:owner-ietf-calendar@imc.org]On
> Behalf Of Paul Hill
> Sent: den 20 oktober 1999 19:45
> To: ietf-calendar
> Subject: Re: CHARSET and LANGUAGE
>
>
> I have been a lurking on the ietf-calendar list for awhile,
> mostly because I don't
> at this time deal with programming event/scheduling/calendar
> issues, but I thought
> I'd jump in with a few comments on language.
>
> Firstly FWIW, language codes are defined in ISO3166. My examples below do
> not use those codes (i.e. ES for Espańol, EN for English).
>
> David Madeo wrote:
> > Having said that, there are lots of cases where even if you
> don't understand
> > the spoken language, you can get by with alternate means.
> >[...]
> > So I'd agree this is important and useful.
>
> Okay, so let me offer the following list of possible scenerios
> and those writing
> the standard can work out how the standard covers or does not
> cover these examples.
>
> 1. A river trip in the wilds of Idaho where the language is English.
>
> #1 is simple enough.
>
> 2. A ski week in Switzerland with guides availage in French,
> English, German etc.
>
> The difference between 1 and 2 is that #2 includes many languages.
>
> 3. An Opera in Italian with supertitles in English (?, around
> here they project them on a little
> strip _above_ the stage or hanging from the balcony etc.)
>
> #3 has a single secondary language, but #2 has many primary languages
>
> 4. An Opera in Italian with Spanish, French, English available
> through a 'little
> digital display'
>
> #4 points out the need for a list of secondary languages and
> hints at a 'delivery
> method' attribute.
>
> 5. An international conference where the Calendar entries have
> all been transalated
> into various languages, so forget about guessing from the title (because
> a particular calendar received a particular transalation), but
> the user would want to
> know that the speaker is giving the talk in Catalan, but there
> will be a simultaneous
> French and Spanish translation. This would be different than the
> proceeding of the
> conference being published in French, English, Spanish and German
> (I assume the
> languages of the proceedings are outside of this standard, but
> maybe not, see
> next example)
>
> #5 shows that the language of the calendar entry is no indication of what
> will happening with the primary and any secondary languages of the event.
> There is a real DIT/DOT distinction (see discussion from last week)
> going on here.
>
> 6. A board meeting of an American cooperation in L.A. where the
> presentation are
> in English only, but printed versions of the talks are available
> in Japanese.
>
> Hopefully, #6 is nearly the same as #3, with only the possible description
> of the form of the secondary language.
>
> (I'll leave out the scenerio of #5 that include "a presentation
> from Latin American division
> President in Spanish". That could get us into an example of two
> primary languages
> and one secondary)
>
> The multi-lingual conference and the vacation week with multiple
> languages available,
> both seem like real, but complex enough possibilities that would
> be good to
> cover.
>
> -Paul
>



From owner-ietf-calendar@imc.org  Thu Oct 21 12:42:10 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04491
	for <calsch-archive@odin.ietf.org>; Thu, 21 Oct 1999 12:42:09 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id IAA03569
	for ietf-calendar-bks; Thu, 21 Oct 1999 08:37:20 -0700 (PDT)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA03565
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 08:37:19 -0700 (PDT)
Received: from PTROUTE.dfpt.extest.microsoft.com (PTROUTE [172.30.236.83]) by doggate.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
	id 42Y60N3A; Thu, 21 Oct 1999 08:39:31 -0700
Received: from PTPUP.dfpt.extest.microsoft.com ([172.30.236.191]) by PTROUTE.dfpt.extest.microsoft.com with Microsoft SMTPSVC(5.0.2151.1);
	 Thu, 21 Oct 1999 08:41:01 -0700
content-class: urn:content-classes:message
From: "Lisa Lippert \(Dusseault\) \(Platinum\)" <lisal@microsoft.com>
To: "John Stracke" <francis@ecal.com>, "calsch WG" <ietf-calendar@imc.org>
Subject: RE: queries for unbounded recurring components
Date: Thu, 21 Oct 1999 08:40:56 -0700
Message-ID: <D301B2FFCEB90140AF181C6EBBF12E06033535@PTPUP.dfpt.extest.microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_3305_01BF1BA0.00B54420"
Thread-Topic: queries for unbounded recurring components
Thread-Index: Ab8boZzMmrsfnjAvSaSpOTznTNTrRAAN5c+w
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600
X-OriginalArrivalTime: 21 Oct 1999 15:41:01.0312 (UTC) FILETIME=[AD3FC000:01BF1BDA]
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_3305_01BF1BA0.00B54420
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Generally I agree with John's principle to push things to the edges, but
I'm not so sure on this one.  The problem is that to do a simple query
such as "what appointments do I have today?", the client has to either
rely on the server to do expansion, OR the client has to download all
appointments today, plus all appointments that recur.  That becomes
expensive once again in terms of bandwidth. And it may in fact be just
about as easy for the server to do the recurrence expansion than to
stream all those recurring items.

It may be reasonable to limit the amount of expansion the server has to
do, though.  It could be interesting to allow the client to request
recurrance expansion for a range of dates, and for the server to be able
to respond "no".  (Then the client just has to download the recurring
items).  That flexibility on the server allows it to tune for the best
performance, both CPU and on the wire.

Lisa

-----Original Message-----
From: owner-ietf-calendar@imc.org [mailto:owner-ietf-calendar@imc.org]On
Behalf Of John Stracke
Sent: Wednesday, October 20, 1999 9:09 AM
To: calsch WG
Subject: Re: queries for unbounded recurring components


Steve Mansour wrote:

> Hmmm... I think it's more involved than that.  Are you
> suggesting that all clients/requesters should know how to
> expand the RRULE?  A light-weight client app may want all the
> instances of a recurring event.

Yes, but we have to think about bandwidth issues--especially
since one of the important places for thin clients is in non-PC
devices in the home, where you probably have 56k or less.

I would prefer to see a protocol where the server is never
required to do the expansion itself.  CPU time is so much cheaper
than bandwidth that it's unreasonable for the clients not to take
on the load.  (For that matter, why should the overworked server
CPU take on that work for its thousands of clients? Push the hard
parts to the edges; that's what makes the Internet run.)

--
/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
|eCal Corp.      |Help stamp out vi in our lifetime!           |
|francis@ecal.com|                                             |
\=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/


------=_NextPart_000_3305_01BF1BA0.00B54420
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4118.0">
<TITLE>RE: queries for unbounded recurring components</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Generally I agree with John's principle to push things =
to the edges, but I'm not so sure on this one.&nbsp; The problem is that =
to do a simple query such as &quot;what appointments do I have =
today?&quot;, the client has to either rely on the server to do =
expansion, OR the client has to download all appointments today, plus =
all appointments that recur.&nbsp; That becomes expensive once again in =
terms of bandwidth. And it may in fact be just about as easy for the =
server to do the recurrence expansion than to stream all those recurring =
items.</FONT></P>

<P><FONT SIZE=3D2>It may be reasonable to limit the amount of expansion =
the server has to do, though.&nbsp; It could be interesting to allow the =
client to request recurrance expansion for a range of dates, and for the =
server to be able to respond &quot;no&quot;.&nbsp; (Then the client just =
has to download the recurring items).&nbsp; That flexibility on the =
server allows it to tune for the best performance, both CPU and on the =
wire.</FONT></P>

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

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

<BR><FONT SIZE=3D2>From: owner-ietf-calendar@imc.org [<A =
HREF=3D"mailto:owner-ietf-calendar@imc.org">mailto:owner-ietf-calendar@im=
c.org</A>]On</FONT>

<BR><FONT SIZE=3D2>Behalf Of John Stracke</FONT>

<BR><FONT SIZE=3D2>Sent: Wednesday, October 20, 1999 9:09 AM</FONT>

<BR><FONT SIZE=3D2>To: calsch WG</FONT>

<BR><FONT SIZE=3D2>Subject: Re: queries for unbounded recurring =
components</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Steve Mansour wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hmmm... I think it's more involved than =
that.&nbsp; Are you</FONT>

<BR><FONT SIZE=3D2>&gt; suggesting that all clients/requesters should =
know how to</FONT>

<BR><FONT SIZE=3D2>&gt; expand the RRULE?&nbsp; A light-weight client =
app may want all the</FONT>

<BR><FONT SIZE=3D2>&gt; instances of a recurring event.</FONT>
</P>

<P><FONT SIZE=3D2>Yes, but we have to think about bandwidth =
issues--especially</FONT>

<BR><FONT SIZE=3D2>since one of the important places for thin clients is =
in non-PC</FONT>

<BR><FONT SIZE=3D2>devices in the home, where you probably have 56k or =
less.</FONT>
</P>

<P><FONT SIZE=3D2>I would prefer to see a protocol where the server is =
never</FONT>

<BR><FONT SIZE=3D2>required to do the expansion itself.&nbsp; CPU time =
is so much cheaper</FONT>

<BR><FONT SIZE=3D2>than bandwidth that it's unreasonable for the clients =
not to take</FONT>

<BR><FONT SIZE=3D2>on the load.&nbsp; (For that matter, why should the =
overworked server</FONT>

<BR><FONT SIZE=3D2>CPU take on that work for its thousands of clients? =
Push the hard</FONT>

<BR><FONT SIZE=3D2>parts to the edges; that's what makes the Internet =
run.)</FONT>
</P>

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

<BR><FONT =
SIZE=3D2>/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\</FONT>

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

<BR><FONT SIZE=3D2>|Chief Scientist =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|</FONT>

<BR><FONT SIZE=3D2>|eCal Corp.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |Help stamp =
out vi in our =
lifetime!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>

<BR><FONT =
SIZE=3D2>|francis@ecal.com|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&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;&nbsp;&nbsp; =
|</FONT>

<BR><FONT =
SIZE=3D2>\=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_3305_01BF1BA0.00B54420--


From owner-ietf-calendar@imc.org  Thu Oct 21 15:10:22 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11283
	for <calsch-archive@odin.ietf.org>; Thu, 21 Oct 1999 15:10:21 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id LAA07014
	for ietf-calendar-bks; Thu, 21 Oct 1999 11:26:39 -0700 (PDT)
Received: from brrr.windchill.com (mail.windchill.com [209.98.24.3])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id LAA06992
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 11:26:37 -0700 (PDT)
Received: from barney.windchill.com (barney.mn.ptc.com [132.253.8.9])
	by brrr.windchill.com (8.9.3/8.9.3) with ESMTP id NAA15666
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 13:30:51 -0500
Received: from windchill.com ([132.253.8.44]) by barney.windchill.com
          (Netscape Messaging Server 3.5)  with ESMTP id AAAABF
          for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 13:29:16 -0500
Message-ID: <380F5B7C.B5F5F4E6@windchill.com>
Date: Thu, 21 Oct 1999 13:29:16 -0500
From: "Neelima Kalidindi" <nkalidindi@windchill.com>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Looking for client APIs to access calendar information
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

Hi All,
      I'm doing a research on the availability of client APIs that can
      access calendar information (using the iCal/vCal standard
notations).
      Specifically, I'm looking for APIs that can query if a certain
user or
      group of users is free at a given time or time range. I'd really
      appreciate it if someone could give me any help in this regard
even if
      it
      means direction to some source where I might find such
information.

Thanks
Neelima.



From owner-ietf-calendar@imc.org  Thu Oct 21 17:10:38 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14266
	for <calsch-archive@odin.ietf.org>; Thu, 21 Oct 1999 17:10:34 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id NAA08665
	for ietf-calendar-bks; Thu, 21 Oct 1999 13:20:11 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id NAA08660
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 13:20:09 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar <ietf-calendar@imc.org>
Subject: Visiting Santa Cruz
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OFF6F04236.7131CCD9-ON85256811.006FD4AB@com>
Date: Thu, 21 Oct 1999 16:22:47 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 10/21/99 04:22:49 PM,
	Serialize complete at 10/21/99 04:22:49 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006FFB9F85256811_="
Sender: owner-ietf-calendar@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 006FFB9F85256811_=
Content-Type: text/plain; charset="us-ascii"

Hey, my hubby and I are going to be out in Santa Cruz on 11/10 through 
11/14 (actually flying out sometime on the 14th to Calgary).  I thought it 
might be nice to introduce you to him and to meet somehow for dinner or 
something.  What do you think? Let me know if that's possible.  Take care.
--=_alternative 006FFB9F85256811_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">Hey, my hubby and I are going to be out in Santa Cruz on 11/10 through 11/14 (actually flying out sometime on the 14th to Calgary). &nbsp;I thought it might be nice to introduce you to him and to meet somehow for dinner or something. &nbsp;What do you think? Let me know if that's possible. &nbsp;Take care.</font>
--=_alternative 006FFB9F85256811_=--


From owner-ietf-calendar@imc.org  Thu Oct 21 21:12:28 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16893
	for <calsch-archive@odin.ietf.org>; Thu, 21 Oct 1999 21:12:27 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id RAA12027
	for ietf-calendar-bks; Thu, 21 Oct 1999 17:33:31 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA12022
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 17:33:30 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id UAA14459
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 20:48:52 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id UAA03985
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 20:34:23 -0400 (EDT)
To: ietf-calendar@imc.org
Subject: Re: CHARSET and LANGUAGE
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF6FD5CC80.FE003F8A-ON85256811.006A1D96@Lotus.com>
Date: Thu, 21 Oct 1999 20:47:56 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/21/99 08:48:18 PM,
	Serialize complete at 10/21/99 08:48:18 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006A5ABA85256811_="
Sender: owner-ietf-calendar@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 006A5ABA85256811_=
Content-Type: text/plain; charset="us-ascii"

Doug:
Per iCalendar, you can only set CHARSET at the content-type header level, 
not at the calendar component level. This was removed from vCalendar, as 
it was massaged into iCalendar. Repeatedly, I have received requests from 
pacific rim reviewers of iCalendar for this function. But, I believe that 
the IESG philosophy is to set the character set at the MIME entity level, 
not within the the MIME entity.
-- Frank

--=_alternative 006A5ABA85256811_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Doug:</font>
<p><font size=3 face="Courier New">Per iCalendar, you can only set CHARSET at the content-type header level, not at the calendar component level. This was removed from vCalendar, as it was massaged into iCalendar. Repeatedly, I have received requests from pacific rim reviewers of iCalendar for this function. But, I believe that the IESG philosophy is to set the character set at the MIME entity level, not within the the MIME entity.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 006A5ABA85256811_=--


From owner-ietf-calendar@imc.org  Thu Oct 21 21:12:47 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16909
	for <calsch-archive@odin.ietf.org>; Thu, 21 Oct 1999 21:12:47 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id RAA12023
	for ietf-calendar-bks; Thu, 21 Oct 1999 17:33:30 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA12016
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 17:33:29 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id UAA14453;
	Thu, 21 Oct 1999 20:48:51 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id UAA03982;
	Thu, 21 Oct 1999 20:34:22 -0400 (EDT)
To: Paul Hill <phill@myriad.com>
Cc: ietf-calendar@imc.org
Subject: Re: CHARSET and LANGUAGE
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF19B18555.7100F5F2-ON85256811.00697DF1@Lotus.com>
Date: Thu, 21 Oct 1999 20:47:55 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/21/99 08:48:17 PM,
	Serialize complete at 10/21/99 08:48:17 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0069E2CB85256811_="
Sender: owner-ietf-calendar@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 0069E2CB85256811_=
Content-Type: text/plain; charset="us-ascii"

Paul Hill wrote, in part:
>The multi-lingual conference and the vacation week with multiple 
languages available,
>both seem like real, but complex enough possibilities that would be good 
to
>cover.

We aren't using ISO standards, we are using the RFC 1766, "Tags for 
Identification of Languages" for specification of languages in iCalendar 
and now CAP. Just to be clear.
Second clarification. Multi-lingual descriptions of SUMMARY and 
DESCRIPTION properties are specified by specifying multiple instances of 
the property, each one with a different LANGUAGE parameter.
-- Frank

--=_alternative 0069E2CB85256811_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Paul Hill wrote, in part:</font>
<p><font size=2 face="Courier New">&gt;The multi-lingual conference and the vacation week with multiple languages available,<br>
&gt;both seem like real, but complex enough possibilities that would be good to<br>
&gt;cover.</font>
<br>
<br><font size=3 face="Courier New">We aren't using ISO standards, we are using the RFC 1766, &quot;Tags for Identification of Languages&quot; for specification of languages in iCalendar and now CAP. Just to be clear.</font>
<p><font size=3 face="Courier New">Second clarification. Multi-lingual descriptions of SUMMARY and DESCRIPTION properties are specified by specifying multiple instances of the property, each one with a different LANGUAGE parameter.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 0069E2CB85256811_=--


From owner-ietf-calendar@imc.org  Thu Oct 21 21:18:32 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16950
	for <calsch-archive@odin.ietf.org>; Thu, 21 Oct 1999 21:18:31 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id RAA12018
	for ietf-calendar-bks; Thu, 21 Oct 1999 17:33:29 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id RAA12011
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 17:33:28 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id UAA14447;
	Thu, 21 Oct 1999 20:48:49 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id UAA03976;
	Thu, 21 Oct 1999 20:34:21 -0400 (EDT)
To: dmadeo@ms.com
Cc: Doug.Royer@software.com, ietf-calendar@imc.org, pregen@egenconsulting.com
Subject: Re: New Topic: Export of calendar data and metadata
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF1B785FB6.4A19B634-ON85256811.0068435B@Lotus.com>
Date: Thu, 21 Oct 1999 20:47:53 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/21/99 08:48:15 PM,
	Serialize complete at 10/21/99 08:48:15 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0068618385256811_="
Sender: owner-ietf-calendar@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 0068618385256811_=
Content-Type: text/plain; charset="us-ascii"

You all have been talking "Import/Export". This is a client capability. 
Don't you mean "Archive/Restore", a server capability?
In either case, I was fairly certain that we deferred this from the 
original requirements for CAP. No?
-- Frank

--=_alternative 0068618385256811_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">You all have been talking &quot;Import/Export&quot;. This is a client capability. Don't you mean &quot;Archive/Restore&quot;, a server capability?</font>
<p><font size=3 face="Courier New">In either case, I was fairly certain that we deferred this from the original requirements for CAP. No?</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 0068618385256811_=--


From owner-ietf-calendar@imc.org  Thu Oct 21 22:23:16 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18447
	for <calsch-archive@odin.ietf.org>; Thu, 21 Oct 1999 22:23:15 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id SAA18084
	for ietf-calendar-bks; Thu, 21 Oct 1999 18:45:46 -0700 (PDT)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA18078
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 18:45:44 -0700 (PDT)
From: pregen@egenconsulting.com
To: ietf-calendar@imc.org
Subject: Apologies
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF223A9A92.F1D5F4AC-ON85256812.0009D606@com>
Date: Thu, 21 Oct 1999 21:48:30 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 10/21/99 09:48:26 PM,
	Serialize complete at 10/21/99 09:48:26 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0009F7AC85256812_="
Sender: owner-ietf-calendar@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 0009F7AC85256812_=
Content-Type: text/plain; charset="us-ascii"

By the way, I sent a note responding to someone, and inadvertently sent it 
to the entire list.  my apologies....(she says, sheepishly.. 8-) .....  )
--=_alternative 0009F7AC85256812_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">By the way, I sent a note responding to someone, and inadvertently sent it to the entire list. &nbsp;my apologies....(she says, sheepishly.. 8-) ..... &nbsp;)</font>
--=_alternative 0009F7AC85256812_=--


From owner-ietf-calendar@imc.org  Fri Oct 22 03:27:17 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03500
	for <calsch-archive@odin.ietf.org>; Fri, 22 Oct 1999 03:27:17 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id XAA01427
	for ietf-calendar-bks; Thu, 21 Oct 1999 23:53:21 -0700 (PDT)
Received: from home.royer.com. (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id XAA01423
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 23:53:20 -0700 (PDT)
Received: from home.royer.com by home.royer.com. (SMI-8.6/SMI-SVR4)
	id XAA20960; Thu, 21 Oct 1999 23:56:29 -0700
Message-ID: <38100A9A.84AFD1C4@home.royer.com>
Date: Thu, 21 Oct 1999 23:56:26 -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: IETF CALSCH WG <ietf-calendar@imc.org>
Subject: Re: New Topic: Export of calendar data and metadata
References: <OF1B785FB6.4A19B634-ON85256811.0068435B@Lotus.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCF34F0914B15B84C5494E218"
Sender: owner-ietf-calendar@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.

--------------msCF34F0914B15B84C5494E218
Content-Type: multipart/mixed;
 boundary="------------5670CDB3FB4E902268612EEA"

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

Frank_Dawson@lotus.com wrote:
> 
> You all have been talking "Import/Export". This is a client capability. Don't
> you mean "Archive/Restore", a server capability?

No.

> In either case, I was fairly certain that we deferred this from the original
> requirements for CAP. No?

Yes - We did defer Archive/Restore.

We also said we must provide the ability to synchronize two calendars.
We would not specify how, just that it must be possible to pull
the contents out of a calendar and put it back possibly modified.

To do that the CUA must be able to get the entire calendar
and put an entire calendar. 

-Doug
--------------5670CDB3FB4E902268612EEA
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

--------------5670CDB3FB4E902268612EEA--

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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDIyMDY1NjI3WjAjBgkqhkiG9w0BCQQxFgQUFnCXHgAu
HIrU67g7ttuHW+yggOAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYAbBOqGfZ9KGUknZJEylRiWpjOGw5xM76ogU8bGhNqP9xXniaB2wMjHPjvHAo04
XTFIkCoUf1IXcoy1CM/kaJ3+4zDet2SSsDhdCOliIzDFNfRr50E1rlMQEktY1aShHC/828qt
jmY5vrPbe1SmthlFZKo/ujz5msI6nJS+ZC8aCw==
--------------msCF34F0914B15B84C5494E218--



From owner-ietf-calendar@imc.org  Fri Oct 22 03:29:12 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03515
	for <calsch-archive@odin.ietf.org>; Fri, 22 Oct 1999 03:29:12 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id XAA01293
	for ietf-calendar-bks; Thu, 21 Oct 1999 23:50:20 -0700 (PDT)
Received: from home.royer.com. (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id XAA01289
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 23:50:19 -0700 (PDT)
Received: from home.royer.com by home.royer.com. (SMI-8.6/SMI-SVR4)
	id XAA20957; Thu, 21 Oct 1999 23:53:25 -0700
Message-ID: <381009D5.2DDF7737@home.royer.com>
Date: Thu, 21 Oct 1999 23:53:09 -0700
From: Doug Royer <doug@home.royer.com>
Reply-To: IETF CALSCH WG <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: ietf-calendar@imc.org
Subject: Re: CHARSET and LANGUAGE
References: <OF19B18555.7100F5F2-ON85256811.00697DF1@Lotus.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF014B554013D726930E3DB65"
Sender: owner-ietf-calendar@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.

--------------msF014B554013D726930E3DB65
Content-Type: multipart/mixed;
 boundary="------------0F1B024E3D8FF924804AD65F"

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

Frank_Dawson@lotus.com wrote:
> 
> Paul Hill wrote, in part:
> 
> >The multi-lingual conference and the vacation week with multiple languages
> available,
> >both seem like real, but complex enough possibilities that would be good to
> >cover.
> 
> We aren't using ISO standards, we are using the RFC 1766, "Tags for
> Identification of Languages" for specification of languages in iCalendar and
> now CAP. Just to be clear.
> 
> Second clarification. Multi-lingual descriptions of SUMMARY and DESCRIPTION
> properties are specified by specifying multiple instances of the property,
> each one with a different LANGUAGE parameter.

Yes. But that still does not tell the attendees what languange will
be spoken at the event - One item in the SKi proposal.
--------------0F1B024E3D8FF924804AD65F
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

--------------0F1B024E3D8FF924804AD65F--

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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDIyMDY1MzIzWjAjBgkqhkiG9w0BCQQxFgQUb/YBiQH2
RhQqEbcKXXgmVmFH65YwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYCRXOO7393WGvREgMq5rwm8XGtGj9tmHmkxgZaUT5BEh8I3oLTqf1O3NPzjVqpv
FFTEt2eOXkNQsF+7mUZtCTRkJbauhHg12N/h/NWz17fu3sAyOhxuz7Xo21mtWkREMVM8wfZi
KgeA3yEVuXQxRnYLPzshXPeeX/heGX/asSKYxA==
--------------msF014B554013D726930E3DB65--



From owner-ietf-calendar@imc.org  Fri Oct 22 03:29:45 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03526
	for <calsch-archive@odin.ietf.org>; Fri, 22 Oct 1999 03:29:43 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id XAA01276
	for ietf-calendar-bks; Thu, 21 Oct 1999 23:48:21 -0700 (PDT)
Received: from home.royer.com. (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id XAA01272
	for <ietf-calendar@imc.org>; Thu, 21 Oct 1999 23:48:19 -0700 (PDT)
Received: from home.royer.com by home.royer.com. (SMI-8.6/SMI-SVR4)
	id XAA20954; Thu, 21 Oct 1999 23:51:28 -0700
Message-ID: <38100969.A5E12A67@home.royer.com>
Date: Thu, 21 Oct 1999 23:51:21 -0700
From: Doug Royer <doug@home.royer.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF CALSCH WG <ietf-calendar@imc.org>
CC: ietf-calendar@imc.org
Subject: Re: CHARSET and LANGUAGE
References: <OF6FD5CC80.FE003F8A-ON85256811.006A1D96@Lotus.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1EEE03AC4B08FCA277DBA742"
Sender: owner-ietf-calendar@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.

--------------ms1EEE03AC4B08FCA277DBA742
Content-Type: multipart/mixed;
 boundary="------------E728B89A75B8BB3F6C9A34FC"

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

Frank_Dawson@lotus.com wrote:
>
> Per iCalendar, you can only set CHARSET at the content-type header level, not
> at the calendar component level. This was removed from vCalendar, as it was
> massaged into iCalendar. Repeatedly, I have received requests from pacific rim
> reviewers of iCalendar for this function. But, I believe that the IESG
> philosophy is to set the character set at the MIME entity level, not within
> the the MIME entity.

I have not proposed any thing like this, and I have not seen anyone
else propose putting it into the MIME entity.

-Doug
--------------E728B89A75B8BB3F6C9A34FC
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

--------------E728B89A75B8BB3F6C9A34FC--

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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDIyMDY1MTIyWjAjBgkqhkiG9w0BCQQxFgQU04kWLmhj
p55B5s1mkLIDoJSJ+UEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYBHOg4LHAEVWJKrBygS1l4S2BrXTfoCSKtiLfuSeTi1jg1gVVH41kCT1CYFNFht
0O6sFL5l6uioyxRC7LDHgFf6L//t7+NhcnKtUrxGuMfF9YBf0I1UMFvREtJSJWUahobH7/I8
4TuniKANXf8OOzLKmG9QZrtDBlg+LdOLaiFmbQ==
--------------ms1EEE03AC4B08FCA277DBA742--



From owner-ietf-calendar@imc.org  Fri Oct 22 05:00:13 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04262
	for <calsch-archive@odin.ietf.org>; Fri, 22 Oct 1999 05:00:13 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id BAA03590
	for ietf-calendar-bks; Fri, 22 Oct 1999 01:18:59 -0700 (PDT)
Received: from ljudo.shortlist.se (ljudo.shortlist.se [193.14.119.253])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id BAA03585
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 01:18:57 -0700 (PDT)
Received: from joyce (unknown [193.14.119.216])
	by ljudo.shortlist.se (Postfix) with SMTP id AEEAA5F9B
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 10:19:26 +0200 (CEST)
From: "Greg FitzPatrick" <gf@medianet.org>
To: "IETF CALSCH WG" <ietf-calendar@imc.org>
Subject: RE: CHARSET and LANGUAGE
Date: Fri, 22 Oct 1999 10:26:09 +0200
Message-ID: <002e01bf1c67$17f1e040$d8770ec1@joyce.musiknet>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <381009D5.2DDF7737@home.royer.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-calendar@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




Thank you Doug, that is just what I am asking.

Are there no  "silent travelers" on this list? People who do not live in an
environment where English is the only language on earth, except when eating
in foreign food restaurants?
Please make yourself heard:-)


Föresten, hur mĺnga nordbor är med pĺ denna lista?  Kan ni inte maila mig
privat sĺ att jag vet hur mĺnga ni är?

Greg


Doug Royer wrote:
> Yes. But that still does not tell the attendees what languange will
> be spoken at the event - One item in the SKi proposal.



From owner-ietf-calendar@imc.org  Fri Oct 22 08:53:21 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10599
	for <calsch-archive@odin.ietf.org>; Fri, 22 Oct 1999 08:53:20 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id FAA29103
	for ietf-calendar-bks; Fri, 22 Oct 1999 05:27:05 -0700 (PDT)
Received: from hqinbh1.ms.com (hqinbh1-e1.ms.com [205.228.12.65] (may be forged))
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id FAA29098
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 05:27:04 -0700 (PDT)
Received: (from uucp@localhost)
        by hqinbh1.ms.com (8.8.6/fw v1.30) id IAA17705
        for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 08:29:42 -0400 (EDT)
Received: from unknown(144.14.193.5) by hqinbh1 via smap (4.1)
	id xma017466; Fri, 22 Oct 99 08:29:22 -0400
Received: from ms.com (hqdsl26.morgan.com [205.228.1.26])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.3) with ESMTP id IAA00548
        for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 08:29:22 -0400 (EDT)
Message-ID: <381058A2.CE9CBF1A@ms.com>
Date: Fri, 22 Oct 1999 08:29:22 -0400
From: David Madeo <dmadeo@ms.com>
Reply-To: dmadeo@ms.com
Organization: Morgan Stanley Dean Witter & Co.
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: New Topic: Export of calendar data and metadata
References: <OF1B785FB6.4A19B634-ON85256811.0068435B@Lotus.com> <38100A9A.84AFD1C4@home.royer.com>
Content-Type: multipart/mixed;
 boundary="------------8D8727205BBA38ADEC8765F1"
Sender: owner-ietf-calendar@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.
--------------8D8727205BBA38ADEC8765F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Doug Royer wrote:

> Frank_Dawson@lotus.com wrote:
> >
> > You all have been talking "Import/Export". This is a client capability. Don't
> > you mean "Archive/Restore", a server capability?
>
> No.

I'm never going to expect two implementations to handle Archive/Restore the same
way.  There are too many implementation details to get right.  How do you handle
locking the database down while you restore, etc. It's also probably more focused
on the Calendar Store, rather than individual calendars.

I do want CAP to explicitly explain how a CUA would extract the entire contents of
a calendar (calendar data and meta data) out.  Whether this is an EXPORT command
which hasn't been thought about yet, or (as I suspect), a set of queries which will
define the entire set of contents, I'll leave this to better and brighter minds
than my own.

If we define what we expect in CAP, everyone will do it in the same way which has
huge benefits for all.   Implementors will have customers easily switching around
to the best implementation.  Customers will have no barriers to picking the best
vendors.  Your super-PDA will chortle happily while synchronizing with the server.

If we don't, then people like me will be explaining to people who don't want to
hear about it why they won't have the ACL's (or whatever) they spent so much time
getting right,  after we switch them to the new product we've picked.

Rather than going back and forth over what to call this, can I ask that one of the
authors take a stab at describing what they think would provide the simplest/most
complete way of extracting a complete set of calendar and meta data?  I'd do this
myself, but I'm in the middle of deploying a new version of a calendar product
within my firm.

dmadeo


--------------8D8727205BBA38ADEC8765F1
Content-Type: text/x-vcard; charset=us-ascii;
 name="dmadeo.vcf"
Content-Description: Card for David Madeo
Content-Disposition: attachment;
 filename="dmadeo.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Madeo;David
tel;fax:212-762-1009
tel;work:212-762-2348
x-mozilla-html:FALSE
url:www.ms.com
org:Morgan Stanley Dean Witter and Discover;Information Technology
version:2.1
email;internet:dmadeo@ms.com
adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA
x-mozilla-cpt:;0
fn:David Madeo
end:vcard

--------------8D8727205BBA38ADEC8765F1--



From owner-ietf-calendar@imc.org  Fri Oct 22 11:42:35 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19757
	for <calsch-archive@odin.ietf.org>; Fri, 22 Oct 1999 11:42:34 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id HAA10305
	for ietf-calendar-bks; Fri, 22 Oct 1999 07:57:52 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.iris.com [198.112.211.23])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id HAA10297
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 07:57:47 -0700 (PDT)
From: Bruce_Kahn@iris.com
X-Notes-Item: 330B3F31:7D30B99A-85256812:00523457;
 type=4; name=$Orig
X-Notes-Item: Reply;
 name=Form
X-Notes-Item: .,
	.;
 type=501; name=$StorageTo
X-Notes-Item: Bruce_Kahn@iris.com;
 flags=44; name=InheritedFrom
X-Notes-Item: owner-ietf-calendar@imc.org;
 flags=44; name=InheritedAltFrom
X-Notes-Item: CN=Bruce Kahn/O=Iris;
 name=AltFrom
X-Notes-Item: stdNotesLtr0;
 name=Logo
X-Notes-Item: 0;
 name=Sign
X-Notes-Item: 0;
 name=Encrypt
X-Notes-Item: 0;
 name=DefaultMailSaveOptions
To: ietf-calendar@imc.org, sman@netscape.com (Steve Mansour)
Subject: Re: queries for unbounded recurring components
X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999
Message-ID: <OF330B3F31.7D30B99A-ON85256812.00523457@iris.com>
Date: Fri, 22 Oct 1999 11:02:04 -0400
X-Notes-Item: CN=Clapton/O=Iris,
	CN=Mountain/O=Iris;
 type=501; flags=0; name=RouteServers
X-Notes-Item: 22-Oct-1999 11:00:27 EDT/22-Oct-1999 11:00:29 EDT, 22-Oct-1999 11:01:13 EDT/22-Oct-1999 11:01:14 EDT;
 type=401; flags=0; name=RouteTimes
X-Notes-Item: CN=Clapton/O=Iris,
	CN=Mountain/O=Iris,
	CN=Capricorn/O=Iris;
 type=501; flags=44; name=$UpdatedBy
X-Notes-Item: 22-Oct-1999 11:00:31 EDT;
 type=401; name=$Revisions
X-Notes-Item: 0;
 name=$MsgTrackFlags
X-Notes-Item: IRIS@iris.com;
 name=FromDomain
X-Notes-Item: 23;
 type=300; name=$Hops
X-Notes-Item: CN=Bruce Kahn/O=Iris;
 name=OriginalFrom
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V502_10191999 |October 19, 1999) at 10/22/99 11:01:02 AM,
	Serialize complete at 10/22/99 11:01:02 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00530D7785256812_="
Sender: owner-ietf-calendar@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 00530D7785256812_=
Content-Type: text/plain; charset="us-ascii"

I wrote:
>Since the request also neglects to ask for the RRULEs, EXRULEs, RDATEs 
>and EXDATEs that may be there, the requestor obviously does not want to 
know
>about the recurrence set or info. 

<CLARIFICATION>
Actually I was a bit ahead of myself.  I assumed (perhaps incorrectly) the 
client did not request the RRULE, RDATE, EXRULE, EXDATE info to be 
returned.  This may or may not have been the case but since Steve was 
asking about unwinding I assumed that the client had not.  Just wanted to 
clarify this before I got a firestorm of emails back...
</CLARIFICATION>

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




<br><font size=2 face="sans-serif">I wrote:</font>
<br><font size=2 face="sans-serif">&gt;Since the request also neglects to ask for the RRULEs, EXRULEs, RDATEs </font>
<br><font size=2 face="sans-serif">&gt;and EXDATEs that may be there, the requestor obviously does not want to know</font>
<br><font size=2 face="sans-serif">&gt;about the recurrence set or info.</font><font size=3 face="Times New Roman"> </font>
<br>
<br><font size=2 face="sans-serif">&lt;CLARIFICATION&gt;</font>
<br><font size=2 face="sans-serif">Actually I was a bit ahead of myself. &nbsp;I assumed (perhaps incorrectly) the client did not request the RRULE, RDATE, EXRULE, EXDATE info to be returned. &nbsp;This may or may not have been the case but since Steve was asking about unwinding I assumed that the client had not. &nbsp;Just wanted to clarify this before I got a firestorm of emails back...</font>
<br><font size=2 face="sans-serif">&lt;/CLARIFICATION&gt;</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 00530D7785256812_=--


From owner-ietf-calendar@imc.org  Fri Oct 22 12:44:51 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23275
	for <calsch-archive@odin.ietf.org>; Fri, 22 Oct 1999 12:44:50 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id JAA15013
	for ietf-calendar-bks; Fri, 22 Oct 1999 09:06:05 -0700 (PDT)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id JAA15008
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 09:06:04 -0700 (PDT)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA17788; Fri, 22 Oct 99 12:09:02 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 MAA28216
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 12:08:47 -0400 (EDT)
Received: from miles-davis (MUCKLEY-FOURTEEN.MIT.EDU [18.172.5.14])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id MAA08628
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 12:08:46 -0400 (EDT)
Message-Id: <4.2.0.58.19991022120549.012ce598@po10.mit.edu>
X-Sender: pbh@po10.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 22 Oct 1999 12:08:22 -0400
To: ietf-calendar <ietf-calendar@imc.org>
From: "Paul B. Hill" <pbh@mit.edu>
Subject: namespace collisions :)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Hi,

Just because even bobmah was confused, Paul B. Hill is still at MIT and 
does not have an email account at myriad.com :) I don't know if the other 
Paul Hill received any message that appeared  to be out of context.

Paul


From owner-ietf-calendar@imc.org  Fri Oct 22 13:19:59 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25650
	for <calsch-archive@odin.ietf.org>; Fri, 22 Oct 1999 13:19:58 -0400 (EDT)
Received: by mail.imc.org (8.9.3/8.9.3) id JAA19064
	for ietf-calendar-bks; Fri, 22 Oct 1999 09:57:54 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA19059
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 09:57:52 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id NAA03671
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 13:13:19 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id MAA04538
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 12:58:44 -0400 (EDT)
To: ietf-calendar@imc.org
Subject: Re: New Topic: Export of calendar data and metadata
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OFB0A3EFF4.BD82B0DD-ON85256812.005E484D@Lotus.com>
Date: Fri, 22 Oct 1999 13:12:34 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/22/99 01:12:50 PM,
	Serialize complete at 10/22/99 01:12:50 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005E350085256812_="
Sender: owner-ietf-calendar@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 005E350085256812_=
Content-Type: text/plain; charset="us-ascii"

Ah, hah! 
So, by ARCHIVE/RESTORE you mean the server operation to put/get of the 
calendar store to a server-side storage device. By IMPORT/EXPORT, you mean 
the act of asking the CS for a stream of iCalendar data representing the 
current state of the calendar store or pushing to the CS a stream of 
iCalendar data representing the current state of the calendar store?
The term "IMPORT/EXPORT" is confusing, then. It implies the common 
vernacular which would be a CUA file function.
We want a EXTRACT/INSERT type of capability, then?
-- Frank

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




<br><font size=3 face="Courier New">Ah, hah! </font>
<p><font size=3 face="Courier New">So, by ARCHIVE/RESTORE you mean the server operation to put/get of the calendar store to a server-side storage device. By IMPORT/EXPORT, you mean the act of asking the CS for a stream of iCalendar data representing the current state of the calendar store or pushing to the CS a stream of iCalendar data representing the current state of the calendar store?</font>
<p><font size=3 face="Courier New">The term &quot;IMPORT/EXPORT&quot; is confusing, then. It implies the common vernacular which would be a CUA file function.</font>
<p><font size=3 face="Courier New">We want a EXTRACT/INSERT type of capability, then?</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 005E350085256812_=--


From owner-ietf-calendar@imc.org  Fri Oct 22 14:15:46 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29189
	for <calsch-archive@odin.ietf.org>; Fri, 22 Oct 1999 14:15:45 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id KAA22030
	for ietf-calendar-bks; Fri, 22 Oct 1999 10:36:23 -0700 (PDT)
Received: from piinbh1.ms.com (piinbh1.ms.com [199.89.64.71])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id KAA22026
	for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 10:36:22 -0700 (PDT)
Received: (from uucp@localhost)
        by piinbh1.ms.com (8.8.6/fw v1.22) id NAA11293
        for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 13:39:06 -0400 (EDT)
Received: from unknown(144.14.193.5) by piinbh1 via smap (4.1)
	id xma009970; Fri, 22 Oct 99 13:38:36 -0400
Received: from ms.com (hqdsl26.morgan.com [205.228.1.26])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.3) with ESMTP id NAA15872
        for <ietf-calendar@imc.org>; Fri, 22 Oct 1999 13:38:36 -0400 (EDT)
Message-ID: <3810A11C.368AC333@ms.com>
Date: Fri, 22 Oct 1999 13:38:37 -0400
From: David Madeo <dmadeo@ms.com>
Reply-To: dmadeo@ms.com
Organization: Morgan Stanley Dean Witter & Co.
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en,ja
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: New Topic: Export of calendar data and metadata
References: <OFB0A3EFF4.BD82B0DD-ON85256812.005E484D@Lotus.com>
Content-Type: multipart/mixed;
 boundary="------------8721ED1DAD4CB4D241499C49"
Sender: owner-ietf-calendar@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.
--------------8721ED1DAD4CB4D241499C49
Content-Type: multipart/alternative;
 boundary="------------DE445C2824EF6F3FEBE63C61"


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

Frank_Dawson@lotus.com wrote:

>
> Ah, hah!
>
> So, by ARCHIVE/RESTORE you mean the server operation to put/get of the
> calendar store to a server-side storage device.

Yes.  This is an implementation detail which doesn't need to be in CAP.

> By IMPORT/EXPORT, you mean the act of asking the CS for a stream of
> iCalendar data representing the current state of the calendar store or
> pushing to the CS a stream of iCalendar data representing the current
> state of the calendar store?

Yes.  Except to mention that I may want to import calendars from a
command line CUA, as well as a GUI or PDA.

> The term "IMPORT/EXPORT" is confusing, then. It implies the common
> vernacular which would be a CUA file function.

Ideally, when I do "File->Export", the CUA will do a "EXTRACT" (as you
call it), and then save the results on the local machine somewhere.  So
while I see the distinction, I'm not sure it's important.

> We want a EXTRACT/INSERT type of capability, then?

I'm not too worried about what it's called.  EXTRACT is fine with me.

dmadeo

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Frank_Dawson@lotus.com wrote:
<blockquote TYPE=CITE>&nbsp;
<br><font face="Courier New"><font size=+0>Ah, hah!</font></font>
<p><font face="Courier New"><font size=+0>So, by ARCHIVE/RESTORE you mean
the server operation to put/get of the calendar store to a server-side
storage device.</font></font></blockquote>
Yes.&nbsp; This is an implementation detail which doesn't need to be in
CAP.
<blockquote TYPE=CITE><font face="Courier New"><font size=+0>By IMPORT/EXPORT,
you mean the act of asking the CS for a stream of iCalendar data representing
the current state of the calendar store or pushing to the CS a stream of
iCalendar data representing the current state of the calendar store?</font></font></blockquote>
Yes.&nbsp; Except to mention that I may want to import calendars from a
command line CUA, as well as a GUI or PDA.
<blockquote TYPE=CITE><font face="Courier New"><font size=+0>The term "IMPORT/EXPORT"
is confusing, then. It implies the common vernacular which would be a CUA
file function.</font></font></blockquote>
Ideally, when I do "File->Export", the CUA will do a "EXTRACT" (as you
call it), and then save the results on the local machine somewhere.&nbsp;
So while I see the distinction, I'm not sure it's important.
<blockquote TYPE=CITE><font face="Courier New"><font size=+0>We want a
EXTRACT/INSERT type of capability, then?</font></font></blockquote>
I'm not too worried about what it's called.&nbsp; EXTRACT is fine with
me.
<p>dmadeo</html>

--------------DE445C2824EF6F3FEBE63C61--

--------------8721ED1DAD4CB4D241499C49
Content-Type: text/x-vcard; charset=us-ascii;
 name="dmadeo.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Madeo
Content-Disposition: attachment;
 filename="dmadeo.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Madeo;David
tel;fax:212-762-1009
tel;work:212-762-2348
x-mozilla-html:FALSE
url:www.ms.com
org:Morgan Stanley Dean Witter and Discover;Information Technology
version:2.1
email;internet:dmadeo@ms.com
adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA
x-mozilla-cpt:;0
fn:David Madeo
end:vcard

--------------8721ED1DAD4CB4D241499C49--



From owner-ietf-calendar@imc.org  Sat Oct 23 05:47:53 1999
Received: from mail.imc.org (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00122
	for <calsch-archive@odin.ietf.org>; Sat, 23 Oct 1999 05:47:52 -0400 (EDT)
Received: (from majordomo@localhost)
	by mail.imc.org (8.9.3/8.9.3) id CAA02149
	for ietf-calendar-bks; Sat, 23 Oct 1999 02:19:55 -0700 (PDT)
Received: from teapot16.domain4.bigpond.com (teapot16.domain4.bigpond.com [139.134.5.164])
	by mail.imc.org (8.9.3/8.9.3) with SMTP id CAA02140
	for <ietf-calendar@imc.org>; Sat, 23 Oct 1999 02:19:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by teapot16.domain4.bigpond.com (NTMail 3.02.13) with ESMTP id ba953083 for <ietf-calendar@imc.org>; Sat, 23 Oct 1999 19:18:14 +1000
Received: from LDIP-T-009-p-73-131.tmns.net.au ([139.134.73.131]) by mail4.bigpond.com (Claudes-Cheesy-MailRouter V2.5 7/1035785); 23 Oct 1999 19:18:13
From: "Simon Mackay" <Simon_Mackay@bigpond.com>
To: "VCard Mailing List (E-mail)" <imc-vcard@imc.org>,
        "Ietf-Calendar (E-mail)" <ietf-calendar@imc.org>
Subject: Lotus Notes and vCard
Date: Sat, 23 Oct 1999 19:00:18 +1000
Message-ID: <000e01bf1d38$1654e620$8349868b@SimonMackay>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01BF1D8B.E85E0A40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-ietf-calendar@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01BF1D8B.E85E0A40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

****************************************************************************
*******************************************************
Sorry about this cross-post but it is concerning both the vCard and
iCalendar standards and application support.
****************************************************************************
*******************************************************

Hi everyone!

Does anyone at IBM know whether Lotus Notes will support the importing of
contact and scheduling data from vCard objects or iCalendar objects. This is
because if this groupware program can accept contacts and schedule info
published in this form, it means that people who have other PIMs can send
this kind of information to Notes correspondents.

Also, are there any add-ins that allow Notes users to import or export
contact and schedule data into these formats?

With regards,

Simon Mackay

------=_NextPart_000_000F_01BF1D8B.E85E0A40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.00.2721.2900" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D70075208-23101999>***********************************************=
*************************************************************************=
***********</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D70075208-23101999>Sorry =
about this=20
cross-post but it is concerning both the vCard and iCalendar standards =
and=20
application support.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D70075208-23101999>***********************************************=
*************************************************************************=
***********</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D70075208-23101999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D70075208-23101999>Hi=20
everyone!</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D70075208-23101999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D70075208-23101999>Does =
anyone=20
at&nbsp;IBM know whether Lotus Notes will support the importing of =
contact and=20
scheduling data from vCard objects or iCalendar objects. This is because =
if this=20
groupware program can accept contacts&nbsp;and schedule info published =
in this=20
form, it means that people who have other PIMs can send this kind of =
information=20
to Notes correspondents.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D70075208-23101999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D70075208-23101999>Also, =
are there any=20
add-ins that allow Notes users to import or export contact and schedule =
data=20
into these formats?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D70075208-23101999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D70075208-23101999>With=20
regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D70075208-23101999></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D70075208-23101999>Simon=20
Mackay</SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01BF1D8B.E85E0A40--



From owner-ietf-calendar@imc.org  Sun Oct 24 03:28:55 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02447
	for <calsch-archive@odin.ietf.org>; Sun, 24 Oct 1999 03:28:54 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA27776
	for ietf-calendar-bks; Sat, 23 Oct 1999 23:57:24 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA27772
	for <ietf-calendar@imc.org>; Sat, 23 Oct 1999 23:57:22 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA18650
	for ietf-calendar@imc.org; Sun, 24 Oct 1999 00:00:03 -0700 (PDT)
Date: Sun, 24 Oct 1999 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@royer.com>
Message-Id: <199910240700.AAA18650@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@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		U
     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

 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.	U
     [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				U
 
 W-14 CAP VEVENT Schema				U
 
 W-15 CAP VTODO Schema				U
 
 W-16 CAP VJOURNAL Schema			U
 
 W-17 CAP VCAR Schema				U

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

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

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			U

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

 W-24 CAP Calendar CHARSET property issues	U

 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				U
      (CAP-00 - 12.2)
      Will there need to be one?		U
      Optional?					U

 W-29 Import/Export				U

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

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

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


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@imc.org  Sun Oct 24 08:22:01 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07553
	for <calsch-archive@odin.ietf.org>; Sun, 24 Oct 1999 08:22:01 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA03475
	for ietf-calendar-bks; Sun, 24 Oct 1999 04:55:41 -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 EAA03469;
	Sun, 24 Oct 1999 04:55:40 -0700 (PDT)
From: Frank_Dawson@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236])
	by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA20220;
	Sun, 24 Oct 1999 08:11:17 -0400 (EDT)
Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108])
	by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id HAA17642;
	Sun, 24 Oct 1999 07:56:45 -0400 (EDT)
To: "Simon Mackay" <Simon_Mackay@bigpond.com>
Cc: ietf-calendar@imc.org, imc-vcard@imc.org
Subject: Re: Lotus Notes and vCard
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF2EE909CF.332321AC-ON85256814.0042A44A@Lotus.com>
Date: Sun, 24 Oct 1999 08:10:00 -0400
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.1|July 16, 1999) at
 10/24/99 08:10:02 AM
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_mixed 0042982185256814_="
Sender: owner-ietf-calendar@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>

--=_mixed 0042982185256814_=
Content-Type: multipart/alternative; boundary="=_alternative 0042982185256814_="


--=_alternative 0042982185256814_=
Content-Type: text/plain; charset="us-ascii"

Check on www.notes.net for the "Notes vCard Support". It provides 
import/export support for Notes r4.5x, r4.6x and r5.x of vCard version 2.1 
and 3.0. Probably the first such support for v3.0 in the industry? There 
is also a Win32 vCard Viewer.
-- Frank Dawson

--=_alternative 0042982185256814_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Check on www.notes.net for the &quot;Notes vCard Support&quot;. It provides import/export support for Notes r4.5x, r4.6x and r5.x of vCard version 2.1 and 3.0. Probably the first such support for v3.0 in the industry? There is also a Win32 vCard Viewer.</font>
<p><font size=3 face="Courier New">-- Frank Dawson</font>
<p>
--=_alternative 0042982185256814_=--
--=_mixed 0042982185256814_=
Content-Type: application/octet-stream; name="myvcard-v30.vcf"
Content-Disposition: attachment; filename="myvcard-v30.vcf"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

QkVHSU46VkNBUkQNClZFUlNJT046My4wDQpOOkRhd3NvbjtGcmFuaw0KRk46RnJhbmsgRGF3c29u
DQpPUkc6TG90dXMgRGV2ZWxvcG1lbnQgQ29ycG9yYXRpb247Q29tbXVuaWNhdGlvbnMgUHJvZHVj
dHMgRGl2aXNpb24NClRaOi0wNTowMA0KVElUTEU6Q29uc3VsdGluZyBFbmdpbmVlcg0KRU1BSUw7
VFlQRT1XT1JLLFBSRUYsSU5URVJORVQ6RnJhbmtfRGF3c29uQExvdHVzLmNvbQ0KRU1BSUw7VFlQ
RT1XT1JLLElOVEVSTkVUOmZkYXdzb25AZWFydGhsaW5rLm5ldA0KTEFCRUw7VFlQRT1XT1JLLFBB
UkNFTCxQT1NUQUw6NjU0NCBCYXR0bGVmb3JkIERyaXZlXG5SYWxlaWdoLCBOQyAyNzYxMy0NCiAz
NTAyXG5VUw0KVEVMO1RZUEU9V09SSyxQUkVGLE1TRzorMSA2MTctNjkzLTg3MjgNClRFTDtUWVBF
PVdPUks6KzEgOTE5LTY3Ni05NTE1DQpURUw7VFlQRT1XT1JLO0ZBWDorMSA2MTctNjkzLTg3MjgN
ClRFTDtUWVBFPUNFTEw6KzEgOTE5LTYwNC0xNTE1IA0KQURSO1RZUEU9V09SSyxQQVJDRUwsUE9T
VEFMOjs7NjU0NCBCYXR0bGVmb3JkIERyaXZlO1JhbGVpZ2g7TkM7Mjc2MTMtMzUwMjtVUw0KWC1D
T01QQU5ZLVVSTDpodHRwOi8vd3d3LkxvdHVzLmNvbS9jYWxlbmRhcg0KRU5EOlZDQVJEDQo=
--=_mixed 0042982185256814_=--


From owner-ietf-calendar@imc.org  Tue Oct 26 07:54:08 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02732
	for <calsch-archive@odin.ietf.org>; Tue, 26 Oct 1999 07:54:07 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA23697
	for ietf-calendar-bks; Tue, 26 Oct 1999 04:24:16 -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 EAA23692
	for <ietf-calendar@imc.org>; Tue, 26 Oct 1999 04:24:11 -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 HAA01905;
	Tue, 26 Oct 1999 07:27:13 -0400 (EDT)
Message-Id: <199910261127.HAA01905@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-cap-01.txt
Date: Tue, 26 Oct 1999 07:27:12 -0400
Sender: owner-ietf-calendar@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		: Calendar Access Protocol (CAP)
	Author(s)	: S. Mansour,  F. Dawson, D. Royer, A. Taler,  P. Hill
	Filename	: draft-ietf-calsch-cap-01.txt
	Pages		: 81
	Date		: 25-Oct-99
	
The Calendar Access Protocol (CAP) is an Internet protocol that
permits a Calendar User (CU) to utilize a Calendar User Agent (CUA)
to access an [RFC2445] based Calendar Store (CS). This memo defines
the CAP specification.
The CAP definition is based on requirements identified by the
Internet Engineering Task Force (IETF) Calendaring and Scheduling
(CALSCH) Working Group. More information about the IETF CALSCH
Working Group activities can be found on the IMC web site at
http://www.imc.org/ietf-calendar, and at the IETF web site at
http://www.ietf.org/html.charters/calsch-charter.html. Refer to the
references within this memo for further information on how to access
these various documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-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-cap-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-cap-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:	<19991025150559.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--




From owner-ietf-calendar@imc.org  Wed Oct 27 12:53:40 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22734
	for <calsch-archive@odin.ietf.org>; Wed, 27 Oct 1999 12:53:39 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA08800
	for ietf-calendar-bks; Wed, 27 Oct 1999 09:22:51 -0700 (PDT)
Received: from komarr.local.thibault.org (adsl-151-197-16-76.bellatlantic.net [151.197.16.76])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08794
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 09:22:45 -0700 (PDT)
Received: from ariel.local.thibault.org (ariel.local.thibault.org [192.168.10.18])
	by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id MAA03634
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 12:25:01 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.local.thibault.org (8.8.7/8.8.7) with ESMTP id MAA28276
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 12:25:29 -0400
Message-ID: <38172779.95A4653C@ecal.com>
Date: Wed, 27 Oct 1999 12:25:29 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: calsch WG <ietf-calendar@imc.org>
Subject: Re: queries for unbounded recurring components
References: <D301B2FFCEB90140AF181C6EBBF12E06033535@PTPUP.dfpt.extest.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

"Lisa Lippert (Dusseault) (Platinum)" wrote:

> Generally I agree with John's principle to push things to the
> edges, but I'm not so sure on this one.  The problem is that to
> do a simple query such as "what appointments do I have today?",
> the client has to either rely on the server to do expansion, OR
> the client has to download all appointments today, plus all
> appointments that recur.

Not necessarily; the server may not have to expand the recurring
event in order to find out whether it occurs on a given day.  For
example, if we have:

DTSTART;TZID=US-Eastern:19970105T083000
RECUR:FREQ=WEEKLY

Then the server says, "OK, 19970105 is a Sunday; is the day being
asked about a Sunday?".

> It may be reasonable to limit the amount of expansion the
> server has to do, though.  It could be interesting to allow the
> client to request recurrance expansion for a range of dates,
> and for the server to be able to respond "no".  (Then the
> client just has to download the recurring items).  That
> flexibility on the server allows it to tune for the best
> performance, both CPU and on the wire.

Yeah, but every extra bit of flexibility in the protocol makes
for more cases to test for interop--and it's a combinatorial
problem, not linear.

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





From owner-ietf-calendar@imc.org  Wed Oct 27 14:13:00 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27740
	for <calsch-archive@odin.ietf.org>; Wed, 27 Oct 1999 14:12:58 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id KAA10264
	for ietf-calendar-bks; Wed, 27 Oct 1999 10:32:40 -0700 (PDT)
Received: from capricorn.iris.com (capricorn.iris.com [198.112.211.23])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10260
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 10:32:38 -0700 (PDT)
From: Bruce_Kahn@iris.com
To: "Lisa Lippert \(Dusseault\) \(Platinum\)" <lisal@microsoft.com>
Cc: francis@ecal.com, ietf-calendar@imc.org
Subject: RE: queries for unbounded recurring components
X-Mailer: Lotus Notes Release 5.0.1 July 16, 1999
Message-ID: <OF683E3EB4.8E95FBC5-ON85256817.005F9585@iris.com>
Date: Wed, 27 Oct 1999 13:35:45 -0400
X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V502_10211999 |October 21, 1999) at 10/27/99 01:37:57 PM,
	Serialize complete at 10/27/99 01:37:57 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0061431785256817_="
Sender: owner-ietf-calendar@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 0061431785256817_=
Content-Type: text/plain; charset="us-ascii"

Lisa wrote:
>It may be reasonable to limit the amount of expansion the server has to 
do, though. 
>It could be interesting to allow the client to request recurrance 
expansion for a range
>of dates, and for the server to be able to respond "no".  (Then the 
client just has to
>download the recurring items).  That flexibility on the server allows it 
to tune for the
>best performance, both CPU and on the wire.

Before I espouse my KISS mantra again, Id like to note that one monkey 
wrench that has not yet been considered in this discussion is the return 
of signed and/or encrypted data.  So far we have agreed that we have some 
design issues dealing with signed/encrypted data but we have not directly 
addressed 'em.  Not sure if that is because we expect our borrowed 
security types to do this for us or if we are being a collective 
ostrich...

Back to the wrench: If the data is signed then this could be blown if the 
CS returns only partial data (either because the client asked for only a 
partial set or becuase the CS restricted it for some reason like 
restricted expansion).  Also, since recurrance instances may not be 
explicitly signed (ie: "RRULE:FREQ=WEEKLY;BYDAY=MO") then extracting the 
full snapshot of the instance for 01-Nov-1999 would result in either 
incorrect or missing signatures.  This could be an argument for where 
signatures and encryption may not be usable in our C&S world as we 
currently expect it to be...

If the data is encrypted, then unless the CS has the key to crack open the 
data and return the expected chunks we have to deal with another serious 
architecture issue.  The same issues applies to the extracting a single 
instance from an encrypted chunk and then reencrypting it for the CU; just 
what do we expect the CS to realistically do?

Im tapped out now but I promise to get some free cycles before DC to 
devote to this.  Whatever solution we collectively come to, I hope it 
follows the KISS principle so that we dont build something big, obtuse and 
very unwieldy that we have to code up and live with for several years! The 
simplest designs usually last better than very complex ones (very 
paraphrased form Sir Arthur Conan Doyle).

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




<br><font size=2 face="sans-serif">Lisa wrote:</font>
<br><font size=2 face="Times New Roman">&gt;It may be reasonable to limit the amount of expansion the server has to do, though. &nbsp;</font>
<br><font size=2 face="Times New Roman">&gt;It could be interesting to allow the client to request recurrance expansion for a range</font>
<br><font size=2 face="Times New Roman">&gt;of dates, and for the server to be able to respond &quot;no&quot;. &nbsp;(Then the client just has to</font>
<br><font size=2 face="Times New Roman">&gt;download the recurring items). &nbsp;That flexibility on the server allows it to tune for the</font>
<br><font size=2 face="Times New Roman">&gt;best performance, both CPU and on the wire.</font>
<br>
<br><font size=2 face="sans-serif">Before I espouse my KISS mantra again, Id like to note that one monkey wrench that has not yet been considered in this discussion is the return of signed and/or encrypted data. &nbsp;So far we have agreed that we have some design issues dealing with signed/encrypted data but we have not directly addressed 'em. &nbsp;Not sure if that is because we expect our borrowed security types to do this for us or if we are being a collective ostrich...</font>
<br>
<br><font size=2 face="sans-serif">Back to the wrench: If the data is signed then this could be blown if the CS returns only partial data (either because the client asked for only a partial set or becuase the CS restricted it for some reason like restricted expansion). &nbsp;Also, since recurrance instances may not be explicitly signed (ie: &quot;RRULE:FREQ=WEEKLY;BYDAY=MO&quot;) then extracting the full snapshot of the instance for 01-Nov-1999 would result in either incorrect or missing signatures. &nbsp;This could be an argument for where signatures and encryption may not be usable in our C&amp;S world as we currently expect it to be...</font>
<br>
<br><font size=2 face="sans-serif">If the data is encrypted, then unless the CS has the key to crack open the data and return the expected chunks we have to deal with another serious architecture issue. &nbsp;The same issues applies to the extracting a single instance from an encrypted chunk and then reencrypting it for the CU; just what do we expect the CS to realistically do?</font>
<br>
<br><font size=2 face="sans-serif">Im tapped out now but I promise to get some free cycles before DC to devote to this. &nbsp;Whatever solution we collectively come to, I hope it follows the KISS principle so that we dont build something big, obtuse and very unwieldy that we have to code up and live with for several years! &nbsp;The simplest designs usually last better than very complex ones (very paraphrased form Sir Arthur Conan Doyle).</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 0061431785256817_=--


From owner-ietf-calendar@imc.org  Wed Oct 27 14:14:18 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27814
	for <calsch-archive@odin.ietf.org>; Wed, 27 Oct 1999 14:14:16 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id KAA10469
	for ietf-calendar-bks; Wed, 27 Oct 1999 10:40:20 -0700 (PDT)
Received: from home.home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10464
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 10:40:18 -0700 (PDT)
Received: from home.royer.com (home.royer.com [63.195.80.50])
	by home.home.royer.com (8.8.8+Sun/8.8.8) with ESMTP id KAA13300
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 10:43:57 -0700 (PDT)
Message-ID: <381739DA.701935A8@home.royer.com>
Date: Wed, 27 Oct 1999 10:43:54 -0700
From: Doug Royer <doug@home.royer.com>
Reply-To: calsch WG <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: queries for unbounded recurring components
References: <D301B2FFCEB90140AF181C6EBBF12E06033535@PTPUP.dfpt.extest.microsoft.com> <38172779.95A4653C@ecal.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD16AAA4646B6AA17FB10429F"
Sender: owner-ietf-calendar@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.

--------------msD16AAA4646B6AA17FB10429F
Content-Type: multipart/mixed;
 boundary="------------95947EB7D28A85889C81FD39"

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

John Stracke wrote:
> 
> "Lisa Lippert (Dusseault) (Platinum)" wrote:
> 
> > Generally I agree with John's principle to push things to the
> > edges, but I'm not so sure on this one.  The problem is that to
> > do a simple query such as "what appointments do I have today?",
> > the client has to either rely on the server to do expansion, OR
> > the client has to download all appointments today, plus all
> > appointments that recur.
> 
> Not necessarily; the server may not have to expand the recurring
> event in order to find out whether it occurs on a given day.  For
> example, if we have:
> 
> DTSTART;TZID=US-Eastern:19970105T083000
> RECUR:FREQ=WEEKLY
> 
> Then the server says, "OK, 19970105 is a Sunday; is the day being
> asked about a Sunday?".

It still breaks one of the CAP goals. To support what
we called thin clients.
--------------95947EB7D28A85889C81FD39
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

--------------95947EB7D28A85889C81FD39--

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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDI3MTc0MzU2WjAjBgkqhkiG9w0BCQQxFgQUJ/Cm+rrd
9KqcInOXcipckwb7X98wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYB4FFrY25U7QKjbzNXP97Y4ziQLj7zZ/olS2ivL8upxs/FzhoAK6EaX0QGkuhhi
7kHZESsVp6+WVMfRpsCKWRFga5z0VAieegKpSBCzF6CFcrtshYiHZd0aMmgHBR4AwZTnf7Bb
LlDTTVm1v5ft/UbVk7pOAiShb5F42a/H3hnupg==
--------------msD16AAA4646B6AA17FB10429F--



From owner-ietf-calendar@imc.org  Wed Oct 27 15:13:35 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01581
	for <calsch-archive@odin.ietf.org>; Wed, 27 Oct 1999 15:13:35 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA11998
	for ietf-calendar-bks; Wed, 27 Oct 1999 11:38:09 -0700 (PDT)
Received: from home.home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11994
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 11:38:07 -0700 (PDT)
Received: from home.royer.com (home.royer.com [63.195.80.50])
	by home.home.royer.com (8.8.8+Sun/8.8.8) with ESMTP id LAA13401
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 11:41:47 -0700 (PDT)
Message-ID: <38174764.D4340A4A@home.royer.com>
Date: Wed, 27 Oct 1999 11:41:40 -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: ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
References: <OF683E3EB4.8E95FBC5-ON85256817.005F9585@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD6DB32251A7FDD147C584763"
Sender: owner-ietf-calendar@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.

--------------msD6DB32251A7FDD147C584763
Content-Type: multipart/mixed;
 boundary="------------6260EF955858658294901CDA"

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

Bruce_Kahn@iris.com wrote:
 
> If the data is encrypted, then unless the CS has the key to crack open the
> data and return the expected chunks we have to deal with another serious
> architecture issue.  The same issues applies to the extracting a single
> instance from an encrypted chunk and then reencrypting it for the CU; just
> what do we expect the CS to realistically do?

If the CS does not have the key, it could not have returned ANY of the data.
And the CS would not know how to return any date ranges. So that will not
work.

It is against IETF policy (as I understand it) to hold a users key
on a server. So unless I misunderstand - that can not be an issue to
us (perhaps someone could implement a CS that did, but that is going
to be out of scope to CALSCH).

With that, we then must depend (IN CAP) on a secure line (TLS).

While transporting the object with iMIP, S/MIME would be used
and the model would have to be:

	sending CUA -> receiving MTA -> receiving MUA -> <move to> CUA -> CS.

Where the receiving MUA or perhaps the CUA did the S/MIME stuff
and put the clear text iCalendar object into the CS using CAP and TLS.
Then secure the heck out of your server.


-Doug
--------------6260EF955858658294901CDA
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

--------------6260EF955858658294901CDA--

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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDI3MTg0MTQxWjAjBgkqhkiG9w0BCQQxFgQUSQeUpZ2g
BOzupmsb1qhzM5N5d7owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYAMGisYcUVWFovfnbNnf48dbUM4x15euXMD69wHN4+wv6DiH3//psxTHBVlGeiv
q9FcgguJN2nCno967puEKUpcTehIRpq5cU+l75ekqQxlX1q9VujwNLY4xLIYn6TLf/BRKelT
mYZ56eqNRZguX5qZYcwbZKh4L2xt838I2CfuZg==
--------------msD6DB32251A7FDD147C584763--



From owner-ietf-calendar@imc.org  Wed Oct 27 15:44:54 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03480
	for <calsch-archive@odin.ietf.org>; Wed, 27 Oct 1999 15:44:53 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12879
	for ietf-calendar-bks; Wed, 27 Oct 1999 12:19:38 -0700 (PDT)
Received: from texsmtp1.texaco.com ([144.5.4.22])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12875
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 12:19:37 -0700 (PDT)
Received: from msx01099.boc.texaco.com ([10.96.52.29])
	by texsmtp1.texaco.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA27479;
	Wed, 27 Oct 1999 14:21:57 -0500 (CDT)
Received: by msx01099.boc.texaco.com with Internet Mail Service (5.5.2448.0)
	id <VVSF6MKG>; Wed, 27 Oct 1999 14:15:09 -0500
Message-ID: <F7329CD3198DD2118EF200805F85266B0199BE16@msx01000.boc.texaco.com>
From: "Lowde, Chris A" <lowdeca@texaco.com>
To: "'John Stracke'" <francis@ecal.com>, calsch WG <ietf-calendar@imc.org>
Subject: RE: queries for unbounded recurring components
Date: Wed, 27 Oct 1999 14:17:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ietf-calendar@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>

There is a slight problem with the following statement:

Then the server says, "OK, 19970105 is a Sunday; is the day being
asked about a Sunday?".

When it is Sunday in Houston, it could well, and for 6 hours, 5 for 1 week
in April,  will be, Monday in London.  

When the calendar user is traveling and is looking at a calendar that is
housed in TimeZone1, is currently in TimeZone2 and is looking at an event
for a time when they are in TimeZone3 the issue of who is expanding what
becomes non-trivial.  In general it should be done by the server which will
be the only system that will have all the information about the user on
which to base the expansion.


Chris.
?
?????????????????
Christopher A Lowde
Texaco
4800 Fournace Pl.
Bellaire, TX 77401-2324
Tel: +1(713)432-2901
Fax: +1(713)838-4529
mailto:lowdeca@texaco.com




 -----Original Message-----
From: 	John Stracke [mailto:francis@ecal.com] 
Sent:	Wednesday, October 27, 1999 11:25
To:	calsch WG
Subject:	Re: queries for unbounded recurring components

"Lisa Lippert (Dusseault) (Platinum)" wrote:

> Generally I agree with John's principle to push things to the
> edges, but I'm not so sure on this one.  The problem is that to
> do a simple query such as "what appointments do I have today?",
> the client has to either rely on the server to do expansion, OR
> the client has to download all appointments today, plus all
> appointments that recur.

Not necessarily; the server may not have to expand the recurring
event in order to find out whether it occurs on a given day.  For
example, if we have:

DTSTART;TZID=US-Eastern:19970105T083000
RECUR:FREQ=WEEKLY

Then the server says, "OK, 19970105 is a Sunday; is the day being
asked about a Sunday?".

> It may be reasonable to limit the amount of expansion the
> server has to do, though.  It could be interesting to allow the
> client to request recurrance expansion for a range of dates,
> and for the server to be able to respond "no".  (Then the
> client just has to download the recurring items).  That
> flexibility on the server allows it to tune for the best
> performance, both CPU and on the wire.

Yeah, but every extra bit of flexibility in the protocol makes
for more cases to test for interop--and it's a combinatorial
problem, not linear.

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




From owner-ietf-calendar@imc.org  Wed Oct 27 16:38:21 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06860
	for <calsch-archive@odin.ietf.org>; Wed, 27 Oct 1999 16:38:20 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA13591
	for ietf-calendar-bks; Wed, 27 Oct 1999 13:05:41 -0700 (PDT)
Received: from home.home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13587
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 13:05:40 -0700 (PDT)
Received: from home.royer.com (home.royer.com [63.195.80.50])
	by home.home.royer.com (8.8.8+Sun/8.8.8) with ESMTP id NAA13493
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 13:09:19 -0700 (PDT)
Message-ID: <38175BE8.502421D1@home.royer.com>
Date: Wed, 27 Oct 1999 13:09:12 -0700
From: Doug Royer <doug@home.royer.com>
Reply-To: calsch WG <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: queries for unbounded recurring components
References: <F7329CD3198DD2118EF200805F85266B0199BE16@msx01000.boc.texaco.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF16FBA3E447DAB1FCAC12416"
Sender: owner-ietf-calendar@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.

--------------msF16FBA3E447DAB1FCAC12416
Content-Type: multipart/mixed;
 boundary="------------F5A6814EFF77E0C327C1CAA3"

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

"Lowde, Chris A" wrote:
> 
> There is a slight problem with the following statement:
> 
> Then the server says, "OK, 19970105 is a Sunday; is the day being
> asked about a Sunday?".
> 
> When it is Sunday in Houston, it could well, and for 6 hours, 5 for 1 week
> in April,  will be, Monday in London.
> 
> When the calendar user is traveling and is looking at a calendar that is
> housed in TimeZone1, is currently in TimeZone2 and is looking at an event
> for a time when they are in TimeZone3 the issue of who is expanding what
> becomes non-trivial.  In general it should be done by the server which will
> be the only system that will have all the information about the user on
> which to base the expansion.

The proposal in CAP is that CUAs ask for times in UTC.
And the server would dish out the correct replies. If the CUA
wishes to know the original timezones, then it MUST ask for TZID
and fetch the approiate VTIMEZONE data from the CS.

So in a sense your are correct. The CS must understand timezones. So
John's email is still correct in that the CS can fetch the data
given the search criteria.

I think the debate is, does a CS:

	1) Only return un-expanded components?
	2) Only return expanded components - with some limit?
	3) Only return components expanded by request. Default un-expanded.
	4) Only return components un-expanded by request. Default expanded.

If we get concensus on one of these, then the issue is how do we ask?

I would like to see a poll with responses:

	1-YES, 1-NO, 1-ABSTAIN
	2-YES, 2-NO, 2-ABSTAIN
	3-YES, 3-NO, 3-ABSTAIN
	4-YES, 4-NO, 4-ABSTAIN

And of cource any examples on how to ask the CS given the CAP ~language~.

I would say:

	1-NO, 2-NO, 3-YES, 4-NO

-Doug
--------------F5A6814EFF77E0C327C1CAA3
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

--------------F5A6814EFF77E0C327C1CAA3--

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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDI3MjAwOTE0WjAjBgkqhkiG9w0BCQQxFgQUymv/HtVD
v5tfCEmXqn38Tj5PQiYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYBINSTITS2NENtlLxf2wnyTkBaNum08gBuE9Cy2pr/jx7FyturHHgZfcaAFi0A5
eCmlSdn/MG6R/tLyqIb6lT+TYb1UHEoMrKUWsgeRMTZHQ1Sn8rRw8SuocbW/qccAe2Mnp6kk
BpSngAZ3VZqLKpOeVU2LbzEOZSvr02Ci8PY1Zw==
--------------msF16FBA3E447DAB1FCAC12416--



From owner-ietf-calendar@imc.org  Wed Oct 27 17:34:54 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10537
	for <calsch-archive@odin.ietf.org>; Wed, 27 Oct 1999 17:34:53 -0400 (EDT)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id OAA14211
	for ietf-calendar-bks; Wed, 27 Oct 1999 14:04:17 -0700 (PDT)
Received: from home.home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14207
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 14:04:15 -0700 (PDT)
Received: from home.royer.com (home.royer.com [63.195.80.50])
	by home.home.royer.com (8.8.8+Sun/8.8.8) with ESMTP id OAA14013
	for <ietf-calendar@imc.org>; Wed, 27 Oct 1999 14:07:55 -0700 (PDT)
Message-ID: <381769A4.128D0D82@home.royer.com>
Date: Wed, 27 Oct 1999 14:07:48 -0700
From: Doug Royer <doug@home.royer.com>
Reply-To: calsch WG <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: queries for unbounded recurring components
References: <F7329CD3198DD2118EF200805F85266B0199BE16@msx01000.boc.texaco.com> <38175BE8.502421D1@home.royer.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBC727A7AEF35E4A5C08AA232"
Sender: owner-ietf-calendar@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.

--------------msBC727A7AEF35E4A5C08AA232
Content-Type: multipart/mixed;
 boundary="------------5ADBCDA90D889EEAB4BEDAF8"

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

I wrote:

> 
> The proposal in CAP is that CUAs ask for times in UTC.
> And the server would dish out the correct replies. If the CUA
> wishes to know the original timezones, then it MUST ask for TZID
> and fetch the approiate VTIMEZONE data from the CS.

As Bruce pointed out to me in email, TZID is in DTSTART - oops.

So a CUA must ask for DTSTART and/or DTEND to get the TZID.
--------------5ADBCDA90D889EEAB4BEDAF8
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

--------------5ADBCDA90D889EEAB4BEDAF8--

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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDI3MjEwNzUwWjAjBgkqhkiG9w0BCQQxFgQU/tlh+73z
8Bk/Kkykq1yOr7fDKPIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYBBWdqiqQ/6UNHprK3sfq90xb6YTKVOOnVlYuYeWcJc3Y+gvCWerNTvqpubRMcD
1ADlAGQMumBCxbXNu/g91qu+dz8NvV8QZTgZtAmY0nr17n6EMUK+9CTCZtT/G4x2TsMwIeN9
SaqRJmC+u+I8SoF92DJmWKWX+8DuZOugx4TtnQ==
--------------msBC727A7AEF35E4A5C08AA232--



From owner-ietf-calendar@imc.org  Sat Oct 30 11:15:26 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03792
	for <calsch-archive@odin.ietf.org>; Sat, 30 Oct 1999 11:15:25 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20573
	for ietf-calendar-bks; Sat, 30 Oct 1999 07:45:44 -0700 (PDT)
Received: from komarr.local.thibault.org (adsl-151-197-16-76.bellatlantic.net [151.197.16.76])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20569
	for <ietf-calendar@imc.org>; Sat, 30 Oct 1999 07:45:43 -0700 (PDT)
Received: from ariel.local.thibault.org (ariel.local.thibault.org [192.168.10.18])
	by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id KAA09495
	for <ietf-calendar@imc.org>; Sat, 30 Oct 1999 10:48:12 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.local.thibault.org (8.8.7/8.8.7) with ESMTP id KAA05608
	for <ietf-calendar@imc.org>; Sat, 30 Oct 1999 10:48:41 -0400
Message-ID: <381B0549.C8033E0B@ecal.com>
Date: Sat, 30 Oct 1999 10:48:41 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: calsch WG <ietf-calendar@imc.org>
Subject: Re: queries for unbounded recurring components
References: <D301B2FFCEB90140AF181C6EBBF12E06033535@PTPUP.dfpt.extest.microsoft.com> <38172779.95A4653C@ecal.com> <381739DA.701935A8@home.royer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

Doug Royer wrote:

> > Not necessarily; the server may not have to expand the recurring
> > event in order to find out whether it occurs on a given day. [...]
>
> It still breaks one of the CAP goals. To support what
> we called thin clients.

Yes, but there are dimensions of thinness; many thin clients will be
more concerned about bandwidth than about processor power.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |I will not buy this .signature, it is scratched.|
|francis@ecal.com|                                                |
\=================================================================/





From owner-ietf-calendar@imc.org  Sat Oct 30 11:26:51 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07072
	for <calsch-archive@odin.ietf.org>; Sat, 30 Oct 1999 11:26:51 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA20855
	for ietf-calendar-bks; Sat, 30 Oct 1999 08:03:59 -0700 (PDT)
Received: from komarr.local.thibault.org (adsl-151-197-16-76.bellatlantic.net [151.197.16.76])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20851
	for <ietf-calendar@imc.org>; Sat, 30 Oct 1999 08:03:57 -0700 (PDT)
Received: from ariel.local.thibault.org (ariel.local.thibault.org [192.168.10.18])
	by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id LAA09523;
	Sat, 30 Oct 1999 11:06:26 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.local.thibault.org (8.8.7/8.8.7) with ESMTP id LAA05647;
	Sat, 30 Oct 1999 11:06:55 -0400
Message-ID: <381B098F.7EDB3765@ecal.com>
Date: Sat, 30 Oct 1999 11:06:55 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
References: <OF683E3EB4.8E95FBC5-ON85256817.005F9585@iris.com> <38174764.D4340A4A@home.royer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

Doug Royer wrote:

> Bruce_Kahn@iris.com wrote:
>
> > If the data is encrypted, then unless the CS has the key to crack open the
> > data and return the expected chunks we have to deal with another serious
> > architecture issue.  The same issues applies to the extracting a single
> > instance from an encrypted chunk and then reencrypting it for the CU; just
> > what do we expect the CS to realistically do?
>
> If the CS does not have the key, it could not have returned ANY of the data.
> And the CS would not know how to return any date ranges. So that will not
> work.

For encrypted data, this is indeed a problem.  But, for *signed* data, Bruce's
objection still stands.  It ought to be possible for someone to submit an S/MIME
message with a text/calendar body, and have the CS store the whole message.  The
CS may or may not check the signature itself, but it can then send the signed
message down in response to queries, so that clients can check the signature if
they want--that way they can do end-to-end authentication, and not have to trust
the CS not to make things up.

If we do this, it raises a couple of further questions:

  1. Should the CS, instead of having to store the whole message, be allowed to
     strip out the text/calendar from the S/MIME, discarding the signature?
  2. If so, should the CS be able to tell the sending CUA not to bother sending
     S/MIME?
  3. Should the receiving CUA be able to specify that it doesn't want the
     signature?

On #1, I think the answer is yes; otherwise it'll be impossible to fit a CAP
server on top of an existing backend.  On #2, again, I think the answer is yes,
since it saves the CUA from wasting bandwidth and CPU time, and also tell the
user that the server can't store signed data.  On #3...probably yes, but I'm not
as sure about it; the savings are less (a CUA that doesn't verify signatures
doesn't spend much CPU time on ignoring them), and the complexity may not be
worth it.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Any sufficiently rigged demo is              |
|francis@ecal.com|indistinguishable from advanced technology.  |
\==============================================================/





From owner-ietf-calendar@imc.org  Sat Oct 30 11:28:21 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07506
	for <calsch-archive@odin.ietf.org>; Sat, 30 Oct 1999 11:28:20 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA20877
	for ietf-calendar-bks; Sat, 30 Oct 1999 08:05:30 -0700 (PDT)
Received: from komarr.local.thibault.org (adsl-151-197-16-76.bellatlantic.net [151.197.16.76])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20873
	for <ietf-calendar@imc.org>; Sat, 30 Oct 1999 08:05:28 -0700 (PDT)
Received: from ariel.local.thibault.org (ariel.local.thibault.org [192.168.10.18])
	by komarr.local.thibault.org (8.9.3/8.9.3) with ESMTP id LAA09527
	for <ietf-calendar@imc.org>; Sat, 30 Oct 1999 11:07:58 -0400
Received: from ecal.com (localhost [127.0.0.1])
	by ariel.local.thibault.org (8.8.7/8.8.7) with ESMTP id LAA05655
	for <ietf-calendar@imc.org>; Sat, 30 Oct 1999 11:08:27 -0400
Message-ID: <381B09EB.F76E2EBB@ecal.com>
Date: Sat, 30 Oct 1999 11:08:27 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: calsch WG <ietf-calendar@imc.org>
Subject: Re: queries for unbounded recurring components
References: <F7329CD3198DD2118EF200805F85266B0199BE16@msx01000.boc.texaco.com> <38175BE8.502421D1@home.royer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-calendar@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

Doug Royer wrote:

> I think the debate is, does a CS:
>
>         1) Only return un-expanded components?
>         2) Only return expanded components - with some limit?
>         3) Only return components expanded by request. Default un-expanded.
>         4) Only return components un-expanded by request. Default expanded.

1, Yes; others, No.

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





From owner-ietf-calendar@imc.org  Sun Oct 31 02:25:52 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07198
	for <calsch-archive@odin.ietf.org>; Sun, 31 Oct 1999 02:25:51 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA16060
	for ietf-calendar-bks; Sat, 30 Oct 1999 23:56:45 -0700 (PDT)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA16056
	for <ietf-calendar@imc.org>; Sat, 30 Oct 1999 23:56:44 -0700 (PDT)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA25751
	for ietf-calendar@imc.org; Sun, 31 Oct 1999 00:00:03 -0700 (PDT)
Date: Sun, 31 Oct 1999 00:00:03 -0700 (PDT)
From: Doug Royer <Doug@Royer.Com>
Message-Id: <199910310700.AAA25751@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@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		U
     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

 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.	U
     [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				U
 
 W-14 CAP VEVENT Schema				U
 
 W-15 CAP VTODO Schema				U
 
 W-16 CAP VJOURNAL Schema			U
 
 W-17 CAP VCAR Schema				U

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

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

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			U

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

 W-24 CAP Calendar CHARSET property issues	U

 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				U
      (CAP-00 - 12.2)
      Will there need to be one?		U
      Optional?					U

 W-29 Import/Export				U

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

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

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


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@imc.org  Sun Oct 31 14:03:03 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22652
	for <calsch-archive@odin.ietf.org>; Sun, 31 Oct 1999 14:03:03 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id KAA24004
	for ietf-calendar-bks; Sun, 31 Oct 1999 10:44:24 -0800 (PST)
Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24000
	for <ietf-calendar@imc.org>; Sun, 31 Oct 1999 10:44:22 -0800 (PST)
Received: from home.royer.com (home.royer.com [63.195.80.50])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id KAA07811
	for <ietf-calendar@imc.org>; Sun, 31 Oct 1999 10:44:52 -0800 (PST)
Message-ID: <381C8E1C.B942A247@home.royer.com>
Date: Sun, 31 Oct 1999 10:44:44 -0800
From: Doug Royer <doug@home.royer.com>
Reply-To: calsch WG <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: queries for unbounded recurring components
References: <D301B2FFCEB90140AF181C6EBBF12E06033535@PTPUP.dfpt.extest.microsoft.com> <38172779.95A4653C@ecal.com> <381739DA.701935A8@home.royer.com> <381B0549.C8033E0B@ecal.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms14E254369E89734D86BBA087"
Sender: owner-ietf-calendar@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.

--------------ms14E254369E89734D86BBA087
Content-Type: multipart/mixed;
 boundary="------------3B5DB68ED960116C68319FF8"

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

John Stracke wrote:
> 
> Doug Royer wrote:
> 
> > > Not necessarily; the server may not have to expand the recurring
> > > event in order to find out whether it occurs on a given day. [...]
> >
> > It still breaks one of the CAP goals. To support what
> > we called thin clients.
> 
> Yes, but there are dimensions of thinness; many thin clients will be
> more concerned about bandwidth than about processor power.

Which is why it is important to do both?
--------------3B5DB68ED960116C68319FF8
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

--------------3B5DB68ED960116C68319FF8--

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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDMxMTg0NDQ2WjAjBgkqhkiG9w0BCQQxFgQULT2q8hB6
gQC3bVRnYSIyzsNqY7QwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYBq1aJk2Hn//KBJx459wV5Bmi/SbtkPhjUTKDuF7HXJ2G+CkzFvElWO3ULoR2mH
6W4JGvlyBMf09XPJthoQZqwASeyjB/YB3Vs85iH9NuG37pQeCkmWBVXczrtgPQoZoevd6rv5
kB9J0f7QmSlBdBhOX3Hwn4vrvB7GBR93TTbLRg==
--------------ms14E254369E89734D86BBA087--



From owner-ietf-calendar@imc.org  Sun Oct 31 14:36:15 1999
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27924
	for <calsch-archive@odin.ietf.org>; Sun, 31 Oct 1999 14:36:15 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA24561
	for ietf-calendar-bks; Sun, 31 Oct 1999 11:11:17 -0800 (PST)
Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24557
	for <ietf-calendar@imc.org>; Sun, 31 Oct 1999 11:11:15 -0800 (PST)
Received: from home.royer.com (home.royer.com [63.195.80.50])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA07830
	for <ietf-calendar@imc.org>; Sun, 31 Oct 1999 11:11:46 -0800 (PST)
Message-ID: <381C946E.D6775C8C@home.royer.com>
Date: Sun, 31 Oct 1999 11:11:42 -0800
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: ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
References: <OF683E3EB4.8E95FBC5-ON85256817.005F9585@iris.com> <38174764.D4340A4A@home.royer.com> <381B098F.7EDB3765@ecal.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC118008EBAABF0F39BB313E2"
Sender: owner-ietf-calendar@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.

--------------msC118008EBAABF0F39BB313E2
Content-Type: multipart/mixed;
 boundary="------------ABE889AAE2B9DB98729C2DD5"

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

John Stracke wrote:
> 
> Doug Royer wrote:
> 
> > Bruce_Kahn@iris.com wrote:
> >
> > > If the data is encrypted, then unless the CS has the key to crack open the
> > > data and return the expected chunks we have to deal with another serious
> > > architecture issue.  The same issues applies to the extracting a single
> > > instance from an encrypted chunk and then reencrypting it for the CU; just
> > > what do we expect the CS to realistically do?
> >
> > If the CS does not have the key, it could not have returned ANY of the data.
> > And the CS would not know how to return any date ranges. So that will not
> > work.
> 
> But, for *signed* data, Bruce's
> objection still stands. 

Had he made it :-)

> It ought to be possible for someone to submit an S/MIME
> message with a text/calendar body, and have the CS store the whole message.  The
> CS may or may not check the signature itself, but it can then send the signed
> message down in response to queries, so that clients can check the signature if
> they want--that way they can do end-to-end authentication, and not have to trust
> the CS not to make things up.

True - assumes the CS does not change anything in the object- and it can
depending on the application.  So as long as it can strip out the
signature (your #1 below). 

If an ATTENDEE sends a RSVP yes, and the CUA or a bot updates the status
information - then the signature of the original object would have to
be tossed.

> If we do this, it raises a couple of further questions:
> 
>   1. Should the CS, instead of having to store the whole message, be allowed to
>      strip out the text/calendar from the S/MIME, discarding the signature?
>   2. If so, should the CS be able to tell the sending CUA not to bother sending
>      S/MIME?
>   3. Should the receiving CUA be able to specify that it doesn't want the
>      signature?
> 
> ...
> On #2, again, I think the answer is yes,
> since it saves the CUA from wasting bandwidth and CPU time, and also tell the
> user that the server can't store signed data.

If the message arrived into an MUA (iMIP) and then dropped into a CUA - 
what good would it do, you have a signature anyway?

A CUA is responsible for formatting the object before sending it down
to a CS. If it does not like the bandwidth or speed of the connection
then that is a CUA issue - not a CAP issue as the CUA does not have
to send one down.

There is also no requirement that a CS support encryption or
digital signatures. So instead on saying you can't do it, maybe
there needs to be a capability saying a CS does sore signatures.
And if the capability is not present, then there is no way to tell.

> On #3...probably yes, but I'm not
> as sure about it; the savings are less (a CUA that doesn't verify signatures
> doesn't spend much CPU time on ignoring them), and the complexity may not be
> worth it.

Just as with email. Clients just ignore them.
--------------ABE889AAE2B9DB98729C2DD5
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

--------------ABE889AAE2B9DB98729C2DD5--

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

MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw
MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG
SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx
bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU
9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud
IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W
ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl
cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm
MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk
YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj
MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww
DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG
iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf
N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA
0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE
ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB
zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg
SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV
2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/
Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI
AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud
DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4
3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1
pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4
AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ
QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh
c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV
9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNOTkxMDMxMTkxMTQ0WjAjBgkqhkiG9w0BCQQxFgQU1rLtHmPr
zV7yRjSlJBsicWwlD9UwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYARKcPn3j9U9GLgV4McBGqDYXsTRao5RsQElmn0nVZ3b8bvVea7NoyEvqAhpbva
Og0nNJcULekch66hgqVbf++VguntAZBXGxe2/n5vchWOy4W1cj4NMQD6ziukH5sLI6jLG11p
8cuJJ4WUuIpEhaUaWE1W7SD4PCmNaWfmgh+TVA==
--------------msC118008EBAABF0F39BB313E2--