From owner-ietf-calendar  Sun Jan  2 00:00:36 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id AAA06584
	for ietf-calendar-bks; Sun, 2 Jan 2000 00:00:36 -0800 (PST)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06580
	for <ietf-calendar@imc.org>; Sun, 2 Jan 2000 00:00:34 -0800 (PST)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA09828
	for ietf-calendar@imc.org; Sun, 2 Jan 2000 00:00:03 -0800 (PST)
Date: Sun, 2 Jan 2000 00:00:03 -0800 (PST)
From: Doug Royer <Doug@Royer.Com>
Message-Id: <200001020800.AAA09828@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  Mon Jan  3 06:46:34 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA16960
	for ietf-calendar-bks; Mon, 3 Jan 2000 06:46:34 -0800 (PST)
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 GAA16956
	for <ietf-calendar@imc.org>; Mon, 3 Jan 2000 06:46:32 -0800 (PST)
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 KAA20901;
	Mon, 3 Jan 2000 10:00:39 -0500 (EST)
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 JAA08689;
	Mon, 3 Jan 2000 09:43:34 -0500 (EST)
To: lesage@exoffice.com
Cc: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF053DBE45.3B56E1ED-ON8525685B.005046DB@Lotus.com>
Date: Mon, 3 Jan 2000 09:46:39 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/03/2000 09:46:53 AM,
	Serialize complete at 01/03/2000 09:46:53 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005192238525685B_="
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 005192238525685B_=
Content-Type: text/plain; charset="us-ascii"

Philippe:
You point out an interesting design point. That is, is the iCalendar XML 
DTD intended to be an XML object for calendars or an alternate XML 
representation for the standard iCalendar format?
We don't need two standard calendar formats, if at all possible. This 
effort is definitely not an attempt to define a new calendar format. It is 
not an effort to define a new calendar XML application, based on 
iCalendar. I think you would agree.
There is but one standard IETF calendar format. That is iCalendar, defined 
by RFC2445. Hence, this format is an alternative XML representation for 
iCalendar. As such, an implementation will already understand iCalendar 
data types. The recurrence grammar is one of these dozen or so standard 
iCalendar data types. It is called RECUR. 
So, any valid iCalendar implementation (including one that understands a 
new alternative XML representation) will already have support for the 
standard iCalendar data types. There is no need to make interpretation of 
a XML representation of an iCalendar object any harder or more complex for 
an iCalendar implementation.
No, it is not a good idea to create RRULE and EXRULE properties as emply 
element types with the RECUR data type redefined as attributes.
-- Frank
--=_alternative 005192238525685B_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Philippe:</font>
<p><font size=3 face="Courier New">You point out an interesting design point. That is, is the iCalendar XML DTD intended to be an XML object for calendars or an alternate XML representation for the standard iCalendar format?</font>
<p><font size=3 face="Courier New">We don't need two standard calendar formats, if at all possible. This effort is definitely not an attempt to define a new calendar format. It is not an effort to define a new calendar XML application, based on iCalendar. I think you would agree.</font>
<p><font size=3 face="Courier New">There is but one standard IETF calendar format. That is iCalendar, defined by RFC2445. Hence, this format is an alternative XML representation for iCalendar. As such, an implementation will already understand iCalendar data types. The recurrence grammar is one of these dozen or so standard iCalendar data types. It is called RECUR. </font>
<p><font size=3 face="Courier New">So, any valid iCalendar implementation (including one that understands a new alternative XML representation) will already have support for the standard iCalendar data types. There is no need to make interpretation of a XML representation of an iCalendar object any harder or more complex for an iCalendar implementation.</font>
<p><font size=3 face="Courier New">No, it is not a good idea to create RRULE and EXRULE properties as emply element types with the RECUR data type redefined as attributes.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 005192238525685B_=--

From owner-ietf-calendar  Mon Jan  3 08:36:56 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA18491
	for ietf-calendar-bks; Mon, 3 Jan 2000 08:36:56 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18486
	for <ietf-calendar@imc.org>; Mon, 3 Jan 2000 08:36:46 -0800 (PST)
From: Bruce_Kahn@iris.com
To: ietf-calendar@imc.org, phill@myriad.com
Subject: Re: CAP & Latency
X-Mailer: Lotus Notes Release 5.0.2  November 4, 1999
Message-ID: <OFF62494F4.9B48BAA5-ON8525685B.005A866E@iris.com>
Date: Mon, 3 Jan 2000 11:36:06 -0500
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/03/2000 11:36:02 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/03/2000 11:36:02 AM,
	Serialize complete at 01/03/2000 11:36:02 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/03/2000 11:36:02 AM,
	S/MIME Sign complete at 01/03/2000 11:36:02 AM,
	Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 01/03/2000
 11:36:50 AM,
	Serialize complete at 01/03/2000 11:36:50 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z01886_boundary_sign
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 an S/MIME signed message.

---------z01886_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 005B30908525685B_="

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

Last week I replied in part with:
>Another subtle difference is that the rewritting server belongs to the 
same 
>'domain' that Doug does.  You wont find, say, myriad.com rewriting Dougs
>software.com address!  In Dougs diagram, CS-1 is doing the rewrite for 
>CUA-1.  However in the CAP case, it could be CS-2 (or an intermediate 
>CS-1.5) that >does the CAP->iTIP conversion and and such CANNOT do
>a rewrite safely!  (Assuming CS-1 didnt do a rewrite already that is). 

I should have been clearer in how I wrote this.  I was in a bit of a rush 
to get out for the holidays, I appologize.

Yes, a mail gateway into myriad.com would rewrite the return address such 
that Paul could easily reply to Doug via the gateway.  However, in the 
flow I originally described the return path would not be via CAP but 
rather via iTIP (iMIP).  As such, there is no guarantee that the addresses 
would get re-rewritten properly by the same CS (or MTA) that did the 
original rewrite.  (A closer analogy would be in via SMTP MTA and out via 
FAX Gateway...)

If the flow of data was via iTIP (iMIP) back to the rewritting CS and it 
in turn returned the reply back via CAP (or iTIP) to the proper 
destination then that would be a bit easier to swallow but as previously 
noted we do not have a path for data to follow out and inbound; we have a 
loop w/potentially no common points (part of my concern).

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




<br><font size=2 face="sans-serif">Last week I replied in part with:</font>
<br><font size=2><tt>&gt;Another subtle difference is that the rewritting server belongs to the same </tt></font>
<br><font size=2><tt>&gt;'domain' that Doug does. &nbsp;You wont find, say, myriad.com rewriting Dougs</tt></font>
<br><font size=2><tt>&gt;software.com address! &nbsp;In Dougs diagram, CS-1 is doing the rewrite for </tt></font>
<br><font size=2><tt>&gt;CUA-1. &nbsp;However in the CAP case, it could be CS-2 (or an intermediate </tt></font>
<br><font size=2><tt>&gt;CS-1.5) that &gt;does the CAP-&gt;iTIP conversion and and such CANNOT do</tt></font>
<br><font size=2><tt>&gt;a rewrite safely! &nbsp;(Assuming CS-1 didnt do a rewrite already that is).</tt></font><font size=3><tt> </tt></font><font size=3 face="sans-serif"><br>
</font>
<br><font size=2 face="sans-serif">I should have been clearer in how I wrote this. &nbsp;I was in a bit of a rush to get out for the holidays, I appologize.</font>
<br>
<br><font size=2 face="sans-serif">Yes, a mail gateway into myriad.com would rewrite the return address such that Paul could easily reply to Doug via the gateway. &nbsp;However, in the flow I originally described the return path would not be via CAP but rather via iTIP (iMIP). &nbsp;As such, there is no guarantee that the addresses would get re-rewritten properly by the same CS (or MTA) that did the original rewrite. &nbsp;(A closer analogy would be in via SMTP MTA and out via FAX Gateway...)</font>
<br>
<br><font size=2 face="sans-serif">If the flow of data was via iTIP (iMIP) back to the rewritting CS and it in turn returned the reply back via CAP (or iTIP) to the proper destination then that would be a bit easier to swallow but as previously noted we do not have a path for data to follow out and inbound; we have a loop w/potentially no common points (part of my concern).</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 005B30908525685B_=--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIAwggHZMIIBg6ADAgECAiBgUF6eflpWh6h9PfgYD7sAlMCM8enGl8RXOcIo9uhg
ezANBgkqhkiG9w0BAQQFADBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzEN
MAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTAeFw05OTEx
MTcxOTEzMjdaFw0wMTExMTYxOTEyNTNaMEgxDTALBgNVBAoTBElyaXMxEzARBgNV
BAMTCkJydWNlIEthaG4xIjAgBgkqhkiG9w0BCQEWE0JydWNlX0thaG5AaXJpcy5j
b20wWzANBgkqhkiG9w0BAQEFAANKADBHAkEA495S/vcTouExtWuNrF33Q28Lcjjk
4lj2W6ERZ3MhEBR5vHL3wTaXoRWVhPeoDaUcCc54oig8YQlC/hwSp3YF4QICQlGj
PDA6MBEGA1UdDgQKBAhG2i3x0db2dzAPBgNVHQ8BAf8EBQMDB7AAMBQGC2CGSAGG
+A4CAgMCBAUDAweAADANBgkqhkiG9w0BAQQFAANBAJnY7BPUuh9G4grcCnmNPlMH
JsE0/KULlvaqMab5uWQd0nFkZg64TIWwlYMLrwKqzenyrEkVF4QO6yjiShaej/Aw
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVT
MQ0wCwYDVQQIEwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIElu
dGVybmV0IENBMB4XDTk4MTEwMjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkG
A1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMT
EElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAw+BjK0cg
xCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5yBLD
j5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwz
cO3Ltq2HlXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/wi
ngAAMYAwggF5AgEBMGowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0ECIGBQXp5+WlaH
qH09+BgPuwCUwIzx6caXxFc5wij26GB7MAkGBSsOAwIaBQCggaswGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMTAzMTYzNjAyWjAj
BgkqhkiG9w0BCQQxFgQUH4U83D+MjRdjFc2UoDRgmEP7PO4wTAYJKoZIhvcNAQkP
MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D
AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQEmbuob7Q8C4dPj71t3H
BeMEAKvRFMEhrwUZ5KZlVmCJt/LzeqPJzNaqdAlWayrAzb9yStnEo26I8JxI44fd
a4kAAAAAAAAAAA==

---------z01886_boundary_sign--

From owner-ietf-calendar  Tue Jan  4 04:05:42 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA06387
	for ietf-calendar-bks; Tue, 4 Jan 2000 04:05:42 -0800 (PST)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06383
	for <ietf-calendar@imc.org>; Tue, 4 Jan 2000 04:05:40 -0800 (PST)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2])
	by internal.mail.demon.net with ESMTP id MAA00518;
	Tue, 4 Jan 2000 12:05:32 GMT
Message-ID: <Yl4XPLAEGec4QAAk@turnpike.com>
Date: Tue, 4 Jan 2000 12:03:16 +0000
To: ietf-calendar@imc.org
From: Paul Overell <paulo@turnpike.com>
Subject: iMIP, RFC2447 and [RFC-1847]-compliant encryption
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.00 beta 1 M <U2yaxlNz9mbtXQDcM+J3SutElj>
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>



iMIP, RFC2447 says: 


>2.2.3 Confidentiality
>
>   To ensure confidentiality using iMIP implementations should utilize
>   [RFC-1847]-compliant encryption.
>


This implicitly excludes S/MIME encryption (RFC2633 etc) as S/MIME's
encryption is not [RFC-1847]-compliant - i.e. S/MIME does not use
multipart/encrypted.


Is this exclusion of S/MIME intentional or have I misunderstood
something here?


Regards
-- 
Paul Overell                                        T U R N P I K E  Ltd

From owner-ietf-calendar  Tue Jan  4 06:07:56 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07727
	for ietf-calendar-bks; Tue, 4 Jan 2000 06:07:56 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07723
	for <ietf-calendar@imc.org>; Tue, 4 Jan 2000 06:07:55 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20211
	for <ietf-calendar@imc.org>; Tue, 4 Jan 2000 06:07:49 -0800 (PST)
Received: from ireland.sun.com (crimea [129.156.238.50])
	by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id OAA21809
	for <ietf-calendar@imc.org>; Tue, 4 Jan 2000 14:07:48 GMT
Message-ID: <3871FEB3.C3BE9AA5@ireland.sun.com>
Date: Tue, 04 Jan 2000 14:07:48 +0000
From: Michael Krivoruchko <misha@ireland.sun.com>
Organization: Sun Microsystems Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
References: <99122918095801.02377@saria.exoffice.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>

Hi All and Happy New Year!

>From  my point of view the current DTD has to be *dramaticaly* improved
in two directions:

  1. Data typing and data structure (Philippe, I am with you!).
     Things like 'rrule' or 'DATE-TIME' have internal structure which can
     be explained in XML tags, so we should do this to make the internal
     data structure "visible" from XML level.

  2. DTD should provide more information for a validation XML parser.
     Elements has to have more restrictive (more correct) definition.
     Say, we should not use "(something.opt1)* (something.optm)*", where:
        something.opt1 := (tag1) | (tag2) | ... | (tagN)
     instead we should use "something.opt1 (something.optm)*", where:
        something.opt1 := (tag1)? (tag2)? ... (tagN)?

Philippe Lesage wrote:

>
> I think that the definition of the rrules & exrules elements in the xml dtd
> should be improved. The current definition (P35) is :
> <!ELEMENT rrule (#PCDATA) >
> <!ATTLIST rrule value NOTATION (RECUR) #IMPLIED>
>
> So, a rule looks like :
> <rrule>FREQ=YEARLY;COUNT=5;BYDAY=1MO</rrule>
>
> In this case, a xml parser would give you  back the string
> "FREQ=YEARLY;COUNT=5;BYDAY=1MO" from the xml file, then you would have to
> parse the string yourself to get back frequency, count and day list. I do not
> think this is in the spirit of xml to proceed this way.
>
>

Michael

--
---------------------------------------------------------------
Michael Krivoruchko                 CDE Group, Sun Microsystems
    Bool House, East Point Business Park, Dublin 3, Ireland
Ph: +353 1 819 9272               E-mail: misha@ireland.sun.com
---------------------------------------------------------------




From owner-ietf-calendar  Tue Jan  4 08:14:14 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA09651
	for ietf-calendar-bks; Tue, 4 Jan 2000 08:14:14 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09646
	for <ietf-calendar@imc.org>; Tue, 4 Jan 2000 08:14:12 -0800 (PST)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: Poll: What goes in...
X-Mailer: Lotus Notes Release 5.0.2  November 4, 1999
Message-ID: <OF0D231118.BE571D00-ON8525683A.005DD32C@iris.com>
Date: Tue, 4 Jan 2000 11:15:58 -0500
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/04/2000 11:13:34 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/04/2000 11:13:34 AM,
	Serialize complete at 01/04/2000 11:13:34 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/04/2000 11:13:35 AM,
	S/MIME Sign complete at 01/04/2000 11:13:35 AM,
	Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 01/04/2000
 11:16:34 AM,
	Serialize complete at 01/04/2000 11:16:34 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z01886_boundary_sign
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 an S/MIME signed message.

---------z01886_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0059222E8525685C_="

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

must come out?  During some of the hallway converstations in DC I got into 
a discussion w/others about data preservation and integrity.  Some folks 
think that the data you put into the CS does not have to come back out 
"intact".  (By "intact" I do not mean byte for byte exact unless necessary 
for stuff like multipart/signed or multipart/encrypted.)  After some 
heated back and forth we reset the talk and I tried to learn more about 
their POV.  I think after a nights sleep we were able to pick up the 
discussion but I left somewhat dazed on this issue.

So Im taking a poll of the list to see what others expect from their CS. 
Should the CS return to you the equivalent MIME data that the CUA put into 
it?  The 8 possible cases to consider:

Usigned, unencrypted entries (no outter MIME wrappers):
text/calendar MIME (a basic calendar entry; no attachments)
multipart/related MIME (a basic calendar entry; 1+ attachments)
Signed, unencrypted entries (outter multipart/signed MIME wrapper):
text/calendar MIME (a basic calendar entry; no attachments)
multipart/related MIME (a basic calendar entry; 1+ attachments)
Unsigned, Encrypted entries (outter multipart/encrypted MIME wrapper):
text/calendar MIME (a basic calendar entry; no attachments)
multipart/related MIME (a basic calendar entry; 1+ attachments)
Signed, Encrypted entries (outter multipart/signed and multipart/encrypted 
MIME wrappers):
text/calendar MIME (a basic calendar entry; no attachments)
multipart/related MIME (a basic calendar entry; 1+ attachments)

What Im want to poll the group on is what is the CS's expected behaviour 
WRT 2.x, 3.x and 4.x cases.  Ill focus on the 2.x cases for the rest of 
this posting...

Some have claimed that the CS does not have to preserve the signature of 
the original data.  They expect the CS to 'rebuild' the entry for the CUA 
from what ever internal format it uses and send back an equivalent 2.1 or 
2.2 style entry but it would have the CS's signature instead of the 
original one.  Paul (B. Hill) stated that 'audit trails' of signatures is 
not a CAP requirement but when I look in the version on the WG site I dont 
see it mentioned either way.  So I thought Id poll the group and see what 
they expect/thought WRT this issue.

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




<br><font size=2 face="sans-serif">must come out? &nbsp;During some of the hallway converstations in DC I got into a discussion w/others about data preservation and integrity. &nbsp;Some folks think that the data you put into the CS does not have to come back out &quot;intact&quot;. &nbsp;(By &quot;intact&quot; I do not mean byte for byte exact unless necessary for stuff like multipart/signed or multipart/encrypted.) &nbsp;After some heated back and forth we reset the talk and I tried to learn more about their POV. &nbsp;I think after a nights sleep we were able to pick up the discussion but I left somewhat dazed on this issue.</font>
<br>
<br><font size=2 face="sans-serif">So Im taking a poll of the list to see what others expect from their CS. &nbsp;Should the CS return to you the equivalent MIME data that the CUA put into it? &nbsp;The 8 possible cases to consider:</font>
<br>
<ol>
<li value=1><font size=2 face="sans-serif">Usigned, unencrypted entries (no outter MIME wrappers):</font></ol>
<ol>
<li value=1><font size=2 face="sans-serif">text/calendar MIME (a basic calendar entry; no attachments)</font>
<li value=2><font size=2 face="sans-serif">multipart/related MIME (a basic calendar entry; 1+ attachments)</font>
<li value=2><font size=2 face="sans-serif">Signed, unencrypted entries (outter multipart/signed MIME wrapper):</font></ol>
<ol>
<li value=1><font size=2 face="sans-serif">text/calendar MIME (a basic calendar entry; no attachments)</font>
<li value=2><font size=2 face="sans-serif">multipart/related MIME (a basic calendar entry; 1+ attachments)</font>
<li value=3><font size=2 face="sans-serif">Unsigned, Encrypted entries (outter multipart/encrypted MIME wrapper):</font></ol>
<ol>
<li value=1><font size=2 face="sans-serif">text/calendar MIME (a basic calendar entry; no attachments)</font>
<li value=2><font size=2 face="sans-serif">multipart/related MIME (a basic calendar entry; 1+ attachments)</font>
<li value=4><font size=2 face="sans-serif">Signed, Encrypted entries (outter multipart/signed and multipart/encrypted MIME wrappers):</font></ol>
<ol>
<li value=1><font size=2 face="sans-serif">text/calendar MIME (a basic calendar entry; no attachments)</font>
<li value=2><font size=2 face="sans-serif">multipart/related MIME (a basic calendar entry; 1+ attachments)</font>
<br>
<br><font size=2 face="sans-serif">What Im want to poll the group on is what is the CS's expected behaviour WRT 2.x, 3.x and 4.x cases. &nbsp;Ill focus on the 2.x cases for the rest of this posting...</font>
<br>
<br><font size=2 face="sans-serif">Some have claimed that the CS does not have to preserve the signature of the original data. &nbsp;They expect the CS to 'rebuild' the entry for the CUA from what ever internal format it uses and send back an equivalent 2.1 or 2.2 style entry but it would have the CS's signature instead of the original one. &nbsp;Paul (B. Hill) stated that 'audit trails' of signatures is not a CAP requirement but when I look in the version on the WG site I dont see it mentioned either way. &nbsp;So I thought Id poll the group and see what they expect/thought WRT this issue.</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></ol>
--=_alternative 0059222E8525685C_=--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIAwggHZMIIBg6ADAgECAiBgUF6eflpWh6h9PfgYD7sAlMCM8enGl8RXOcIo9uhg
ezANBgkqhkiG9w0BAQQFADBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzEN
MAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTAeFw05OTEx
MTcxOTEzMjdaFw0wMTExMTYxOTEyNTNaMEgxDTALBgNVBAoTBElyaXMxEzARBgNV
BAMTCkJydWNlIEthaG4xIjAgBgkqhkiG9w0BCQEWE0JydWNlX0thaG5AaXJpcy5j
b20wWzANBgkqhkiG9w0BAQEFAANKADBHAkEA495S/vcTouExtWuNrF33Q28Lcjjk
4lj2W6ERZ3MhEBR5vHL3wTaXoRWVhPeoDaUcCc54oig8YQlC/hwSp3YF4QICQlGj
PDA6MBEGA1UdDgQKBAhG2i3x0db2dzAPBgNVHQ8BAf8EBQMDB7AAMBQGC2CGSAGG
+A4CAgMCBAUDAweAADANBgkqhkiG9w0BAQQFAANBAJnY7BPUuh9G4grcCnmNPlMH
JsE0/KULlvaqMab5uWQd0nFkZg64TIWwlYMLrwKqzenyrEkVF4QO6yjiShaej/Aw
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVT
MQ0wCwYDVQQIEwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIElu
dGVybmV0IENBMB4XDTk4MTEwMjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkG
A1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMT
EElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAw+BjK0cg
xCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5yBLD
j5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwz
cO3Ltq2HlXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/wi
ngAAMYAwggF5AgEBMGowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0ECIGBQXp5+WlaH
qH09+BgPuwCUwIzx6caXxFc5wij26GB7MAkGBSsOAwIaBQCggaswGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMTA0MTYxMzM0WjAj
BgkqhkiG9w0BCQQxFgQULX8En5xPBkXBcORKk/hLFnkcg2kwTAYJKoZIhvcNAQkP
MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D
AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQCMvNs5MlzG0ff6/89SC
DEISejEyDNyxua95BJtWBkOAyhxX8BKtqdt5oeh9yBjro7hhdh7P/+JaQbm+xBT4
Xz8AAAAAAAAAAA==

---------z01886_boundary_sign--

From owner-ietf-calendar  Tue Jan  4 18:24:54 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id SAA21276
	for ietf-calendar-bks; Tue, 4 Jan 2000 18:24:54 -0800 (PST)
Received: from titan.exoffice.com (IDENT:root@host98.ridgeventures.com [207.33.160.98] (may be forged))
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21267
	for <ietf-calendar@imc.org>; Tue, 4 Jan 2000 18:24:52 -0800 (PST)
Received: from saria.exoffice.com (IDENT:root@[207.33.160.102])
	by titan.exoffice.com (8.9.3/8.9.3) with SMTP id TAA02980
	for <ietf-calendar@imc.org>; Tue, 4 Jan 2000 19:19:48 -0800
From: Philippe Lesage <lesage@exoffice.com>
Reply-To: lesage@exoffice.com
Organization: Exoffice
To: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
Date: Tue, 4 Jan 2000 17:21:49 -0800
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <OF053DBE45.3B56E1ED-ON8525685B.005046DB@Lotus.com>
In-Reply-To: <OF053DBE45.3B56E1ED-ON8525685B.005046DB@Lotus.com>
MIME-Version: 1.0
Message-Id: <0001041822310A.00697@saria.exoffice.com>
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>



> 
> Philippe:
> You point out an interesting design point. That is, is the iCalendar XML 
> DTD intended to be an XML object for calendars or an alternate XML 
> representation for the standard iCalendar format?
> We don't need two standard calendar formats, if at all possible. This 
> effort is definitely not an attempt to define a new calendar format. It is 
> not an effort to define a new calendar XML application, based on 
> iCalendar. I think you would agree.
> There is but one standard IETF calendar format. That is iCalendar, defined 
> by RFC2445. Hence, this format is an alternative XML representation for 
> iCalendar. As such, an implementation will already understand iCalendar 
> data types. The recurrence grammar is one of these dozen or so standard 
> iCalendar data types. It is called RECUR. 
> So, any valid iCalendar implementation (including one that understands a 
> new alternative XML representation) will already have support for the 
> standard iCalendar data types. 

Ok, but it is not a valid reason for preventing the DTD from describing the
data types internal structure.

You imply that the DTD could just have one single element :
<!ELEMENT iCalendar (#PCDATA) > 
Any valid ICal implementation should be able to understand this string....

>There is no need to make interpretation of 
> a XML representation of an iCalendar object any harder or more complex for 
> an iCalendar implementation.

I don't think so. In fact, all this work is done by your favorite xml parser.

> No, it is not a good idea to create RRULE and EXRULE properties as emply 
> element types with the RECUR data type redefined as attributes.
> -- Frank

Best Regards

Philippe.

----------------------------------------
Content-Type: text/html; name="unnamed"
Content-Transfer-Encoding: 7bit
Content-Description: 
----------------------------------------

From owner-ietf-calendar  Wed Jan  5 05:33:29 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA29098
	for ietf-calendar-bks; Wed, 5 Jan 2000 05:33:29 -0800 (PST)
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 FAA29092;
	Wed, 5 Jan 2000 05:33:28 -0800 (PST)
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 IAA13194;
	Wed, 5 Jan 2000 08:47:45 -0500 (EST)
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 IAA12167;
	Wed, 5 Jan 2000 08:30:24 -0500 (EST)
To: lesage@exoffice.com
Cc: ietf-calendar@imc.org, owner-ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OFFE91350B.0B420BC4-ON8525685D.0049EB2B@Lotus.com>
Date: Wed, 5 Jan 2000 08:33:56 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/05/2000 08:34:07 AM,
	Serialize complete at 01/05/2000 08:34:07 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 004AF07B8525685D_="
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 004AF07B8525685D_=
Content-Type: text/plain; charset="us-ascii"

Philippe:
You aren't really serious. Certainly, there is quite a difference between 
leveraging standard data types in iCalendar within the XML DTD. A PCDATA 
content type for these is appropriate. But a PCDATA content type for the 
whole of the iCalendar object is not an equal argument.
You seem to be approaching this as a XML application design problem, 
rather than just a remapping of iCalendar semantics into an alternate 
syntax. The originator and recipient of these objects are presumed to be 
iCalendar conformant subsystems.
We are also not assuming the XML iCalendar object would be parsed by a 
validating parser. This would be a huge implementation overhead for client 
environments. The only requirement that seems reasonable is that the XML 
iCalendar object be well-formed, but not even a valid XML entity. That is, 
there may not be a XML declaration or prolog/epilog in the entity.
-- Frank
--=_alternative 004AF07B8525685D_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Philippe:</font>
<p><font size=3 face="Courier New">You aren't really serious. Certainly, there is quite a difference between leveraging standard data types in iCalendar within the XML DTD. A PCDATA content type for these is appropriate. But a PCDATA content type for the whole of the iCalendar object is not an equal argument.</font>
<p><font size=3 face="Courier New">You seem to be approaching this as a XML application design problem, rather than just a remapping of iCalendar semantics into an alternate syntax. The originator and recipient of these objects are presumed to be iCalendar conformant subsystems.</font>
<p><font size=3 face="Courier New">We are also not assuming the XML iCalendar object would be parsed by a validating parser. This would be a huge implementation overhead for client environments. The only requirement that seems reasonable is that the XML iCalendar object be well-formed, but not even a valid XML entity. That is, there may not be a XML declaration or prolog/epilog in the entity.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 004AF07B8525685D_=--

From owner-ietf-calendar  Wed Jan  5 07:44:41 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA01121
	for ietf-calendar-bks; Wed, 5 Jan 2000 07:44:41 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01117
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 07:44:40 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21341
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 07:44:38 -0800 (PST)
Received: from ireland.sun.com (crimea [129.156.238.50])
	by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id PAA24123
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 15:44:36 GMT
Message-ID: <387366E4.4FADDC7D@ireland.sun.com>
Date: Wed, 05 Jan 2000 15:44:36 +0000
From: Michael Krivoruchko <misha@ireland.sun.com>
Organization: Sun Microsystems Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
References: <99122918095801.02377@saria.exoffice.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>

Hi All,

Frank Dawson wrote:

> We don't need two standard calendar formats, if at all possible. This effort is
> definitely not an attempt to define a new calendar format. It is not an effort to
> define a new calendar XML application, based on iCalendar. I think you would agree.
>

We are not creating a new format! Only thing we do is searching an XML
equivalent of RFC2445 data types. It is hard to find out "iCalendar XML"
tools, but there are few "XML aware" applications around. Why not allow
them "to see" iCalendar data?


The following is my version of RECUR data type. It is nearly the same as
Philippe's version but this variant a bit more strict than original:
  1. 'freq' is defined as '#REQUIRED' attribute with a list of possible values
  2. 'until' and 'count' defined as elements
  3. 'weekday' uses a list of possible values
  4. 'by...' rules more "typesafe"

---------------------------------------------------
<!-- TIME -->
<!ELEMENT seconds #PCDATA>  <!-- 0..60 -->
<!ELEMENT minutes #PCDATA>  <!-- 0..59 -->
<!ELEMENT hours #PCDATA>  <!-- 0..23 -->

<!ELEMENT TIME (hours, minutes, seconds)>

<!-- DATE and DATE-TIME -->
<!ENTITY % attr.weekday "MO | TU | WE | TH | FR | SA | SU">

<!ELEMENT monthday #PCDATA>  <!-- (-31..-1) | (1..31) -->
<!ELEMENT yearday #PCDATA>  <!-- (-366..-1) | (1..366) -->
<!ELEMENT weekno #PCDATA>  <!-- (-53..-1) | (1..53) -->
<!ELEMENT monthno #PCDATA>  <!-- 1..12 -->
<!ELEMENT yearno #PCDATA>  <!-- [0-9]{1,4} -->
<!ELEMENT yearpos #PCDATA>  <!-- (-366..-1) | (1..366) -->
<!ELEMENT weekday weekno?>  <!-- "weekno" is day's month or year position -->
<!ATTLIST weekday name (%attr.weekday;) #REQUIRED>

<!ELEMENT DATE (yearno, monthno, monthday)>
<!ELEMENT DATE-TIME (DATE, TIME)>

<!-- RECUR -->
<!ELEMENT until (DATE | DATE-TIME)>
<!ELEMENT count #PCDATA>  <!-- positive intager -->

<!ELEMENT bysecond seconds+>
<!ELEMENT byminute minutes+>
<!ELEMENT byhour hours+>
<!ELEMENT byweekday weekday+>
<!ELEMENT bymonthday monthday+>
<!ELEMENT byyearday yearday+>
<!ELEMENT byweekno weekno+>
<!ELEMENT bymonth monthno+>
<!ELEMENT bysetpos yearpos+>

<!ENTITY % RECUR.time "(bysecond?), (byminute?), (byhour?)">
<!ENTITY % RECUR.date "(byweekday?), (bymonthday?), (byyearday?), (byweekno?), (bymonth?)">
<!ELEMENT RECUR ((until | count)?), (%rrule.time;), (%rrule.date;), (bysetpos?)>

<!ATTLIST RECUR freq (SECONDLY | MINUTELY | HOURLY | DAILY | WEEKLY | MONTHLY | YEARLY) #REQUIRED>
<!ATTLIST RECUR interval #PCDATA "1" #IMPLIED>
<!ATTLIST RECUR wkst (%attr.weekday;) "MO" #IMPLIED>

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

Philippe Lesage wrote:

> What do you think about it ?
>
> ---------------------------------------------------
> <!ENTITY % attr.recrule "
>         freq CDATA #IMPLIED
>         until CDATA #IMPLIED
>         count CDATA #IMPLIED
>         wkst CDATA #IMPLIED
>         interval CDATA #IMPLIED ">
>
> <!ENTITY % recrule.opt1 " (bysecond?),(byminute?),(byhour?),(byday?),(bymonthday?),(byyearday?),(byweekno?),(bymonth?),(bysetpos?) ">
>
> <!ELEMENT exrule (%recrule.opt1;) >
> <!ATTLIST exrule
>         %attr.recrule;
>         value NOTATION (RECUR) #IMPLIED>
>
> <!ELEMENT rrule (%recrule.opt1;)>
> <!ATTLIST rrule
>         %attr.recrule;
>         value NOTATION (RECUR) #IMPLIED>
>
> <!ELEMENT bysecond (list+)>
>
> <!ELEMENT byminute (list+)>
>
> <!ELEMENT byhour (list+)>
>
> <!ELEMENT byday (daylist+)>
>
> <!ELEMENT bymonthday (list+)>
>
> <!ELEMENT byyearday (list+)>
>
> <!ELEMENT byweekno (list+)>
>
> <!ELEMENT bymonth (list+)>
>
> <!ELEMENT bysetpos (list+)>
>
> <!ELEMENT list (#PCDATA) >
>
> <!ELEMENT daylist (#PCDATA) >
> <!ATTLIST daylist ordwk CDATA #IMPLIED>
>
> --------------------------------------------------------
>

Michael

--
---------------------------------------------------------------
Michael Krivoruchko                 CDE Group, Sun Microsystems
    Bool House, East Point Business Park, Dublin 3, Ireland
Ph: +353 1 819 9272               E-mail: misha@ireland.sun.com
---------------------------------------------------------------




From owner-ietf-calendar  Wed Jan  5 09:08:44 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02460
	for ietf-calendar-bks; Wed, 5 Jan 2000 09:08:44 -0800 (PST)
Received: from mail1.myriad.com ([63.75.14.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA02456
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 09:08:43 -0800 (PST)
Received: from dr.myriad.com by mail1.myriad.com
          via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Jan 2000 17:08:44 UT
Received: from catalina.myriad.com (catalina [10.2.1.17])
	by dr.myriad.com (8.9.2/8.9.2) with ESMTP id KAA05363
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 10:08:43 -0700 (MST)
Received: from myriad.com (dxdh_42 [10.2.4.42])
	by catalina.myriad.com (8.8.8+Sun/8.8.8) with ESMTP id KAA04292
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 10:08:15 -0700 (MST)
Message-ID: <38737B32.511CB91C@myriad.com>
Date: Wed, 05 Jan 2000 10:11:14 -0700
From: Paul Hill <phill@myriad.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
References: <OFFE91350B.0B420BC4-ON8525685D.0049EB2B@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-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Frank_Dawson@lotus.com wrote:
> We are also not assuming the XML iCalendar object would be parsed by a validating parser.

I believe you can always feed an XML document that is highly
specified by some (external) DTD into a non-validating parser regardless of how
specified it is.

-Paul
-- 
Myriad Genetics: http://www.myriad.com/
Java FAQ: http://www.afu.com/javafaq.html (Section 9, Computer Dating)

From owner-ietf-calendar  Wed Jan  5 18:15:41 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11614
	for ietf-calendar-bks; Wed, 5 Jan 2000 18:15:41 -0800 (PST)
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 SAA11608
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 18:15:39 -0800 (PST)
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 VAA16359;
	Wed, 5 Jan 2000 21:30:01 -0500 (EST)
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 VAA11376;
	Wed, 5 Jan 2000 21:12:50 -0500 (EST)
To: Paul Hill <phill@myriad.com>
Cc: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OFD1E7983E.DDDB0856-ON8525685E.000BAF21@Lotus.com>
Date: Wed, 5 Jan 2000 21:16:28 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/05/2000 09:16:30 PM,
	Serialize complete at 01/05/2000 09:16:30 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 000CED718525685E_="
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 000CED718525685E_=
Content-Type: text/plain; charset="us-ascii"

Paul Hill replied:

>Frank_Dawson@lotus.com wrote:
>> We are also not assuming the XML iCalendar object would be parsed by a 
validating parser.

>I believe you can always feed an XML document that is highly
>specified by some (external) DTD into a non-validating parser regardless 
of how
>specified it is.

Of course. This will be the most common case. Few implementations will use 
a validating parser. 
The argument was being made to ignore the standard iCalendar data types 
and recast data types such as RECUR into elaborate XML data structures or 
spreadout over half a dozen attributes. The argument being that one should 
take advantage of the capabilities of an XML parser for structuring data.
My counter argument was that we had well defined, standardized data types 
in the iCalendar specification that any conforming implementation of RFC 
2445 would already be able to parse _and_ the fact that validating parsers 
(that could validate the more complex structuring against the DTD) would 
not be used be used by most implemenations. 

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




<br><font size=3 face="Courier New">Paul Hill replied:</font>
<p>
<br><font size=2 face="Courier New">&gt;Frank_Dawson@lotus.com wrote:<br>
&gt;&gt; We are also not assuming the XML iCalendar object would be parsed by a validating parser.<br>
<br>
&gt;I believe you can always feed an XML document that is highly<br>
&gt;specified by some (external) DTD into a non-validating parser regardless of how<br>
&gt;specified it is.<br>
</font>
<br><font size=3 face="Courier New">Of course. This will be the most common case. Few implementations will use a validating parser. </font>
<p><font size=3 face="Courier New">The argument was being made to ignore the standard iCalendar data types and recast data types such as RECUR into elaborate XML data structures or spreadout over half a dozen attributes. The argument being that one should take advantage of the capabilities of an XML parser for structuring data.</font>
<p><font size=3 face="Courier New">My counter argument was that we had well defined, standardized data types in the iCalendar specification that any conforming implementation of RFC 2445 would already be able to parse _and_ the fact that validating parsers (that could validate the more complex structuring against the DTD) would not be used be used by most implemenations. </font>
<p>
--=_alternative 000CED718525685E_=--

From owner-ietf-calendar  Wed Jan  5 18:20:12 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11993
	for ietf-calendar-bks; Wed, 5 Jan 2000 18:20:12 -0800 (PST)
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 SAA11987
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 18:20:11 -0800 (PST)
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 VAA16506;
	Wed, 5 Jan 2000 21:34:35 -0500 (EST)
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 VAA11588;
	Wed, 5 Jan 2000 21:17:24 -0500 (EST)
To: Michael Krivoruchko <misha@ireland.sun.com>
Cc: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF5D22FA2D.AFF8067E-ON8525685E.000C9AB9@Lotus.com>
Date: Wed, 5 Jan 2000 21:21:02 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/05/2000 09:21:04 PM,
	Serialize complete at 01/05/2000 09:21:05 PM,
	Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/05/2000 09:21:05 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 000D584D8525685E_="
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 000D584D8525685E_=
Content-Type: text/plain; charset="us-ascii"

Michael:
You are missing the point. 
There are already well defined iCalendar data types. We don't need to 
redefine these. 
Creating a more structured on the wire format, that takes more bandwidth 
(both on the wire and to parse), when the originator and recipient already 
understand the IETF standard iCalendar semantics makes not sense.
Unless you are interested in defining a new XML application for 
calendaring.
Which we are not. We already have a single standard for representing 
calendar information and scheduling semantics. Let's leverage it.
-- Frank
--=_alternative 000D584D8525685E_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Michael:</font>
<p><font size=3 face="Courier New">You are missing the point. </font>
<p><font size=3 face="Courier New">There are already well defined iCalendar data types. We don't need to redefine these. </font>
<p><font size=3 face="Courier New">Creating a more structured on the wire format, that takes more bandwidth (both on the wire and to parse), when the originator and recipient already understand the IETF standard iCalendar semantics makes not sense.</font>
<p><font size=3 face="Courier New">Unless you are interested in defining a new XML application for calendaring.</font>
<p><font size=3 face="Courier New">Which we are not. We already have a single standard for representing calendar information and scheduling semantics. Let's leverage it.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 000D584D8525685E_=--

From owner-ietf-calendar  Wed Jan  5 22:02:00 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id WAA23964
	for ietf-calendar-bks; Wed, 5 Jan 2000 22:02:00 -0800 (PST)
Received: from titan.exoffice.com (IDENT:root@host98.ridgeventures.com [207.33.160.98] (may be forged))
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA23960
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 22:01:57 -0800 (PST)
Received: from saria.exoffice.com (IDENT:root@philippe.exoffice.com [24.12.46.59])
	by titan.exoffice.com (8.9.3/8.9.3) with SMTP id WAA28494
	for <ietf-calendar@imc.org>; Wed, 5 Jan 2000 22:56:53 -0800
From: Philippe Lesage <lesage@exoffice.com>
Reply-To: lesage@exoffice.com
Organization: Exoffice
To: ietf-calendar@imc.org
Subject: XML Schema ready
Date: Wed, 5 Jan 2000 20:54:02 -0800
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00010521594200.00655@saria.exoffice.com>
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>


Hi all !

I wrotte an xml schema which is as close as possible from the xml
structure defined by the ICalendar DTD draft. (except for the rrules & exrules... ) 

This is just a first version an it needs to be improved. All comments are
welcome !

http://shuffle.exolab.org/schema.xml  (with netscape, use View Page Source) 

Philippe Lesage
Exoffice Technologies.

From owner-ietf-calendar  Thu Jan  6 09:05:13 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11444
	for ietf-calendar-bks; Thu, 6 Jan 2000 09:05:13 -0800 (PST)
Received: from titan.exoffice.com (host98.ridgeventures.com [207.33.160.98] (may be forged))
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11440
	for <ietf-calendar@imc.org>; Thu, 6 Jan 2000 09:05:12 -0800 (PST)
Received: from saria.exoffice.com (IDENT:root@philippe.exoffice.com [24.12.46.59])
	by titan.exoffice.com (8.9.3/8.9.3) with SMTP id KAA03647
	for <ietf-calendar@imc.org>; Thu, 6 Jan 2000 10:00:07 -0800
From: Philippe Lesage <lesage@exoffice.com>
Reply-To: lesage@exoffice.com
Organization: Exoffice
To: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition 
Date: Thu, 6 Jan 2000 08:58:33 -0800
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00010609025901.00655@saria.exoffice.com>
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>


I think there is basically a contracdiction in your conception of ICal xml : 

You assume that both originator and recipient are RFC2445 compliant. So why
do they use xml to exchange data ? They could just use the regular format.
So from this point of view  xml is totaly useless for calendaring aplication,
and it was a error to write a DTD draft for that.

My point of view is that the xml format can be used when just one of the
originator or recipient is not RFC2445 compliant. And if some data are
not visible at the xml level, the application has to parse the string a second
time. This is obviously the consequence of a bad xml translation. The RFC
grammar use a comma separated list for the bylist, it is straighforward to
convert this in xml by a list of tags.

> 
> Philippe:
> You aren't really serious.

What I wanted to make clear is that the xml visibility limit you are arbitrary
fixing at the datatype level can be fixed at any other level (calendar,
component or property). If you asume that the recipient can parse RFC2445
string format, why not sending him all the data into two <ICalendar> tags ?

Or if you choose the limit to be at the component level then the recipient
would get an xml structure <ICalendar> </ICalendar> containing some <event>,
<todo>, ... , tags . And each component tag would just contain the ICal string
defining the component. 
It is a correct xml embedding and works fine (I mean two RCF2445
compliant application can exchange data this way), but that's totaly pointless. 

> Certainly, there is quite a difference between 
> leveraging standard data types in iCalendar within the XML DTD. A PCDATA 
> content type for these is appropriate. But a PCDATA content type for the 
> whole of the iCalendar object is not an equal argument.
> You seem to be approaching this as a XML application design problem, 
> rather than just a remapping of iCalendar semantics into an alternate 
> syntax. The originator and recipient of these objects are presumed to be 
> iCalendar conformant subsystems.
> We are also not assuming the XML iCalendar object would be parsed by a 
> validating parser. This would be a huge implementation overhead for client 
> environments. The only requirement that seems reasonable is that the XML 
> iCalendar object be well-formed, but not even a valid XML entity. That is, 
> there may not be a XML declaration or prolog/epilog in the entity.
> -- Frank

From owner-ietf-calendar  Thu Jan  6 08:44:30 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11095
	for ietf-calendar-bks; Thu, 6 Jan 2000 08:44:30 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11091
	for <ietf-calendar@imc.org>; Thu, 6 Jan 2000 08:44:29 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14638
	for <ietf-calendar@imc.org>; Thu, 6 Jan 2000 08:44:33 -0800 (PST)
Received: from ireland.sun.com (crimea [129.156.238.50])
	by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id QAA03068
	for <ietf-calendar@imc.org>; Thu, 6 Jan 2000 16:44:31 GMT
Message-ID: <3874C66F.6B5A57F1@ireland.sun.com>
Date: Thu, 06 Jan 2000 16:44:31 +0000
From: Michael Krivoruchko <misha@ireland.sun.com>
Organization: Sun Microsystems Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
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>

Frank:

> You are missing the point.
>

Yes, I definitely do!


> Creating a more structured on the wire format, that takes more bandwidth (both on the
> wire and to parse), when the originator and recipient already understand the IETF
> standard iCalendar semantics makes not sense.
>

I can not see a reason to use XML if those documents are readable only for tools
which know about iCalendar data types. The iCalendar tool can always read
RFC2445-document so it needs not "optional"(draft-many-ical-xmldoc-01.txt
p 2.3.2) XML.


> Unless you are interested in defining a new XML application for calendaring.
>
> Which we are not. We already have a single standard for representing calendar
> information and scheduling semantics. Let's leverage it.
>

It sounds like you are ready to discuss cosmetic details of the document cover,
but you would not discuss the concept of the document.
I am not interested in "a new XML application for calendaring". Only things I am
talking about are more detailed XML representation of the data types defined in
RFC2445 and XML grammar which more adequate to grammar defined in the
same RFC2445.

Michael

--
---------------------------------------------------------------
Michael Krivoruchko                 CDE Group, Sun Microsystems
    Bool House, East Point Business Park, Dublin 3, Ireland
Ph: +353 1 819 9272               E-mail: misha@ireland.sun.com
---------------------------------------------------------------




From owner-ietf-calendar  Thu Jan  6 10:38:32 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12630
	for ietf-calendar-bks; Thu, 6 Jan 2000 10:38:32 -0800 (PST)
Received: from mail1.myriad.com ([63.75.14.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA12626
	for <ietf-calendar@imc.org>; Thu, 6 Jan 2000 10:38:31 -0800 (PST)
Received: from dr.myriad.com by mail1.myriad.com
          via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Jan 2000 18:38:37 UT
Received: from catalina.myriad.com (catalina [10.2.1.17])
	by dr.myriad.com (8.9.2/8.9.2) with ESMTP id LAA00159
	for <ietf-calendar@imc.org>; Thu, 6 Jan 2000 11:38:37 -0700 (MST)
Received: from myriad.com (dxdh_42 [10.2.4.42])
	by catalina.myriad.com (8.8.8+Sun/8.8.8) with ESMTP id LAA13174
	for <ietf-calendar@imc.org>; Thu, 6 Jan 2000 11:38:07 -0700 (MST)
Message-ID: <3874E1C5.E464782D@myriad.com>
Date: Thu, 06 Jan 2000 11:41:09 -0700
From: Paul Hill <phill@myriad.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
References: <OF5D22FA2D.AFF8067E-ON8525685E.000C9AB9@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-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Frank_Dawson@lotus.com wrote:
> Creating a more structured on the wire format, that takes more bandwidth (both 
> on the wire and to parse), when the originator and recipient already understand
> the IETF standard iCalendar semantics makes not sense.

Yes, a more wordy, more structured format has the disadvantage that it does 
take more space to store and transmit. I would think that the time and 
space it takes to parse would be comparable.  The advantage is that
these apparently excessive markings helps apps that never have heard of
iCalendar to deal with calendar information.

> Unless you are interested in defining a new XML application for calendaring.

While iCalendar is more optimized for communication between
general purpose calendar user agents and between calendar systems,
the advantage of defining a translation to an alternate, but more 
general (yet verbose) XML compliant format, is that this alternate format
can be used where applicable to solve _additional_ problems outside of
'normal' calendaring. It is the potential to work with the data elsewhere that
drives a desire for an XML form of iCalendar. XML applications
parsing libraries, books etc. already exist and are being written as we speak, 
all they need is a DTD to drive them.  These include XML aware browsers,
XML viewers, multiple general purpose parsing libraries (each with a different
power), XML utilities, and maybe even XML editors.

The simplest gain might come from the use of the power and features
of the existing general purpose applications that could be leverage by
having a well-defined and detailed as possible XML mapping.

A second and potentially larger gain might come from the the
creation of additional tools, utilities, calendar agents, by anyone 
who understands and uses the more general purpose XML/DTD formats, because
this larger community could create other uses for calendar data.

An incidental, but more immediate gain, for the iCalendar standard 
and its users is that the technical problem of converting between two well 
defined detailed forms helps to identify any ambiguity which exists in the
interpretation of either form.

-Paul
----
Myriad Genetics: http://www.myriad.com/
Java FAQ: http://www.afu.com/javafaq.html (Section 9, Computer Dating)

From owner-ietf-calendar  Fri Jan  7 08:46:38 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA09917
	for ietf-calendar-bks; Fri, 7 Jan 2000 08:46:38 -0800 (PST)
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 IAA09913
	for <ietf-calendar@imc.org>; Fri, 7 Jan 2000 08:46:37 -0800 (PST)
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 MAA28537;
	Fri, 7 Jan 2000 12:01:12 -0500 (EST)
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 LAA26894;
	Fri, 7 Jan 2000 11:43:57 -0500 (EST)
To: Michael Krivoruchko <misha@ireland.sun.com>
Cc: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
X-Mailer: Lotus Notes Build V5010624 June 24, 1999
Message-ID: <OF6EB05DC1.A3D71FF5-ON8525685F.0054D48A@Lotus.com>
Date: Fri, 7 Jan 2000 11:47:09 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/07/2000 11:47:10 AM,
	Serialize complete at 01/07/2000 11:47:10 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005CBA088525685F_="
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 005CBA088525685F_=
Content-Type: text/plain; charset="us-ascii"

Michael:
I agree with you (and so has the mailing list) that the alternative XML 
representation for standard iCalendar doesn't make much sense, since 
conformant iCalendar products will understand the standard format. After 
all, multiple representations will present interoperability problems. We 
may want to take this to a XML iCalendar mailing list. I can ask IMC if 
they would host this.
However, the market hype around XML hasn't dissipated it's fervor, either.
This led a number of folks (myself, Doug Royer and Surendra Reddy) to 
craft the XML iCalendar DTD I-D. However, given the rabid interest in XML 
we put down some design principles to this work. 
Some of the recent discussion has crossed some of these principles, 
including the idea to redefine the basic iCalendar data types.
This just doesn't make sense. No one would think about redefining in XML 
the RFC822 address data type (i.e., "MAILTO:" local part "@" domain part). 
After all this is a part of an IETF standard. Like wise, it doesn't make 
much sense to create new formats for already existing proposed standards 
for iCalendar data model components.
See what I mean?
-- Frank

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




<br><font size=3 face="Courier New">Michael:</font>
<p><font size=3 face="Courier New">I agree with you (and so has the mailing list) that the alternative XML representation for standard iCalendar doesn't make much sense, since conformant iCalendar products will understand the standard format. After all, multiple representations will present interoperability problems. We may want to take this to a XML iCalendar mailing list. I can ask IMC if they would host this.</font>
<p><font size=3 face="Courier New">However, the market hype around XML hasn't dissipated it's fervor, either.</font>
<p><font size=3 face="Courier New">This led a number of folks (myself, Doug Royer and Surendra Reddy) to craft the XML iCalendar DTD I-D. However, given the rabid interest in XML we put down some design principles to this work. </font>
<p><font size=3 face="Courier New">Some of the recent discussion has crossed some of these principles, including the idea to redefine the basic iCalendar data types.</font>
<p><font size=3 face="Courier New">This just doesn't make sense. No one would think about redefining in XML the RFC822 address data type (i.e., &quot;MAILTO:&quot; local part &quot;@&quot; domain part). After all this is a part of an IETF standard. Like wise, it doesn't make much sense to create new formats for already existing proposed standards for iCalendar data model components.</font>
<p><font size=3 face="Courier New">See what I mean?</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 005CBA088525685F_=--

From owner-ietf-calendar  Fri Jan  7 13:44:21 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13156
	for ietf-calendar-bks; Fri, 7 Jan 2000 13:44:21 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13152
	for <ietf-calendar@imc.org>; Fri, 7 Jan 2000 13:44:17 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16507;
	Fri, 7 Jan 2000 13:44:27 -0800 (PST)
Received: from ireland.sun.com (crimea [129.156.238.50])
	by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id VAA25842;
	Fri, 7 Jan 2000 21:44:25 GMT
Message-ID: <38765E38.24C87BD3@ireland.sun.com>
Date: Fri, 07 Jan 2000 21:44:25 +0000
From: Michael Krivoruchko <misha@ireland.sun.com>
Organization: Sun Microsystems Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
Content-Type: text/plain; charset=UTF-8
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>

Frank:


> I agree with you (and so has the mailing list) that the alternative XML representation for standard
> iCalendar doesn't make much sense, since conformant iCalendar products will understand the standard
> format. After all, multiple representations will present interoperability problems. We may want to take this
> to a XML iCalendar mailing list. I can ask IMC if they would host this.
>

Probably no one CUA will use XML to talk CS. Why we need additional
coding for the same functionality which we have got from iCalendar native
data format parser anyway. More over, you are right, the interoperability
issues could rise.


> This just doesn't make sense. No one would think about redefining in XML the RFC822 address data
> type (i.e., "MAILTO:" local part "@" domain part). After all this is a part of an IETF standard. Like wise,
> it doesn't make much sense to create new formats for already existing proposed standards for iCalendar
> data model components.
>

Surprise! I need such kind of decomposition of URL. Why? Users are lazy.
They type only "local part" and press "Send" button. Than mailer has to
parse the address and find out is it complete. We can receive the same
result using XML parser for nothing:
<MAILTO><local-part>misha</local-part></MAILTO>

The question is: When to stop? It is possible to represent an integer as
an array of digits. It does not sounds good even to me. ;-)

Seriously. XML without native iCalendar data types could be quite useful
when CU want to save something (event, to-do,...) locally in a file and than
use some non-iCalendar XML tool to add these data, say, to weekly report.
Such scenario sounds to me quite possible, but "save as..." is CUA
functionality and, perhaps, you are right, it should not be discussed here.
Only thing I am worry about is: each CUA will define own DTD for iCalendar
data.

Michael

--
---------------------------------------------------------------
Michael Krivoruchko                 CDE Group, Sun Microsystems
    Bool House, East Point Business Park, Dublin 3, Ireland
Ph: +353 1 819 9272               E-mail: misha@ireland.sun.com
---------------------------------------------------------------




From owner-ietf-calendar  Sat Jan  8 23:59:57 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA03043
	for ietf-calendar-bks; Sat, 8 Jan 2000 23:59:57 -0800 (PST)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03039
	for <ietf-calendar@imc.org>; Sat, 8 Jan 2000 23:59:55 -0800 (PST)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA21732
	for ietf-calendar@imc.org; Sun, 9 Jan 2000 00:00:03 -0800 (PST)
Date: Sun, 9 Jan 2000 00:00:03 -0800 (PST)
From: Doug Royer <Doug@Royer.Com>
Message-Id: <200001090800.AAA21732@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  Sun Jan  9 23:34:50 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA00502
	for ietf-calendar-bks; Sun, 9 Jan 2000 23:34:50 -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 XAA00498
	for <ietf-calendar@imc.org>; Sun, 9 Jan 2000 23:34:49 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id XAA21662
	for <ietf-calendar@imc.org>; Sun, 9 Jan 2000 23:35:10 -0800 (PST)
Message-ID: <38798BA5.917D8F6B@home.royer.com>
Date: Sun, 09 Jan 2000 23:35:01 -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: XML DTD update proposition
References: <OF053DBE45.3B56E1ED-ON8525685B.005046DB@Lotus.com> <0001041822310A.00697@saria.exoffice.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF914FF377866CEBD644A89C6"
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.

--------------msF914FF377866CEBD644A89C6
Content-Type: multipart/mixed;
 boundary="------------389BB734DED745F683BAB7C9"

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

Philippe Lesage wrote:
> 
> >
> > Philippe:
> > You point out an interesting design point. That is, is the iCalendar XML
> > DTD intended to be an XML object for calendars or an alternate XML
> > representation for the standard iCalendar format?
> > We don't need two standard calendar formats, if at all possible. This
> > effort is definitely not an attempt to define a new calendar format. It is
> > not an effort to define a new calendar XML application, based on
> > iCalendar. I think you would agree.
> > There is but one standard IETF calendar format. That is iCalendar, defined
> > by RFC2445. Hence, this format is an alternative XML representation for
> > iCalendar. As such, an implementation will already understand iCalendar
> > data types. The recurrence grammar is one of these dozen or so standard
> > iCalendar data types. It is called RECUR.
> > So, any valid iCalendar implementation (including one that understands a
> > new alternative XML representation) will already have support for the
> > standard iCalendar data types.
> 
> Ok, but it is not a valid reason for preventing the DTD from describing the
> data types internal structure.

So what is the point? It seems to me that you are saying you really don't
want to work on iCalendar and add what you think is needed. You just 
want to work with XML? iCalendar is this groups work.

> You imply that the DTD could just have one single element :
> <!ELEMENT iCalendar (#PCDATA) >
> Any valid ICal implementation should be able to understand this string....
> 
> >There is no need to make interpretation of
> > a XML representation of an iCalendar object any harder or more complex for
> > an iCalendar implementation.
> 
> I don't think so. In fact, all this work is done by your favorite xml parser.

Except when you wish to exchange the data with an iCalendar tool. What
do you do with the extra data?
--------------389BB734DED745F683BAB7C9
Content-Type: text/x-vcard; charset=us-ascii;
 name="doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="doug.vcf"

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

--------------389BB734DED745F683BAB7C9--

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

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
ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTEwMDczNTAzWjAjBgkqhkiG9w0BCQQxFgQUiy0lJUek
Uly3ucQIyR+OpHBEUMUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYC4VQv2c/EmEVRynPODok/nvDQsBmPZY4ON+RLQ/jCWqBc7fUSpQyTEP0mGJPqI
L4ax+mvEy9vc3hSsuZRal6zCstXr3Ty2gM31exQWG2fV69CynuTSrgT2YngVQuoK3FvyuzRy
b4fRQ4t14ynLiW1vpoGW3CPUI2oZundxgY3d3A==
--------------msF914FF377866CEBD644A89C6--


From owner-ietf-calendar  Mon Jan 10 01:37:48 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id BAA01831
	for ietf-calendar-bks; Mon, 10 Jan 2000 01:37:48 -0800 (PST)
Received: from titan.exoffice.com (IDENT:root@host98.ridgeventures.com [207.33.160.98] (may be forged))
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01824
	for <ietf-calendar@imc.org>; Mon, 10 Jan 2000 01:37:47 -0800 (PST)
Received: from saria.exoffice.com (IDENT:root@philippe.exoffice.com [24.12.46.59])
	by titan.exoffice.com (8.9.3/8.9.3) with SMTP id BAA00361
	for <ietf-calendar@imc.org>; Mon, 10 Jan 2000 01:41:14 -0800
From: Philippe Lesage <lesage@exoffice.com>
Reply-To: lesage@exoffice.com
Organization: Exoffice
To: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
Date: Mon, 10 Jan 2000 01:02:10 -0800
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <OF053DBE45.3B56E1ED-ON8525685B.005046DB@Lotus.com> <0001041822310A.00697@saria.exoffice.com> <38798BA5.917D8F6B@home.royer.com>
In-Reply-To: <38798BA5.917D8F6B@home.royer.com>
MIME-Version: 1.0
Message-Id: <00011001354900.00648@saria.exoffice.com>
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>



>> 
>> >
>> > Philippe:
>> > You point out an interesting design point. That is, is the iCalendar XML
>> > DTD intended to be an XML object for calendars or an alternate XML
>> > representation for the standard iCalendar format?
>> > We don't need two standard calendar formats, if at all possible. This
>> > effort is definitely not an attempt to define a new calendar format. It is
>> > not an effort to define a new calendar XML application, based on
>> > iCalendar. I think you would agree.
>> > There is but one standard IETF calendar format. That is iCalendar, defined
>> > by RFC2445. Hence, this format is an alternative XML representation for
>> > iCalendar. As such, an implementation will already understand iCalendar
>> > data types. The recurrence grammar is one of these dozen or so standard
>> > iCalendar data types. It is called RECUR.
>> > So, any valid iCalendar implementation (including one that understands a
>> > new alternative XML representation) will already have support for the
>> > standard iCalendar data types.
>> 
>> Ok, but it is not a valid reason for preventing the DTD from describing the
>> data types internal structure.
>
>So what is the point? It seems to me that you are saying you really don't
>want to work on iCalendar and add what you think is needed. You just 
>want to work with XML? iCalendar is this groups work.
>

As Paul & Michael explained it better than me, other non iCalendar application
might need to exchange data with a XML compliant calendaring server. So
it is really a problem for them if they can't see the RECUR datatype internal
structure for example. The XML representation is for me usefull is only one
case : exchange with non ICal application.

I think it is really an opportunity for this group to define a good Ical
xml format which can be used by any xml aware application. It is just too bad
that each one defines it's one DTD or schema. In this case, everyone lose.

>> You imply that the DTD could just have one single element :
>> <!ELEMENT iCalendar (#PCDATA) >
>> Any valid ICal implementation should be able to understand this string....
>> 
>> >There is no need to make interpretation of
>> > a XML representation of an iCalendar object any harder or more complex for
>> > an iCalendar implementation.
>> 
>> I don't think so. In fact, all this work is done by your favorite xml parser.
>
>Except when you wish to exchange the data with an iCalendar tool. What
>do you do with the extra data?

From owner-ietf-calendar  Mon Jan 10 06:26:36 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA07750
	for ietf-calendar-bks; Mon, 10 Jan 2000 06:26:36 -0800 (PST)
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 GAA07746
	for <ietf-calendar@imc.org>; Mon, 10 Jan 2000 06:26:35 -0800 (PST)
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 JAA05816;
	Mon, 10 Jan 2000 09:41:16 -0500 (EST)
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 JAA25692;
	Mon, 10 Jan 2000 09:24:32 -0500 (EST)
To: lesage@exoffice.com
Cc: ietf-calendar@imc.org
Subject: Re: XML DTD update proposition
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF577ED2C6.CD8B36B6-ON85256862.004EB627@Lotus.com>
Date: Mon, 10 Jan 2000 09:27:35 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/10/2000 09:27:39 AM,
	Serialize complete at 01/10/2000 09:27:39 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 004FFCE285256862_="
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 004FFCE285256862_=
Content-Type: text/plain; charset="us-ascii"

Philippe Lesage wrote in part:
>As Paul & Michael explained it better than me, other non iCalendar 
application
>might need to exchange data with a XML compliant calendaring server. So
>it is really a problem for them if they can't see the RECUR datatype 
internal
>structure for example. The XML representation is for me usefull is only 
one
>case : exchange with non ICal application.

This argument is very faulted. If we generalize your argument, then you 
say that you don't accept any data type unless your DTD defines it. After 
all, you don't seem to like accepting the iCalendar RECUR data type as a 
PCDATA entity. Extending this argument, you are telling me that you 
couldn't accept any other standard data types passed in a PCDATA element 
type's content information. I just don't buy this line of reasoning. In 
fact, there are many efforts underway to standardize schema and data types 
that would be passed in PCDATA content model, but that if you support 
these standard types your application would have to have secondary parsers 
for.
Well, for calendaring and scheduling information, iCalendar is the 
standard. It defines about a dozen data types that are used in the 
iCalendar model. It only makes sense to leverage the large investment made 
by the IETF CALSCH WG in any XML DTD for C&S also rather than arbitrarily 
defining new data types that strike the fancy of the new DTD designer.
I think that this on redefinition of data types is complete. The consensus 
of the WG was (in past discussions) to leverage as much of iCalendar as 
possible to create the iCalendar XML DTD. You haven't raised any new 
arguments.
Thanks for the open discussion but lets keep the use of the standard 
iCalendar data types. The date/time datums are also based on ISO standards 
for date and time that are being adopted across the industry, albeit the 
more terse "basic" format of ISO 8601.
Some of your other comments for improving the DTD are valid and will be 
incorporated.
-- Frank

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




<br><font size=3 face="Courier New">Philippe Lesage wrote in part:</font>
<p><font size=2 face="Courier New">&gt;As Paul &amp; Michael explained it better than me, other non iCalendar application<br>
&gt;might need to exchange data with a XML compliant calendaring server. So<br>
&gt;it is really a problem for them if they can't see the RECUR datatype internal<br>
&gt;structure for example. The XML representation is for me usefull is only one<br>
&gt;case : exchange with non ICal application.</font>
<br>
<br><font size=3 face="Courier New">This argument is very faulted. If we generalize your argument, then you say that you don't accept any data type unless your DTD defines it. After all, you don't seem to like accepting the iCalendar RECUR data type as a PCDATA entity. Extending this argument, you are telling me that you couldn't accept any other standard data types passed in a PCDATA element type's content information. I just don't buy this line of reasoning. In fact, there are many efforts underway to standardize schema and data types that would be passed in PCDATA content model, but that if you support these standard types your application would have to have secondary parsers for.</font>
<p><font size=3 face="Courier New">Well, for calendaring and scheduling information, iCalendar is the standard. It defines about a dozen data types that are used in the iCalendar model. It only makes sense to leverage the large investment made by the IETF CALSCH WG in any XML DTD for C&amp;S also rather than arbitrarily defining new data types that strike the fancy of the new DTD designer.</font>
<p><font size=3 face="Courier New">I think that this on redefinition of data types is complete. The consensus of the WG was (in past discussions) to leverage as much of iCalendar as possible to create the iCalendar XML DTD. You haven't raised any new arguments.</font>
<p><font size=3 face="Courier New">Thanks for the open discussion but lets keep the use of the standard iCalendar data types. The date/time datums are also based on ISO standards for date and time that are being adopted across the industry, albeit the more terse &quot;basic&quot; format of ISO 8601.</font>
<p><font size=3 face="Courier New">Some of your other comments for improving the DTD are valid and will be incorporated.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 004FFCE285256862_=--

From owner-ietf-calendar  Tue Jan 11 07:48:03 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA01929
	for ietf-calendar-bks; Tue, 11 Jan 2000 07:48:03 -0800 (PST)
Received: from klaymen.rim.net (mail.rim.net [206.51.26.155])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01925
	for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 07:48:01 -0800 (PST)
Received: from SMTP (navieg1.rim.net [192.17.64.254])
	by klaymen.rim.net (8.9.3/8.9.1) with SMTP id KAA01917
	for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 10:48:16 -0500
Received: from lightning.rim.net ([192.17.64.45]) by 192.17.64.254
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 11 Jan 2000 15:46:22 0000 (GMT)
Received: by lightning.rim.net with Internet Mail Service (5.5.2448.0)
	id <CP91K925>; Tue, 11 Jan 2000 10:48:15 -0500
Message-ID: <E05B69D6CB8ED21185A10000F8020E5301C03E24@lightning.rim.net>
From: Antony Davies <adavies@rim.net>
To: "'ietf-calendar@imc.org'" <ietf-calendar@imc.org>
Subject: RFC2445 section 4.8.6.3
Date: Tue, 11 Jan 2000 10:48:14 -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>

Should the line
trigger = "TRIGGER" (trigrel / trigabs) ^M
read
trigger = "TRIGGER" (trigrel/trigabs) CRLF^M

Thanks,

-------------------------------------
Antony Davies,
Software, Research In Motion
adavies@rim.net



From owner-ietf-calendar  Tue Jan 11 09:24:58 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03356
	for ietf-calendar-bks; Tue, 11 Jan 2000 09:24:58 -0800 (PST)
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 JAA03352
	for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 09:24:56 -0800 (PST)
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 MAA16237;
	Tue, 11 Jan 2000 12:39:54 -0500 (EST)
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 MAA24087;
	Tue, 11 Jan 2000 12:07:27 -0500 (EST)
To: Antony Davies <adavies@rim.net>
Cc: ietf-calendar@imc.org
Subject: Re: RFC2445 section 4.8.6.3
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF4D97132E.0C60FB38-ON85256863.005E35D2@Lotus.com>
Date: Tue, 11 Jan 2000 12:10:02 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/11/2000 12:10:04 PM,
	Serialize complete at 01/11/2000 12:10:04 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005EDED085256863_="
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 005EDED085256863_=
Content-Type: text/plain; charset="us-ascii"

Yes! The ABNF needs the CRLF sequence added. Thank you for the errata. 
Will update and repost the spec as an I-D.
Keep those review comments coming in!
-- Frank

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




<br><font size=3 face="Courier New">Yes! The ABNF needs the CRLF sequence added. Thank you for the errata. Will update and repost the spec as an I-D.</font>
<p><font size=3 face="Courier New">Keep those review comments coming in!</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 005EDED085256863_=--

From owner-ietf-calendar  Tue Jan 11 12:19:51 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05793
	for ietf-calendar-bks; Tue, 11 Jan 2000 12:19:51 -0800 (PST)
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 MAA05789
	for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 12:19:50 -0800 (PST)
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 PAA06091
	for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 15:34:51 -0500 (EST)
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 PAA18730
	for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 15:18:46 -0500 (EST)
Subject: CalConnect Plans
To: ietf-calendar@imc.org
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OFB756EC4C.BFC09195-ON85256863.006FB891@Lotus.com>
Date: Tue, 11 Jan 2000 15:21:17 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/11/2000 03:21:19 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
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>

Folks:
What are the plans for the CalConnect? Is this still planned for February?

-- Frank



From owner-ietf-calendar  Tue Jan 11 17:07:36 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id RAA09909
	for ietf-calendar-bks; Tue, 11 Jan 2000 17:07:36 -0800 (PST)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09905
	for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 17:07:35 -0800 (PST)
Received: from Software.com ([207.175.94.144]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <20000112010736.FNNF4647450.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 19:07:36 -0600
Message-ID: <387BD3AF.EC7A1F38@Software.com>
Date: Tue, 11 Jan 2000 17:06:55 -0800
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: New Topic: Export of calendar data and metadata
References: <OF2A4CB9AA.D967D921-ON85256810.004C572A@com> <380DDCAA.CF4AD140@ms.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms97A31D930FCD5A1F7EC7CCC4"
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.

--------------ms97A31D930FCD5A1F7EC7CCC4
Content-Type: multipart/mixed;
 boundary="------------2DCF1DEF86BF593BFA130EEF"

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



David Madeo wrote:
> 
> 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.

I agree, it should be possible for an administrative or super user account
to fetch everything - given a VCAR. Or to set anything - given a VCAR.

We would also need to explain that there would not be any kind if CS
supported incremental backup or restore. That would be up to a custom
CUA (or any CUA) to merge/mix/delete with a users help.  I see this part
of backup the same as disconnected/reconnected issues.
--------------2DCF1DEF86BF593BFA130EEF
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"

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

--------------2DCF1DEF86BF593BFA130EEF--

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

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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjAxMDY1NlowIwYJKoZIhvcNAQkEMRYEFNEE
3NEEOHu5JtUW/FH71l+ZpV8SMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAd675VnGixpbSGM7iuNy1Rm/YOh3tVQTE+AGPtPdg2zxxsHBixy3WkAe9
9oIOCeDQLNwG/6DR7LHjpihi6uKHmeXXBlPweE2P4oLSearQAQGk5d04uo3ao2MtALA/Bthr
RNfNUs0xjr+99mqVT+6n6MmskuL3MWcVYK24cMsYISA=
--------------ms97A31D930FCD5A1F7EC7CCC4--


From owner-ietf-calendar  Tue Jan 11 16:55:11 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id QAA09677
	for ietf-calendar-bks; Tue, 11 Jan 2000 16:55:11 -0800 (PST)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09673
	for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 16:55:09 -0800 (PST)
Received: from Software.com ([207.175.94.144]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <20000112005510.FNKK4647450.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 18:55:10 -0600
Message-ID: <387BD0C5.F849910D@Software.com>
Date: Tue, 11 Jan 2000 16:54:29 -0800
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: <OFE42705A3.784833BB-ON85256810.00529132@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEA48C6DBAB54887547F5B1CF"
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.

--------------msEA48C6DBAB54887547F5B1CF
Content-Type: multipart/mixed;
 boundary="------------5231E40C72AF3EE718BF8506"

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



Bruce_Kahn@iris.com wrote:
> 
> 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. 
> ...
> 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! ;^) )


Okay - now you wish to administer the VCAR for a user-list(group). If it
is not expanded by the CS how will you ever find who is on the list?
Or as some have expressed, how to find out if you have permission to
do something.

I don't see any difference between a VCAR for one or many (huge) number of
users. As in:

	(1) They have access or not to whatever the VCAR specifies.

	(2) They have read access to the VCAR or not.

The only issue as I see it is how do you administer the list
and MUST or MAY it be expanded dynamically to a CUA.

A specific implementation my allow dynamic lists (LDAP or whatever).
There still needs to be an interoperable way to find out who is on a
dynamic list. That can be done with or without CAP (LDAP Tool for example).

I assert that if you are a CAP client:

	(A) And you have access to read the VCAR, then the expansion
	    must be possible (Assuming you have permission and it is
	    not a violation of site administrative policy) Otherwise you
	    would be requiring all CUAs to understand all dynamic list
	    implementations - Not possible.

	    preposal:

		(A.1) If the CS is unable or unwilling to expand the
		      list, OR the CS administrator has elected not to
		      allow list expansion:

			Then return as the VCAR something like this IF
			they happen to be a MEMBER of the LIST and
			were GRANTed or DENYed access the the CS would
			dynamicly create a wire VCAR into:

				BEGIN:VCAR
				CARID:Permisssions for group 'A'
				GRANT;MEMBER=<group-name>:< Querying-CU's-UPN>
				END:VCAR

			Or:

				BEGIN:VCAR
				CARID:Permisssions for group 'A'
				DENY;MEMBER=<group-name>:< Querying-CU's-UPN>
				END:VCAR

			Because ether way there would have to be a unique
			ID for the group name and they simply would or would
			not have access to the resource specified by
			that VCAR.

			Then a CUA WOULD be able to determine in advance
			if the CU had permission for an operation without
			dynamic list expansion.  Determinable by a MEMBER=GROUP
			parameter to GRANT or DENY.
		
		(A.2) If the CS can show some CUA the list, then it 
		      could be sent as:

				BEGIN:VCAR
				CARID:Permisssions for group 'A'
				GRANT;GROUP=<foogroup>:UPN=<...>
				...
				DENY;GROUP=<foogroup>:UPN=<...>
				...
				END:VCAR

		OR

				As in (A.1)

	(B) If you do NOT have access to read the VCAR, the answer of
	    how to show them is irrelevant.


I think this addresses all of the issues. I do not think that we should
define a way to administer user-group-lists. And I do not think that
we can mandate that CUA's or CS's  MUST have user-group-lists.
We could mandate that a CUA understand what a GROUP= parameter in
a GRANT or DENY means there may be more users that are not determinable
to the CUA.
--------------5231E40C72AF3EE718BF8506
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"

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

--------------5231E40C72AF3EE718BF8506--

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

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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjAwNTQzMFowIwYJKoZIhvcNAQkEMRYEFHOV
IggqORDC/+99BpIRrifBXFzgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGATTd2FgLaP8anjkAh81Y1h4Rsx52oZVs5v+hnzoKb1gS1hOPcgrnrt/TU
T3gmJW5uHot4UdzIzs1wergUOX61/rp+pWREmcMlXE7J7Yf8LDRG5AyWrQaoviD37TEDSY7h
nTNNGkmV9sTcQp8t3maABRUWJMUSnzk35hXt+s/8aLU=
--------------msEA48C6DBAB54887547F5B1CF--


From owner-ietf-calendar  Tue Jan 11 17:14:17 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id RAA09993
	for ietf-calendar-bks; Tue, 11 Jan 2000 17:14:17 -0800 (PST)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09989
	for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 17:14:16 -0800 (PST)
Received: from Software.com ([207.175.94.144]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <20000112011417.FNOY4647450.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Tue, 11 Jan 2000 19:14:17 -0600
Message-ID: <387BD540.374BB9A4@Software.com>
Date: Tue, 11 Jan 2000 17:13:36 -0800
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: queries for unbounded recurring components
References: <OF9E42AD7F.C0D79E55-ON85256810.0063CDF6@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms35360E07EA2B2696B970F636"
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.

--------------ms35360E07EA2B2696B970F636
Content-Type: multipart/mixed;
 boundary="------------79333BB6841B3CD25F04FAEF"

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



Bruce_Kahn@iris.com wrote:
> 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"?

I think we discussed this already.

As for components between dates (give me >= January && < Febuary).

The logic (as I recall) was:

	TIME-1:		CUA-1 asks for the 1st 3 after date.

	TIME-2:		CUA-2 inserts 1 new entry BEFORE the original.
				      1 new after the original 1st entry.

	TIME-3:		CUA-1 asks for (in what ever way) the next 3.

			What do you return? Do you notify them that
			some are new and they did not get them?

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

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

--------------79333BB6841B3CD25F04FAEF--

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

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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjAxMTMzN1owIwYJKoZIhvcNAQkEMRYEFJyD
bzEk9xdR+87FoY6X+t++7Z3mMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAlZD0bR4rv2BJnjXD+GIvA+sIFfzmeqYKOGY61XVvt/KL5t6PcorjgtNx
uKZbRb/ZkRGorg+VaYo8pBpOcGan1i7JFx0sgC1g05sdyNItfW65XP7l1bVRIK7u3BjQ2o3T
WVqI+u5RE+1U4LWfIQxImqRpPKEhlitT7bNjcrtg7Qg=
--------------ms35360E07EA2B2696B970F636--


From owner-ietf-calendar  Wed Jan 12 06:57:52 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16311
	for ietf-calendar-bks; Wed, 12 Jan 2000 06:57:52 -0800 (PST)
Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16307
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 06:57:51 -0800 (PST)
Received: from ANAND ([209.110.75.185])
	by smtp7.atl.mindspring.net (8.9.3/8.8.5) with SMTP id JAA16592
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 09:58:25 -0500 (EST)
Message-ID: <002601bf5d0d$a2030c50$b94b6ed1@ANAND>
From: "Anand Sancheti" <anand@fortek.com>
To: <ietf-calendar@imc.org>
Subject: 
Date: Wed, 12 Jan 2000 09:59:31 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01BF5CE3.B8C51AC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.5600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600
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_0023_01BF5CE3.B8C51AC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Unsubscribe

------=_NextPart_000_0023_01BF5CE3.B8C51AC0
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.3800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Unsubscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0023_01BF5CE3.B8C51AC0--


From owner-ietf-calendar  Wed Jan 12 06:58:22 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16336
	for ietf-calendar-bks; Wed, 12 Jan 2000 06:58:22 -0800 (PST)
Received: from teamsoft.com ([207.134.168.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16331
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 06:58:17 -0800 (PST)
Received: from [207.134.168.55]
	by teamsoft.com (FirstClass Mail Server v5.50) with SMTP
	transient id 70; Tue, 11 Jan 2000 10:07:24 -0500
X-Sender: fortin@teamsoft.com
Message-Id: <v01530500b4a24734e85e@[207.134.168.55]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Jan 2000 10:05:57 -0500
To: Doug.Royer@software.com (Doug.Royer@software.com)
From: fortin@teamsoft.com (Gilles Fortin)
Subject: Re: New Topic: Export of calendar data and metadata
Cc: ietf-calendar@imc.org
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 an issue that does not seem to me to have been properly addressed:
exporting holiday data. For interoperability it will be useful to
import/export holiday data.
This type of data is usually stored at the CS level and pertains to all its
users. Let's think of a school, which will follow national holidays, state
holidays, school board holiday and eventually special school events... Does
the iCalendar model take this into account?


>David Madeo wrote:
>>>
>>> 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.
>
>I agree, it should be possible for an administrative or super user account
>to fetch everything - given a VCAR. Or to set anything - given a VCAR.
>
>We would also need to explain that there would not be any kind if CS
>supported incremental backup or restore. That would be up to a custom
>CUA (or any CUA) to merge/mix/delete with a users help.  I see this part
>of backup the same as disconnected/reconnected issues.
>
>
>Content-Type: application/octet-stream; name="Doug.Royer.vcf"
>Content-Disposition: attachment; filename="Doug.Royer.vcf"
>
>Attachment converted: HD:Doug.Royer.vcf 16 (????/----) (00025796)
>Content-Type: application/octet-stream; name="smime.p7s"
>Content-Disposition: attachment; filename="smime.p7s"
>
>Attachment converted: HD:smime.p7s 9 (????/----) (00025797)

Gilles Fortin, Founder & President
__________________________________
Teamsoft Inc.
50 Queen, #304
Montreal, Canada H3C 2N5
+514-875-2231x106    fax:+514-875-2401
Internet: fortin@teamsoft.com    Web: http://teamsoft.com 



From owner-ietf-calendar  Wed Jan 12 07:45:18 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17018
	for ietf-calendar-bks; Wed, 12 Jan 2000 07:45:18 -0800 (PST)
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 HAA17014
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 07:45:17 -0800 (PST)
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 LAA03532;
	Wed, 12 Jan 2000 11:00:22 -0500 (EST)
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 KAA06613;
	Wed, 12 Jan 2000 10:44:48 -0500 (EST)
To: fortin@teamsoft.com (Gilles Fortin)
Cc: ietf-calendar@imc.org
Subject: Re: New Topic: Export of calendar data and metadata
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF08C0531B.2E2F4871-ON85256864.00568637@Lotus.com>
Date: Wed, 12 Jan 2000 10:46:58 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/12/2000 10:47:01 AM,
	Serialize complete at 01/12/2000 10:47:01 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0057479485256864_="
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 0057479485256864_=
Content-Type: text/plain; charset="us-ascii"

Gilles:
In the iCalendar/iTIP/iMIP work that I have been doing with Lotus 
Notes/Domino, one of the first examples we did was to create an iCalendar 
object for import/export demonstration that contained all the Company 
Holidays in it.
Yes, the iCalendar data model handles such cases.
-- Frank


--=_alternative 0057479485256864_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Gilles:</font>
<p><font size=3 face="Courier New">In the iCalendar/iTIP/iMIP work that I have been doing with Lotus Notes/Domino, one of the first examples we did was to create an iCalendar object for import/export demonstration that contained all the Company Holidays in it.</font>
<p><font size=3 face="Courier New">Yes, the iCalendar data model handles such cases.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
<p>
--=_alternative 0057479485256864_=--

From owner-ietf-calendar  Wed Jan 12 08:21:55 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA17559
	for ietf-calendar-bks; Wed, 12 Jan 2000 08:21:55 -0800 (PST)
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 IAA17555
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 08:21:53 -0800 (PST)
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 LAA11149
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 11:36:58 -0500 (EST)
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 LAA15531
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 11:21:24 -0500 (EST)
To: ietf-calendar@imc.org
Subject: Re: queries for unbounded recurring components
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF35CE4BF1.5C566294-ON85256864.00597FEC@Lotus.com>
Date: Wed, 12 Jan 2000 11:20:44 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/12/2000 11:23:36 AM,
	Serialize complete at 01/12/2000 11:23:36 AM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005A5EF585256864_="
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 005A5EF585256864_=
Content-Type: text/plain; charset="us-ascii"

Doug:
Wouldn't CUA-1 see that the SEQUENCE number for the event had changed from 
what it had and then ask for the whole definition of the event?
Or are you addressing the case where CUA-1 is reading from the calendar 
while CUA-2 is writing into it, creating a condition where what it reads 
is out of date?
-- Frank




Doug Royer <Doug.Royer@software.com>
Sent by: owner-ietf-calendar@imc.org
01/11/2000 08:13 PM
Please respond to ietf-calendar

 
        To:     ietf-calendar@imc.org
        cc:     (bcc: Frank Dawson/CAM/Lotus)
        Subject:        Re: queries for unbounded recurring components



>Bruce_Kahn@iris.com wrote:
>> 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"?

>I think we discussed this already.

>As for components between dates (give me >= January && < Febuary).

>The logic (as I recall) was:

>                TIME-1:                                 CUA-1 asks for 
the 1st 3 after date.

>                TIME-2:                                 CUA-2 inserts 1 
new entry BEFORE the original.
>                                                                      1 
new after the original 1st entry.

>                TIME-3:                                 CUA-1 asks for 
(in what ever way) the next 3.

>                                                What do you return? Do 
you notify them that
>                                                some are new and they did 
not get them?


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




<br><font size=3 face="Courier New">Doug:</font>
<p><font size=3 face="Courier New">Wouldn't CUA-1 see that the SEQUENCE number for the event had changed from what it had and then ask for the whole definition of the event?</font>
<p><font size=3 face="Courier New">Or are you addressing the case where CUA-1 is reading from the calendar while CUA-2 is writing into it, creating a condition where what it reads is out of date?</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
<p>
<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">01/11/2000 08:13 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;(bcc: Frank Dawson/CAM/Lotus)</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: queries for unbounded recurring components</font></table>
<br>
<br><font size=2 face="Courier New"><br>
<br>
&gt;Bruce_Kahn@iris.com wrote:<br>
&gt;&gt; It does however raise the question about the<br>
&gt;&gt; search mechanism/language. &nbsp;Could a CUA use the currently proposed<br>
&gt;&gt; mechanism/language to request &quot;Give me the next 3 entries for UID:12345 after<br>
&gt;&gt; 19991019T142100&quot;?<br>
<br>
&gt;I think we discussed this already.<br>
<br>
&gt;As for components between dates (give me &gt;= January &amp;&amp; &lt; Febuary).<br>
<br>
&gt;The logic (as I recall) was:<br>
<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; TIME-1: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;CUA-1 asks for the 1st 3 after date.<br>
<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; TIME-2: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;CUA-2 inserts 1 new entry BEFORE the original.<br>
&gt; &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; &nbsp;1 new after the original 1st entry.<br>
<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; TIME-3: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;CUA-1 asks for (in what ever way) the next 3.<br>
<br>
&gt; &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; What do you return? Do you notify them that<br>
&gt; &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; some are new and they did not get them?<br>
</font>
<br>
--=_alternative 005A5EF585256864_=--

From owner-ietf-calendar  Wed Jan 12 08:42:31 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17823
	for ietf-calendar-bks; Wed, 12 Jan 2000 08:42:31 -0800 (PST)
Received: from hqvsbh1.ms.com (hqvsbh1.ms.com [205.228.12.103])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17819
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 08:42:30 -0800 (PST)
Received: (from uucp@localhost)
        by hqvsbh1.ms.com (8.9.3/fw v1.30) id LAA13774;
        Wed, 12 Jan 2000 11:43:04 -0500 (EST)
Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1)
	id sma.9476953731.012628; Wed, 12 Jan 00 11:42:53 -0500
Received: by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id LAA12518;
	Wed, 12 Jan 2000 11:42:53 -0500 (EST)
X-Authentication-Warning: hqvsbh1.ms.com: Processed from queue /var/spool/mqueue-vs
X-Authentication-Warning: hqvsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf
X-Interface: IDMZ
Received: from sasmh4.ms.com(144.14.193.5) by hqvsbh1 via smap (4.1)
	id sma.9476953581.011847; Wed, 12 Jan 00 11:42:38 -0500
Received: from msdw.com (vector.morgan.com [144.14.16.149])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id LAA04058;
        Wed, 12 Jan 2000 11:42:38 -0500 (EST)
Message-ID: <387CAEFE.E6C75C6B@msdw.com>
Date: Wed, 12 Jan 2000 11:42:38 -0500
From: David Madeo <David.Madeo@msdw.com>
Reply-To: David.Madeo@msdw.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
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: Gilles Fortin <fortin@teamsoft.com>, ietf-calendar@imc.org
Subject: Re: New Topic: Export of calendar data and metadata
References: <OF08C0531B.2E2F4871-ON85256864.00568637@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-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

fortin@teamsoft.com

> There is an issue that does not seem to me to have been properly addressed:
> exporting holiday data. For interoperability it will be useful to
> import/export holiday data.

> This type of data is usually stored at the CS level and pertains to all its
> users. Let's think of a school, which will follow national holidays, state
> holidays, school board holiday and eventually special school events... Does
> the iCalendar model take this into account?

Frank_Dawson@lotus.com wrote:
> Gilles:
> 
> In the iCalendar/iTIP/iMIP work that I have been doing with Lotus
> Notes/Domino, one of the first examples we did was to create an
> iCalendar object for import/export demonstration that contained all
> the Company Holidays in it.
> 
> Yes, the iCalendar data model handles such cases.

I suspect there's a subtext to this question which wasn't clarified.  
Some Calendar Servers treat Holidays as something special.   For
example, one that I'm familiar with automatically ignores instances of
repeating meetings which occur on a "holiday". 

It's hard to see how this scales though.  At our site, even though we
have company "holidays", there are some people who work on those days. 
I suspect that the best way to solve this is to have different "holiday"
calendars which individuals can sign up for in some way and are marked
as "NO CONFLICT".  The CS can then safely treat Holidays just like
anything else.

dmadeo

From owner-ietf-calendar  Wed Jan 12 08:38:55 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA17765
	for ietf-calendar-bks; Wed, 12 Jan 2000 08:38:55 -0800 (PST)
Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17761
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 08:38:54 -0800 (PST)
Received: from joyce (unknown [193.14.119.6])
	by ljudo.shortlist.se (Postfix) with SMTP
	id 559C0B3696; Wed, 12 Jan 2000 17:38:53 +0100 (CET)
From: "Greg FitzPatrick" <gf@medianet.org>
To: <ietf-calendar@imc.org>
Cc: "Gilles Fortin" <fortin@teamsoft.com>
Subject: SV: New Topic: Export of calendar data and metadata
Date: Wed, 12 Jan 2000 17:43:45 +0100
Message-ID: <NCBBJIFAOLHFMAPPOLHCOEMPCLAA.gf@medianet.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <v01530500b4a24734e85e@[207.134.168.55]>
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 separate issue.  Ideally Holidays should be published as schemas
by the appropriate authority that has the power to declare them.  This is
very rare or should I say non-existent, though we think at least that we
have convinced  the Swedish government to let us do that for them.

Otherwise there are  volunteer efforts such as

http://www.holidayfestival.com/

which many planners use.  But again it is not an authoritive site - and all
the discussions which took place around the Olson time zone database apply
here as well. see thread: Timezones and Olson Tables

As Brian says in his disclaimer:

"I cannot guarantee the accuracy of any information given in any of the
pages from which this document has been called or of any page in the site
http://www.HolidayFestival.com. While every effort is made to achieve
accuracy, users should accept this for what it is, an attempt to gather
together in one place as much information as possible, however incomplete or
inaccurate it may be, in the hopes that it will be of some help to them.
Users make use of this information strictly at their own risk and are
advised to confirm it with their own contacts before traveling. Bankers and
those in the banking industry should be aware that, while every effort is
made to show accurate bank holidays around the world, they should
double-check the data with their own contacts before accepting it for
value-dating or other financial purposes."

I do not believe that anyone would like to indiscriminately fill their
CalApp with Holidays (someone at an IETF meeting told me there were 1236
public bodies with the authority to declare a holiday in California alone)
but that any event-publisher should have  access to immediate feed back on
any relevant holiday which occurs at a time and place coordinate matching
that of the intended event.

And the same goes for any calendar user planning attendance.

In any case the issue is not "Holidays" per se but "Schemas", since there
are many resources which in the future will receive "authoritive" addresses
and consequently  become part of the legal infrastructure.

In the SKiCal draft we refer to at least 14 desirable schemas, though we use
the term "lists".   Lists should be dependable, authoritive,
machine-readable, and so on...

http://www.ietf.org/internet-drafts/draft-many-ical-ski-01.txt

So stay tuned for Namespaces, schemas, paths, pointers and links in iCal V.5
(perhaps we will have gotten around to calling it xCal by then), but for the
time being, as phrased in typical CALSCH speak;
- It's not on our plate.



> There is an issue that does not seem to me to have been properly
> addressed:
> exporting holiday data. For interoperability it will be useful to
> import/export holiday data.
> This type of data is usually stored at the CS level and pertains
> to all its
> users. Let's think of a school, which will follow national holidays, state
> holidays, school board holiday and eventually special school
> events... Does
> the iCalendar model take this into account?
>
>
> >David Madeo wrote:
> >>>
> >>> 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.
> >
> >I agree, it should be possible for an administrative or super
> user account
> >to fetch everything - given a VCAR. Or to set anything - given a VCAR.
> >
> >We would also need to explain that there would not be any kind if CS
> >supported incremental backup or restore. That would be up to a custom
> >CUA (or any CUA) to merge/mix/delete with a users help.  I see this part
> >of backup the same as disconnected/reconnected issues.
> >
> >
> >Content-Type: application/octet-stream; name="Doug.Royer.vcf"
> >Content-Disposition: attachment; filename="Doug.Royer.vcf"
> >
> >Attachment converted: HD:Doug.Royer.vcf 16 (????/----) (00025796)
> >Content-Type: application/octet-stream; name="smime.p7s"
> >Content-Disposition: attachment; filename="smime.p7s"
> >
> >Attachment converted: HD:smime.p7s 9 (????/----) (00025797)
>
> Gilles Fortin, Founder & President
> __________________________________
> Teamsoft Inc.
> 50 Queen, #304
> Montreal, Canada H3C 2N5
> +514-875-2231x106    fax:+514-875-2401
> Internet: fortin@teamsoft.com    Web: http://teamsoft.com
>
>


From owner-ietf-calendar  Wed Jan 12 09:12:04 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18268
	for ietf-calendar-bks; Wed, 12 Jan 2000 09:12:04 -0800 (PST)
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 JAA18263
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 09:12:02 -0800 (PST)
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 MAA20557;
	Wed, 12 Jan 2000 12:27:07 -0500 (EST)
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 MAA26235;
	Wed, 12 Jan 2000 12:11:36 -0500 (EST)
To: David.Madeo@msdw.com
Cc: dmadeo@ms.com, fortin@teamsoft.com, ietf-calendar@imc.org
Subject: Re: New Topic: Export of calendar data and metadata
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF5A293895.52A01133-ON85256864.005E606C@Lotus.com>
Date: Wed, 12 Jan 2000 12:13:44 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/12/2000 12:13:41 PM,
	Serialize complete at 01/12/2000 12:13:41 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005F392685256864_="
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 005F392685256864_=
Content-Type: text/plain; charset="us-ascii"

David:
A better way is for you to define Holidays as individual date based events 
with time transparency set to TRANSPARENT, rather than OPAQUE.
Alternately, you could set them to OPAQUE, but give them a low PRIORITY 
compared to normal group scheduled events (i.e., CATEGORIES:MEETING).
A still better approach is for a calendar for the user to have a robust 
"user profile" that allows you to set that you allow or don't allow 
scheduling of events and to-dos on Holidays.
-- Frank
--=_alternative 005F392685256864_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">David:</font>
<p><font size=3 face="Courier New">A better way is for you to define Holidays as individual date based events with time transparency set to TRANSPARENT, rather than OPAQUE.</font>
<p><font size=3 face="Courier New">Alternately, you could set them to OPAQUE, but give them a low PRIORITY compared to normal group scheduled events (i.e., CATEGORIES:MEETING).</font>
<p><font size=3 face="Courier New">A still better approach is for a calendar for the user to have a robust &quot;user profile&quot; that allows you to set that you allow or don't allow scheduling of events and to-dos on Holidays.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 005F392685256864_=--

From owner-ietf-calendar  Wed Jan 12 09:12:05 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA18272
	for ietf-calendar-bks; Wed, 12 Jan 2000 09:12:05 -0800 (PST)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18267
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 09:12:04 -0800 (PST)
Received: from Software.com ([207.175.94.29]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <20000112171209.FRID4647450.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 11:12:09 -0600
Message-ID: <387CB5BA.EB7CA3E4@Software.com>
Date: Wed, 12 Jan 2000 09:11:22 -0800
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: New Topic: Export of calendar data and metadata
References: <v01530500b4a24734e85e@[207.134.168.55]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8E5E22D99119C2F30CDE2939"
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.

--------------ms8E5E22D99119C2F30CDE2939
Content-Type: multipart/mixed;
 boundary="------------EED181EC8B96521BB90E4859"

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


Gilles Fortin wrote:
> 
> There is an issue that does not seem to me to have been properly addressed:
> exporting holiday data. For interoperability it will be useful to
> import/export holiday data.
> This type of data is usually stored at the CS level and pertains to all its
> users. Let's think of a school, which will follow national holidays, state
> holidays, school board holiday and eventually special school events... Does
> the iCalendar model take this into account?

A CUA can ask for any type of data. Do you mean that you want
a special tag for HOLIDAY?

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

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

--------------EED181EC8B96521BB90E4859--

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

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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjE3MTEyM1owIwYJKoZIhvcNAQkEMRYEFD6c
CteI21xaBDYe61JokTzV7ZvMMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAPO7Nf169di9ZLiu8wekQKCSdJD/RwCpJxEgm4H1xiNF9IIGPwVN1epup
t+VLC7QKZNRBrumzzAd1FDVx+DYfRdMfy3oofv/yTdhoECBEuJQ4QyAYoEGNBSk3yn3nFtjD
Y/jiL+L33IfuokI1zrH4BkzSopl0kHOO4eBD5Zt+2h8=
--------------ms8E5E22D99119C2F30CDE2939--


From owner-ietf-calendar  Wed Jan 12 09:16:06 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA18346
	for ietf-calendar-bks; Wed, 12 Jan 2000 09:16:06 -0800 (PST)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18342
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 09:16:05 -0800 (PST)
Received: from Software.com ([207.175.94.29]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <20000112171611.FRJM4647450.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 11:16:11 -0600
Message-ID: <387CB6AB.265CF539@Software.com>
Date: Wed, 12 Jan 2000 09:15:23 -0800
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: queries for unbounded recurring components
References: <OF35CE4BF1.5C566294-ON85256864.00597FEC@Lotus.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0A77A06B5D4725489E3ED6FF"
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.

--------------ms0A77A06B5D4725489E3ED6FF
Content-Type: multipart/mixed;
 boundary="------------A7434A47088EC594EAD5862B"

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



Frank_Dawson@lotus.com wrote:
> 
> Doug:
> 
> Wouldn't CUA-1 see that the SEQUENCE number for the event had changed from
> what it had and then ask for the whole definition of the event?

Not if as Bruce says, "...if you don't ask for it, you will not get it ...".
So if CUA-1 did not ask for SEQUENCE, it would never know.

That's why I think date range queries are the better option. If you
don't ask for SEQUENCE, you will still get the correct answer.

> Or are you addressing the case where CUA-1 is reading from the calendar while
> CUA-2 is writing into it, creating a condition where what it reads is out of
> date?

No. Not simultaneous. But separate operations over time.

> -- Frank
> 
>   Doug Royer <Doug.Royer@software.com>
>                                                To:
>   Sent by: owner-ietf-calendar@imc.org  ietf-calendar@imc.org
>                                                cc:        (bcc: Frank
>   01/11/2000 08:13 PM                  Dawson/CAM/Lotus)
>   Please respond to ietf-calendar              Subject:        Re: queries
>                                        for unbounded recurring components
> 
> >Bruce_Kahn@iris.com wrote:
> >> 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"?
> 
> >I think we discussed this already.
> 
> >As for components between dates (give me >= January && < Febuary).
> 
> >The logic (as I recall) was:
> 
> >                 TIME-1:                                  CUA-1 asks for the
> 1st 3 after date.
> 
> >                 TIME-2:                                  CUA-2 inserts 1 new
> entry BEFORE the original.
> >                                                                          1
> new after the original 1st entry.
> 
> >                 TIME-3:                                  CUA-1 asks for (in
> what ever way) the next 3.
> 
> >                                                   What do you return? Do you
> notify them that
> >                                                   some are new and they did
> not get them?
--------------A7434A47088EC594EAD5862B
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"

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

--------------A7434A47088EC594EAD5862B--

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

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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjE3MTUyNFowIwYJKoZIhvcNAQkEMRYEFO8o
4QTMnqV49USr67mKToTAb0hiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAOzxHWg3tdFGBiB1SbXNKOH1rpTNyfCtVXXqGuWKezZyg52JCpeNMd3X9
RxQaS+TBbyog8bVgM9+J/X08/gAVM7hMmQPZk55YLvQvIWgajWtrlzR6kcWfhDrnOSswn/fF
5PAU5lkQMQFA+LRGUNgLJ3oWSF8/Axgz7nNrgJfD1M8=
--------------ms0A77A06B5D4725489E3ED6FF--


From owner-ietf-calendar  Wed Jan 12 09:18:37 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18435
	for ietf-calendar-bks; Wed, 12 Jan 2000 09:18:37 -0800 (PST)
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 JAA18431;
	Wed, 12 Jan 2000 09:18:36 -0800 (PST)
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 MAA21415;
	Wed, 12 Jan 2000 12:33:40 -0500 (EST)
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 MAA27232;
	Wed, 12 Jan 2000 12:18:09 -0500 (EST)
To: "Greg FitzPatrick" <gf@medianet.org>
Cc: fortin@teamsoft.com, ietf-calendar@imc.org, owner-ietf-calendar@imc.org
Subject: Re: SV: New Topic: Export of calendar data and metadata
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OFE2508354.F0A76605-ON85256864.005EFE82@Lotus.com>
Date: Wed, 12 Jan 2000 12:20:17 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/12/2000 12:20:14 PM,
	Serialize complete at 01/12/2000 12:20:14 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 005FD2AE85256864_="
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 005FD2AE85256864_=
Content-Type: text/plain; charset="us-ascii"

Greg:
I think that the original question was about the iCalendar data model. Is 
it expressive enough for import/export of holiday definitions.
The answer is, yes it is. 
You are correct. Depending on what an individual means by "holidays", 
there is a different "authority" who defines and probably publishes these.
For Lotus Holidays (or our Pay Days, a holiday for my significant-other!), 
I got to Lotus HR for this information. I have been able to add it to my 
Notes calendar and then export it as an iCalendar object.
-- Frank

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




<br><font size=3 face="Courier New">Greg:</font>
<p><font size=3 face="Courier New">I think that the original question was about the iCalendar data model. Is it expressive enough for import/export of holiday definitions.</font>
<p><font size=3 face="Courier New">The answer is, yes it is. </font>
<p><font size=3 face="Courier New">You are correct. Depending on what an individual means by &quot;holidays&quot;, there is a different &quot;authority&quot; who defines and probably publishes these.</font>
<p><font size=3 face="Courier New">For Lotus Holidays (or our Pay Days, a holiday for my significant-other!), I got to Lotus HR for this information. I have been able to add it to my Notes calendar and then export it as an iCalendar object.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 005FD2AE85256864_=--

From owner-ietf-calendar  Wed Jan 12 09:46:20 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA18809
	for ietf-calendar-bks; Wed, 12 Jan 2000 09:46:20 -0800 (PST)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18805
	for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 09:46:19 -0800 (PST)
Received: from Software.com ([207.175.94.29]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <20000112174624.FRSF4647450.mta2biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Wed, 12 Jan 2000 11:46:24 -0600
Message-ID: <387CBDBE.A0CC98E7@Software.com>
Date: Wed, 12 Jan 2000 09:45:34 -0800
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: New Topic: Export of calendar data and metadata
References: <OF5A293895.52A01133-ON85256864.005E606C@Lotus.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms9BF6CBE00E24D951F7553CBD"
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.

--------------ms9BF6CBE00E24D951F7553CBD
Content-Type: multipart/mixed;
 boundary="------------06C376D8ADF4E9AB07872097"

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



Frank_Dawson@lotus.com wrote:
> 
> David:
> 
> A better way is for you to define Holidays as individual date based events
> with time transparency set to TRANSPARENT, rather than OPAQUE.
> 
> Alternately, you could set them to OPAQUE, but give them a low PRIORITY
> compared to normal group scheduled events (i.e., CATEGORIES:MEETING).
> 
> A still better approach is for a calendar for the user to have a robust "user
> profile" that allows you to set that you allow or don't allow scheduling of
> events and to-dos on Holidays.

And also it depends on the calendar. For example if it is a company
calendar, then OPAQUE and NO CONFLICTS might be valid.

Where an individual may choose not to treat it as OPAQUE and allow CONFLICTS.

So the source of the information (authoritative or not) can set the TRANSPARENCY
and CONFLICTs values when PUBLISHed, but a CUA must be able to override them
as pointed out above when depositing them into CU owned calendar.

I do not see this problem unique to holidays.

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

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

--------------06C376D8ADF4E9AB07872097--

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

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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjE3NDUzNVowIwYJKoZIhvcNAQkEMRYEFNkP
LH5lKEU5ZYPdxIuHcENd4aIOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAFUF2wY+AxwUibzR5G4JuPdIp+/gV7VriztY7XhNFzfrXEh3dwGG+5ZQF
JbzQ8c2idMVpgp8e2uuqhQuHcHIt+Gh9UqRuxfCQTVqg8TwsF3Fcr54L7FvFkekyUfn45Wom
N6yBUs4rLktf32FqNkGYOMBBgy5C9RtkuNmzRt47Mn4=
--------------ms9BF6CBE00E24D951F7553CBD--


From owner-ietf-calendar  Thu Jan 13 07:05:27 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA23566
	for ietf-calendar-bks; Thu, 13 Jan 2000 07:05:27 -0800 (PST)
Received: from localhost.localdomain (outbound.ecal.com [209.218.166.156] (may be forged))
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23562
	for <ietf-calendar@imc.org>; Thu, 13 Jan 2000 07:05:25 -0800 (PST)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA19486
	for <ietf-calendar@imc.org>; Thu, 13 Jan 2000 10:07:30 -0500
Message-ID: <387DEA32.F87ACA1F@ecal.com>
Date: Thu, 13 Jan 2000 10:07:30 -0500
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: SV: New Topic: Export of calendar data and metadata
References: <NCBBJIFAOLHFMAPPOLHCOEMPCLAA.gf@medianet.org>
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>

Greg FitzPatrick wrote:

> This is a separate issue.  Ideally Holidays should be published as schemas
> by the appropriate authority that has the power to declare them.

Except that not everybody observes all official holidays.  For example,
Presidents' Day is an official U.S. holiday, but most companies don't take it
off.  So you probably need to get your holiday data from some more local source
maybe one that filters the official data.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |Dave Barry for President! He'll Keep Dan Quayle.|
|francis@ecal.com|(OK, it's old)                                  |
\=================================================================/




From owner-ietf-calendar  Thu Jan 13 11:55:51 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA27063
	for ietf-calendar-bks; Thu, 13 Jan 2000 11:55:51 -0800 (PST)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27058
	for <ietf-calendar@imc.org>; Thu, 13 Jan 2000 11:55:50 -0800 (PST)
Received: from Software.com ([207.175.94.29]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000113195602.LUGV4639007.mta1biz.bizmailsrvcs.net@Software.com>;
          Thu, 13 Jan 2000 13:56:02 -0600
Message-ID: <387E2DBB.6FE6D426@Software.com>
Date: Thu, 13 Jan 2000 11:55:39 -0800
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: Paul Overell <paulo@turnpike.com>
CC: ietf-calendar@imc.org
Subject: (I-3)Re: iMIP, RFC2447 and [RFC-1847]-compliant encryption
References: <Yl4XPLAEGec4QAAk@turnpike.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF3AF3FC6D5125697B64C367A"
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.

--------------msF3AF3FC6D5125697B64C367A
Content-Type: multipart/mixed;
 boundary="------------A862C9F5A93370236E9CADE6"

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


As I could not find a reply to this, I'll try.

We want S/MIME, and most of us are not security experts, what
do you suggest? Is there a better text or RFC, or should
it be dropped?

Paul Overell wrote:
> 
> iMIP, RFC2447 says:
> 
> >2.2.3 Confidentiality
> >
> >   To ensure confidentiality using iMIP implementations should utilize
> >   [RFC-1847]-compliant encryption.
> >
> 
> This implicitly excludes S/MIME encryption (RFC2633 etc) as S/MIME's
> encryption is not [RFC-1847]-compliant - i.e. S/MIME does not use
> multipart/encrypted.
> 
> Is this exclusion of S/MIME intentional or have I misunderstood
> something here?
> 
> Regards
> --
> Paul Overell                                        T U R N P I K E  Ltd
--------------A862C9F5A93370236E9CADE6
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"

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

--------------A862C9F5A93370236E9CADE6--

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

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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMzE5NTU0MFowIwYJKoZIhvcNAQkEMRYEFLlX
NlepqIYIheNfYOlr9ACNBeoUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAxg3GuE8/hqaBb7AQXmdG5s/yrIGx2gkR7it/WG89GgFO59YZ7SpH/kbQ
JBfg5wIfZEd1Vd1YHM4xdGE0tOpnY3XSbONexXInpmOynl3r85vYB9UmErsS0Nn00nAjvDd+
mU9QA+tdoyG/qryVYhZqtKZhnOxmSy5gjmVCQhDESdc=
--------------msF3AF3FC6D5125697B64C367A--


From owner-ietf-calendar  Thu Jan 13 12:07:01 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA27201
	for ietf-calendar-bks; Thu, 13 Jan 2000 12:07:01 -0800 (PST)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27197
	for <ietf-calendar@imc.org>; Thu, 13 Jan 2000 12:07:00 -0800 (PST)
Received: from Software.com ([207.175.94.29]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000113200713.LUNI4639007.mta1biz.bizmailsrvcs.net@Software.com>
          for <ietf-calendar@imc.org>; Thu, 13 Jan 2000 14:07:13 -0600
Message-ID: <387E305B.8FB050EB@Software.com>
Date: Thu, 13 Jan 2000 12:06:51 -0800
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
CC: ietf-calendar@imc.org
Subject: Re: Poll: What goes in...
References: <OF0D231118.BE571D00-ON8525683A.005DD32C@iris.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBDBC56C37F16D27350B98A35"
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.

--------------msBDBC56C37F16D27350B98A35
Content-Type: multipart/mixed;
 boundary="------------EE3468F62605A4DD55BF32DA"

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



Bruce_Kahn@iris.com wrote:
> 
> must come out?  During some of the hallway converstations in DC I got into a
> discussion w/others about data preservation and integrity.  Some folks think
> that the data you put into the CS does not have to come back out "intact".
>  (By "intact" I do not mean byte for byte exact unless necessary for stuff
> like multipart/signed or multipart/encrypted.)  After some heated back and
> forth we reset the talk and I tried to learn more about their POV.  I think
> after a nights sleep we were able to pick up the discussion but I left
> somewhat dazed on this issue.
> 
> So Im taking a poll of the list to see what others expect from their CS.
>  Should the CS return to you the equivalent MIME data that the CUA put into
> it?  The 8 possible cases to consider:
> ....

>      Some have claimed that the CS does not have to preserve the signature of
>      the original data.  They expect the CS to 'rebuild' the entry for the CUA
>      from what ever internal format it uses and send back an equivalent 2.1 or
>      2.2 style entry but it would have the CS's signature instead of the
>      original one.  Paul (B. Hill) stated that 'audit trails' of signatures is
>      not a CAP requirement but when I look in the version on the WG site I
>      dont see it mentioned either way.  So I thought Id poll the group and see
>      what they expect/thought WRT this issue.

The CS is not a tape archive. It can manipulate the data, other users
can update the data. It can represent the data differently. I recall
a conversation where one vendor wanted to unwind some RRULEs when
they pulled it out (REPEAT 5 days -> 5 unique DATE entries).

In the EMAIL world a signature not only means that you sent the email,
it verifies that this is the email you sent. I don't know of any way
to preserve this information. If nothing else, the instant that the
CUA deposits this information into the CS the LAST-MODIFIED date will
change. Now what the original user sent is not the same as what is
in the CS == signaure invalid.

I also recall the DC hallway conversation saying that audit trails are
out of scope for CAP. And that seems to be the only reason for the
signature once it is verified and deposited into a CS.

There was conversation about preserving the signature so that it was
valid across the wire. This as I recall involved rearranging the
V{...} blocks so it could be done. (Anyone else remember?)
--------------EE3468F62605A4DD55BF32DA
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"

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

--------------EE3468F62605A4DD55BF32DA--

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

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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMzIwMDY1MlowIwYJKoZIhvcNAQkEMRYEFBnk
AAVNAMdypWa7/gCSS8oxof/KMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAUApzboRLR+9y7KdxPn/mc2VDZZ6kKKRRPTWUYeceVaSdaGRJjkI1LlrI
ztwtrndwowl67Dz2m4zyGoR9XOH04qprsOZO/bl2McaW3/BdkDme05kZvvmx32UGPcEYEeGy
r4c8kw/VH5leCDS8KXSLNBz/4HhxCHprwmQi+tad0X4=
--------------msBDBC56C37F16D27350B98A35--


From owner-ietf-calendar  Thu Jan 13 12:28:56 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA27448
	for ietf-calendar-bks; Thu, 13 Jan 2000 12:28:56 -0800 (PST)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27444
	for <ietf-calendar@imc.org>; Thu, 13 Jan 2000 12:28:55 -0800 (PST)
Received: from Software.com ([207.175.94.29]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000113202908.LUYN4639007.mta1biz.bizmailsrvcs.net@Software.com>;
          Thu, 13 Jan 2000 14:29:08 -0600
Message-ID: <387E357F.F2C0732D@Software.com>
Date: Thu, 13 Jan 2000 12:28:47 -0800
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: Issues with CAP "transport" protocol
References: <131151.3151395744@dhcp46-lt224.lt.ietf.innovationslab.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms68942174B153F891C24CEDC4"
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.

--------------ms68942174B153F891C24CEDC4
Content-Type: multipart/mixed;
 boundary="------------FF248D884BD3E419255B85E6"

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



Chris Newman wrote:
> 
> Here are the issues with the CAP "transport" protocol I raised at the IETF
> meeting.  These are based on my experience with other protocols.  [I
> apologize if some of these duplicate list traffic, as I'm 1200 messages
> behind on this list.]
> 
> "Transport" protocol
> ====================
> Using the OSI model, TCP/IP is the "transport protocol" and all of CAP is
> layered on top of it.  So what's called the "transport" protocol in the
> draft should either be called a "session-layer" protocol, a
> "presentation-layer" protocol or dodge the whole protocol-stack issue and
> call it a "transfer" protocol.

Yes and thanks. We had been struggling to pick names.
(Issue: W-30)

> NOOP command
> ============
> 
> If there's an idle timeout, and you want the ability for the client to hold
> the connection open for later use, then there should be a NOOP command.  I
> was told that the list didn't want ability for client to keep connection
> alive but idle.

True. With IMAP, many ISP's do not like the fact that IMAP allows clients
to keep an otherwise idle connection open with NOOP.
(Issue: W-31)

Perhaps could have a NOOP command that could be issued by a CUA
to indicate that the CUA wished the connection to stay alive subject
to CS administrative policy.
(Issue: W-32)

> AUTHENTICATE success data
> =========================
> 
> SASL permits a SASL profile to optionally return server mutual
> authentication data with a success code.  In the case of DIGEST-MD5, having
> the ability to include a base64 string of SASL data with the success
> response code will save a round trip.

I do not understand what you are saying here. Are you suggesting a
default authentication?

> Response-codes and text
> =======================
> 
> The response codes are numeric -- this means that anyone looking at the
> protocol trace will likely need to look up the numbers (especially since
> debug text may or may not reflect the meaning of the specific error code).
> Personally, I much prefer short mnemonic strings for machine-parsable error
> codes so that debugging is easier.  I was told the list already reached
> concensus on using numbers.
> 
> Also, if there's human readable text included with response codes, then
> there needs to be a specified language for that text.  It can be done as:
> 
> The text is "i-default" meaning it's in English intended for international
> readers, and may also include a translation of the text appropriate to the
> locale.
> 
> Or the client can negotiate the language it wants text to be in.

We discussed this on the WG list (issues W-10 & W-11)

 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)
 

> DISCONNECT -> QUIT/LOGOUT
> =========================
> 
> I requested that the "DISCONNECT" command be renamed to "QUIT" to match
> other IETF protocols (and also be shorter to type).

Issue: W-33

> Additional Authentication Errors
> ================================
> 
> In using SASL, I've identified a number of useful authentication error
> codes:
> .....

Thanks. We will work them into the next draft for comments.

> Response code data model
> ========================
> 
> The spec need a clear data model for when response data is present, when it
> isn't, and which data is machine parsable or human readable.  For example,
> some of your error codes return URLs in the field usually reserved for
> "debug text" intended for humans.  Since this is an exceptional situation,
> you need a way to distinguish such handling from "normal" handling (or
> eliminate the exception).
> 
> Also some examples show:
>         #.#.# text CRLF
>         <multiple lines of data>
>         .
> and others show just:
>         #.#.# text CRLF
> 
> So either the <multiple lines of data> should always be present, or there
> should be some way to tell if it will be present based on the error code.

I ~think~ that they are defined for an error code.

Issue: W-34

> Layer violation
> ===============
> The "CREATE" method has a serious layering violation between the
> "transport" protocol and app protocol.  Specifically, multiple "transport"
> layer status responses are returned based on the number of "Target:" items
> in the application layer request.  This indiates that the status responses
> are really application layer status responses.

I don't understand the issue here.
--------------FF248D884BD3E419255B85E6
Content-Type: text/x-vcard; charset=us-ascii;
 name="Doug.Royer.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="Doug.Royer.vcf"

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

--------------FF248D884BD3E419255B85E6--

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

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
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMzIwMjg0OFowIwYJKoZIhvcNAQkEMRYEFG4h
ll1SoYhkBoJGWUpQwMzfz+SDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGATBfwFc5/wW2Pfv6fXuWCr0P5lmP+io8DozX6SDmlwGocvxYVKFCISuSH
BWAX8fazndkv8AwqhKQK51MsLuVbIetJiJsgXkkWpqwjckbOJ1xP/xt9mGG5Jx5atNbp6zhh
SwedDLtZvKvdbvUs8brzkoWo+MU/HQjSL0VKZvNdJ8o=
--------------ms68942174B153F891C24CEDC4--


From owner-ietf-calendar  Thu Jan 13 14:56:07 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA29639
	for ietf-calendar-bks; Thu, 13 Jan 2000 14:56:07 -0800 (PST)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA29635
	for <ietf-calendar@imc.org>; Thu, 13 Jan 2000 14:56:06 -0800 (PST)
Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Jan 2000 14:56:14 -0800 (Pacific Standard Time)
Received: by dfssl with Internet Mail Service (5.5.2650.21)
	id <CRDBJV3C>; Thu, 13 Jan 2000 14:56:14 -0800
Message-ID: <9BE3A7FF0D67C341819FCA57736D5BC59D0674@dino.platinum.corp.microsoft.com>
From: Naveen Kachroo <nkachroo@Exchange.Microsoft.com>
To: ietf-calendar@imc.org
Cc: "'Frank_Dawson@lotus.com'" <Frank_Dawson@lotus.com>,
        "'Steve Mansour'"
	 <sman@netscape.com>
Subject: Netscape Meeting Responses
Date: Thu, 13 Jan 2000 12:43:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF5E19.647FA606"
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.

------_=_NextPart_001_01BF5E19.647FA606
Content-Type: text/plain;
	charset="iso-8859-1"

We are seeing some interop problems with Netscape 4.7

Netscape, when responding to a recurring meeting, is generating a separate
VEVENT for each instance. They are all contained inside the same VCALENDAR
block in the response. Each VEVENT has a RECURRENCE-ID.

Any ideas why? Why isn't a single VEVENT response enough..?

------_=_NextPart_001_01BF5E19.647FA606
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 =
5.5.2650.12">
<TITLE>Netscape Meeting Responses</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">We are seeing some interop problems =
with Netscape 4.7</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Netscape, when responding to a =
recurring meeting, is generating a separate VEVENT for each instance. =
They are all contained inside the same VCALENDAR block in the response. =
Each VEVENT has a RECURRENCE-ID.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Any ideas why? Why isn't a single =
VEVENT response enough..?</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF5E19.647FA606--

From owner-ietf-calendar  Thu Jan 13 14:57:22 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA29692
	for ietf-calendar-bks; Thu, 13 Jan 2000 14:57:22 -0800 (PST)
Received: from eljefe.innosoft.com (ELJEFE.INNOSOFT.COM [192.160.253.137])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29688
	for <ietf-calendar@imc.org>; Thu, 13 Jan 2000 14:57:21 -0800 (PST)
Received: from nifty-jr.innosoft.com ([192.160.253.35])
 by mail.eljefe.innosoft.com (PMDF V6.0-17 #4409)
 with ESMTPA id <0FOA006T9Q0ISB@mail.eljefe.innosoft.com> for
 ietf-calendar@imc.org; Thu, 13 Jan 2000 14:48:19 -0800 (PST)
Date: Thu, 13 Jan 2000 14:56:30 -0800
From: Chris Newman <chris.newman@innosoft.com>
Subject: Re: Issues with CAP "transport" protocol
In-reply-to: <387E357F.F2C0732D@Software.com>
To: Doug Royer <Doug.Royer@software.com>, ietf-calendar@imc.org
Message-id: <1337279.3156764190@nifty-jr.innosoft.com>
MIME-version: 1.0
X-Mailer: Mulberry (MacOS) [2.0.0b5, s/n S-100003]
Content-type: text/plain; charset=us-ascii; format=flowed
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>

--On Thursday, January 13, 2000 12:28 -0800 Doug Royer 
<Doug.Royer@Software.com> wrote:
>> AUTHENTICATE success data
>> =========================
>> 
>> SASL permits a SASL profile to optionally return server mutual
>> authentication data with a success code.  In the case of DIGEST-MD5,
>> having the ability to include a base64 string of SASL data with the
>> success response code will save a round trip.
> 
> I do not understand what you are saying here. Are you suggesting a
> default authentication?

It should be possible to do:

C: <auth-command> <sasl-mech-name> <sasl-client-data>
S: <sasl-server-data>
C: <sasl-client-data>
S: <success-code> <sasl-server-data>

The profile of SASL in CAP doesn't include a way to include final 
<server-data> with the <success-code>, thus forcing and extra round trip:

C: <auth-command> <sasl-mech-name> <sasl-client-data>
S: <sasl-server-data>
C: <sasl-client-data>
S: <sasl-server-data>
C: <empty-message>
S: <success-code>

I was mentioning that DIGEST-MD5 is an example of an authentication 
protocol with this behavior.

>> Layer violation
>> ===============
>> The "CREATE" method has a serious layering violation between the
>> "transport" protocol and app protocol.  Specifically, multiple
>> "transport" layer status responses are returned based on the number of
>> "Target:" items in the application layer request.  This indiates that
>> the status responses are really application layer status responses.
> 
> I don't understand the issue here.

The contents of the "app" layer impacts the number of responses generated 
at the "transport" layer.  This is a layering violation becuase you then 
can't write code for the transport layer without giving it specific 
knowledge of the "app" layer.  It'd be like making TCP/IP work differently 
based on whether FTP or POP was being used.

So you need to fix the layering violation.  You could have a single 
"transport" layer response code which includes app-level data with a 
response with a code for each "Target:" line in the app-level request.

		- Chris


From owner-ietf-calendar  Fri Jan 14 02:18:54 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id CAA22315
	for ietf-calendar-bks; Fri, 14 Jan 2000 02:18:54 -0800 (PST)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA22309
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 02:18:52 -0800 (PST)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2])
	by internal.mail.demon.net with ESMTP id KAA22531;
	Fri, 14 Jan 2000 10:19:33 GMT
Message-ID: <Ak$B$KAXevf4QALz@turnpike.com>
Date: Fri, 14 Jan 2000 10:16:55 +0000
To: ietf-calendar@imc.org
From: Paul Overell <paulo@turnpike.com>
Subject: Re: iMIP, RFC2447 and [RFC-1847]-compliant encryption
References: <Yl4XPLAEGec4QAAk@turnpike.com> <387E2DBB.6FE6D426@Software.com>
In-Reply-To: <387E2DBB.6FE6D426@Software.com>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.00 beta 2 M <U2yaxlNz9mbtXQDcM+J3SutElj>
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>

In article <387E2DBB.6FE6D426@Software.com>, Doug Royer
<Doug.Royer@Software.com> writes
>
>Paul Overell wrote:
>>
>> iMIP, RFC2447 says:
>>
>> >2.2.3 Confidentiality
>> >
>> >   To ensure confidentiality using iMIP implementations should utilize
>> >   [RFC-1847]-compliant encryption.
>> >
>>
>> This implicitly excludes S/MIME encryption (RFC2633 etc) as S/MIME's
>> encryption is not [RFC-1847]-compliant - i.e. S/MIME does not use
>> multipart/encrypted.
>>
>> Is this exclusion of S/MIME intentional or have I misunderstood
>> something here?
>>


>As I could not find a reply to this, I'll try.
>

Thanks - I was beginning to feel left out  :).

>We want S/MIME, and most of us are not security experts, what
>do you suggest? Is there a better text or RFC, or should
>it be dropped?
>


I know of no better RFC.   PGP/MIME encryption is RFC1847 compliant,
S/MIME encryption isn't.

As S/MIME was not explicitly specified I assume that the intention was
to leave the actual encryption scheme unspecified.

You ask for a suggestion, how about:

        To ensure confidentiality using iMIP implementations SHOULD
        utilize encryption.  It is outside the scope of this memo to
        specify specific encryption schemes.



Regards
-- 
Paul Overell                                        T U R N P I K E  Ltd

From owner-ietf-calendar  Fri Jan 14 08:13:25 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA01088
	for ietf-calendar-bks; Fri, 14 Jan 2000 08:13:25 -0800 (PST)
Received: from klaymen.rim.net (mail.rim.net [206.51.26.155] (may be forged))
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01084
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 08:13:22 -0800 (PST)
Received: from SMTP (navieg1.rim.net [192.17.64.254])
	by klaymen.rim.net (8.9.3/8.9.1) with SMTP id LAA17153
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 11:14:07 -0500
Received: from lightning.rim.net ([192.17.64.45]) by 192.17.64.254
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 14 Jan 2000 16:12:32 0000 (GMT)
Received: by lightning.rim.net with Internet Mail Service (5.5.2448.0)
	id <CP91LK7S>; Fri, 14 Jan 2000 11:14:06 -0500
Message-ID: <E05B69D6CB8ED21185A10000F8020E5301C03E2B@lightning.rim.net>
From: Antony Davies <adavies@rim.net>
To: "'ietf-calendar@imc.org'" <ietf-calendar@imc.org>
Subject: quoted printable in DESCRIPTION
Date: Fri, 14 Jan 2000 11:14:05 -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>

I may need to process MS outlook generated vcalendar objects.
I am unsure if they are RFC2445 compliant, or perhaps to some earlier RFC,
but I dont think 'text' fields in RFC2445 allow quoted printable encoding
(ie  DESCRIPTION;ENCODING=QUOTED-PRINTABLE:text) the only thing
I saw explicitly mentioned was the backslash encoding.
Also the only use of ENCODING I saw explicitly mentioned was for the binary
type.

Is outlook generating an invalid  vcalendar object in this case?

TIA

-------------------------------------
Antony Davies,
Software, Research In Motion
adavies@rim.net



From owner-ietf-calendar  Fri Jan 14 09:51:09 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02276
	for ietf-calendar-bks; Fri, 14 Jan 2000 09:51:09 -0800 (PST)
Received: from pivsbh1.ms.com (pivsbh1.ms.com [199.89.64.103])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02272
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 09:51:05 -0800 (PST)
Received: (from uucp@localhost)
        by pivsbh1.ms.com (8.9.3/fw v1.30) id MAA27425
        for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 12:51:50 -0500 (EST)
Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1)
	id sma.9478722951.026385; Fri, 14 Jan 00 12:51:35 -0500
Received: by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id MAA26379
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 12:51:35 -0500 (EST)
X-Authentication-Warning: pivsbh1.ms.com: Processed from queue /var/spool/mqueue-vs
X-Authentication-Warning: pivsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf
X-Interface: IDMZ
Received: from sasmh4.ms.com(144.14.193.5) by pivsbh1 via smap (4.1)
	id sma.9478722861.024941; Fri, 14 Jan 00 12:51:26 -0500
Received: from msdw.com (vector.morgan.com [144.14.16.149])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id MAA17112
        for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 12:51:25 -0500 (EST)
Message-ID: <387F621D.98376@msdw.com>
Date: Fri, 14 Jan 2000 12:51:25 -0500
From: David Madeo <David.Madeo@msdw.com>
Reply-To: David.Madeo@msdw.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
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Poll: What goes in...
References: <OF0D231118.BE571D00-ON8525683A.005DD32C@iris.com> <387E305B.8FB050EB@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>

Doug Royer wrote:
> 
> Bruce_Kahn@iris.com wrote:
> >
> > must come out?  During some of the hallway converstations in DC I got into a
> > discussion w/others about data preservation and integrity.  Some folks think
> > that the data you put into the CS does not have to come back out "intact".
> >  (By "intact" I do not mean byte for byte exact unless necessary for stuff
> > like multipart/signed or multipart/encrypted.)  After some heated back and
> > forth we reset the talk and I tried to learn more about their POV.  I think
> > after a nights sleep we were able to pick up the discussion but I left
> > somewhat dazed on this issue.
> >
> > So Im taking a poll of the list to see what others expect from their CS.
> >  Should the CS return to you the equivalent MIME data that the CUA put into
> > it?  The 8 possible cases to consider:
> > ....

> The CS is not a tape archive. It can manipulate the data, other users
> can update the data. It can represent the data differently. I recall
> a conversation where one vendor wanted to unwind some RRULEs when
> they pulled it out (REPEAT 5 days -> 5 unique DATE entries).

As a customer, I can safely say that I'd like to be able to import
everything related to a calendar store (calendars, ACL's, etc).  I'd
also like to export that same set of things that I can import.  It
should be completely bi-directional.  Do not trap me in an
implementation or think that it's ok to ask the user to re-enter data.

While I agree that users change things (and thus checksums), I'd like to
suggest that the CS should not transform the data as it come in. There
is a difference between a meeting which repeats for five days and 5
unique events.  

dmadeo

From owner-ietf-calendar  Fri Jan 14 09:49:05 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA02246
	for ietf-calendar-bks; Fri, 14 Jan 2000 09:49:05 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02242
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 09:48:56 -0800 (PST)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: ietf-calendar@imc.org
Subject: Re: Poll: What goes in...
X-Mailer: Lotus Notes Release 5.0.2  November 4, 1999
Message-ID: <OFA9E6E309.3639DF8E-ON85256866.00610CAC@iris.com>
Date: Fri, 14 Jan 2000 12:49:07 -0500
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/14/2000 12:49:09 PM,
	Serialize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/14/2000 12:49:09 PM,
	Serialize complete at 01/14/2000 12:49:09 PM,
	Itemize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/14/2000 12:49:09 PM,
	S/MIME Sign complete at 01/14/2000 12:49:09 PM,
	Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 01/14/2000
 12:52:13 PM,
	Serialize complete at 01/14/2000 12:52:13 PM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z01886_boundary_sign
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 an S/MIME signed message.

---------z01886_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0061E22885256866_="

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

Doug replied in part with:
>There was conversation about preserving the signature so that it was
>valid across the wire. This as I recall involved rearranging the
>V{...} blocks so it could be done. (Anyone else remember?)

This was a semi-related topic that had more to deal with preventing 
multiple fantouts and data tampering.  For example, I send a request to 
Doug@software.com and Steve@netscape.com.  My CS would fan out the 
identical request to both netscape.com and software.com.  Unfortunately 
upon receiving the requests at each site the receiving CS would see a 
TARGET on the other site and attempt to do the same fanouts again.  We 
could get into race conditions and other looping conditions that get 
really really ugly.  (Just picture the 5 way separate domain case between 
the CAP editors!!)  There were also encrypted data considerations for this 
need to as not all CS in the 'chain'/path may/should be able to see the 
encrypted CAP data.

To prevent this routing loop problem, to 'fix' the possible problem of a 
CS blowing signatures by modifying TARGETs (ie: my CS removes 
Doug@software.com from the copy that goes to netscape.com and visa versa) 
and to allow the passing of encrypted data thru CS's that do not have the 
key to see what is inside it we discussed splitting the TARGET information 
(or more precisely the command related information) into a separate body 
part.   Last I recall, Steve Mansur had the token to scribe up the changes 
we discussed and send out in the next revision of the draft.

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




<br><font size=2 face="sans-serif">Doug replied in part with:</font>
<br><font size=2 face="Courier New">&gt;There was conversation about preserving the signature so that it was<br>
&gt;valid across the wire. This as I recall involved rearranging the<br>
&gt;V{...} blocks so it could be done. (Anyone else remember?)</font>
<br>
<br><font size=2 face="sans-serif">This was a semi-related topic that had more to deal with preventing multiple fantouts and data tampering. &nbsp;For example, I send a request to Doug@software.com and Steve@netscape.com. &nbsp;My CS would fan out the identical request to both netscape.com and software.com. &nbsp;Unfortunately upon receiving the requests at each site the receiving CS would see a TARGET on the other site and attempt to do the same fanouts again. &nbsp;We could get into race conditions and other looping conditions that get really really ugly. &nbsp;(Just picture the 5 way separate domain case between the CAP editors!!) &nbsp;There were also encrypted data considerations for this need to as not all CS in the 'chain'/path may/should be able to see the encrypted CAP data.</font>
<br>
<br><font size=2 face="sans-serif">To prevent this routing loop problem, to 'fix' the possible problem of a CS blowing signatures by modifying TARGETs (ie: my CS removes Doug@software.com from the copy that goes to netscape.com and visa versa) and to allow the passing of encrypted data thru CS's that do not have the key to see what is inside it we discussed splitting the TARGET information (or more precisely the command related information) into a separate body part. &nbsp; Last I recall, Steve Mansur had the token to scribe up the changes we discussed and send out in the next revision of the draft.</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 0061E22885256866_=--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIAwggHZMIIBg6ADAgECAiBgUF6eflpWh6h9PfgYD7sAlMCM8enGl8RXOcIo9uhg
ezANBgkqhkiG9w0BAQQFADBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzEN
MAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTAeFw05OTEx
MTcxOTEzMjdaFw0wMTExMTYxOTEyNTNaMEgxDTALBgNVBAoTBElyaXMxEzARBgNV
BAMTCkJydWNlIEthaG4xIjAgBgkqhkiG9w0BCQEWE0JydWNlX0thaG5AaXJpcy5j
b20wWzANBgkqhkiG9w0BAQEFAANKADBHAkEA495S/vcTouExtWuNrF33Q28Lcjjk
4lj2W6ERZ3MhEBR5vHL3wTaXoRWVhPeoDaUcCc54oig8YQlC/hwSp3YF4QICQlGj
PDA6MBEGA1UdDgQKBAhG2i3x0db2dzAPBgNVHQ8BAf8EBQMDB7AAMBQGC2CGSAGG
+A4CAgMCBAUDAweAADANBgkqhkiG9w0BAQQFAANBAJnY7BPUuh9G4grcCnmNPlMH
JsE0/KULlvaqMab5uWQd0nFkZg64TIWwlYMLrwKqzenyrEkVF4QO6yjiShaej/Aw
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVT
MQ0wCwYDVQQIEwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIElu
dGVybmV0IENBMB4XDTk4MTEwMjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkG
A1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMT
EElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAw+BjK0cg
xCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5yBLD
j5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwz
cO3Ltq2HlXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/wi
ngAAMYAwggF5AgEBMGowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0ECIGBQXp5+WlaH
qH09+BgPuwCUwIzx6caXxFc5wij26GB7MAkGBSsOAwIaBQCggaswGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMTE0MTc0OTA5WjAj
BgkqhkiG9w0BCQQxFgQUgqfXIza76Dd3otEpWY6NqYIsvUUwTAYJKoZIhvcNAQkP
MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D
AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQFJ/4DJFoMX2PQqm3GBK
6Zk7pk5AjF2+qsZhoVxEaauwVcpT8gXB1QCOPT4iCaXIy3oqWZCEBeUZIna+VGjp
H58AAAAAAAAAAA==

---------z01886_boundary_sign--

From owner-ietf-calendar  Fri Jan 14 11:01:09 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA02991
	for ietf-calendar-bks; Fri, 14 Jan 2000 11:01:09 -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 LAA02987
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 11:01:07 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA13370;
	Fri, 14 Jan 2000 11:01:51 -0800 (PST)
Message-ID: <387F7299.986B2035@home.royer.com>
Date: Fri, 14 Jan 2000 11:01:45 -0800
From: Doug Royer <doug@home.royer.com>
Reply-To: "'ietf-calendar@imc.org'" <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'" <ietf-calendar@imc.org>
Subject: Re: quoted printable in DESCRIPTION
References: <E05B69D6CB8ED21185A10000F8020E5301C03E2B@lightning.rim.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7877181505DCEE838D8575A8"
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.

--------------ms7877181505DCEE838D8575A8
Content-Type: multipart/mixed;
 boundary="------------C75C04588D3A52EE2ABFA4FF"

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

Antony Davies wrote:
> 
> I may need to process MS outlook generated vcalendar objects.
> I am unsure if they are RFC2445 compliant, or perhaps to some earlier RFC,
> but I dont think 'text' fields in RFC2445 allow quoted printable encoding
> (ie  DESCRIPTION;ENCODING=QUOTED-PRINTABLE:text) the only thing
> I saw explicitly mentioned was the backslash encoding.
> Also the only use of ENCODING I saw explicitly mentioned was for the binary
> type.
> 
> Is outlook generating an invalid  vcalendar object in this case?

As the default charset for RFC2445 is UTF-8, why encode text as
iCalendar is 8-bit ready. Also, 'email' can be transfered in quoted
printable, the parsing end (Destination MUA), should un-encode them to
get the original (8-bit or otherwise) information. If not then what you
get is not what the original calendar had.

For VALUE=BINARY encoding is used because it may contain embedded
end-of-line characters or zeros.

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

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

--------------C75C04588D3A52EE2ABFA4FF--

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

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
ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTE0MTkwMTQ2WjAjBgkqhkiG9w0BCQQxFgQUfQze4+4h
OoDlX6cX8+HRt3YBVEwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYB5O9ZEUxYA3zC2mAGg4aWAgHmT2dwC6V1Ga5FmqmTpFPoVO9Ag1El55ShO81AU
o7qqf5axuvtMYIksqzRTYePrlrWQGElsAVMVPgf/I6deUHkJmHKZo/ydeLNc5LGJ1QHxQatD
abVWUzz+35Ur1FFHzWdLBxtdJ8yrqBSEeYZS5Q==
--------------ms7877181505DCEE838D8575A8--


From owner-ietf-calendar  Fri Jan 14 12:34:46 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA04112
	for ietf-calendar-bks; Fri, 14 Jan 2000 12:34:46 -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 MAA04108
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 12:34:44 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id MAA13548
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 12:35:30 -0800 (PST)
Message-ID: <387F888B.F1F85B65@home.royer.com>
Date: Fri, 14 Jan 2000 12:35:24 -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: Poll: What goes in...
References: <OF0D231118.BE571D00-ON8525683A.005DD32C@iris.com> <387E305B.8FB050EB@Software.com> <387F621D.98376@msdw.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEE6A10B681B9CC4002C81FA7"
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.

--------------msEE6A10B681B9CC4002C81FA7
Content-Type: multipart/mixed;
 boundary="------------DF7AC1D848A9FBC4CD8DFD4A"

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

David Madeo wrote:
> 
> Doug Royer wrote:
> >
> > Bruce_Kahn@iris.com wrote:
> > >
> > > must come out?  During some of the hallway converstations in DC I got into a
> > > discussion w/others about data preservation and integrity.  Some folks think
> > > that the data you put into the CS does not have to come back out "intact".
> > >  (By "intact" I do not mean byte for byte exact unless necessary for stuff
> > > like multipart/signed or multipart/encrypted.)  After some heated back and
> > > forth we reset the talk and I tried to learn more about their POV.  I think
> > > after a nights sleep we were able to pick up the discussion but I left
> > > somewhat dazed on this issue.
> > >
> > > So Im taking a poll of the list to see what others expect from their CS.
> > >  Should the CS return to you the equivalent MIME data that the CUA put into
> > > it?  The 8 possible cases to consider:
> > > ....
> 
> > The CS is not a tape archive. It can manipulate the data, other users
> > can update the data. It can represent the data differently. I recall
> > a conversation where one vendor wanted to unwind some RRULEs when
> > they pulled it out (REPEAT 5 days -> 5 unique DATE entries).
> 
> As a customer, I can safely say that I'd like to be able to import
> everything related to a calendar store (calendars, ACL's, etc).  I'd
> also like to export that same set of things that I can import.  It
> should be completely bi-directional.  Do not trap me in an
> implementation or think that it's ok to ask the user to re-enter data.

I think we agree.

	If a CUA deposits a VCALENDAR with the following VEVENT:

			BEGIN:VEVENT
			DESCRIPTION:.....bla bla baa
			SUMMARY: boring....
			.
			.
			END:VEVENT

I say the CS may return:

			BEGIN:VEVENT
			SUMMARY: boring....
			.
			.
			DESCRIPTION:.....bla bla baa
			.
			END:VEVENT

And it is the same. No need to preserve the same data in EXACTLY the same order.
And this by the way would break a signature that may have come in with the
original data. I say - so what - the signature is not an ical object and
the signature is only for accounting - out of scope.

> While I agree that users change things (and thus checksums), I'd like to
> suggest that the CS should not transform the data as it come in. There
> is a difference between a meeting which repeats for five days and 5
> unique events.

I agree. And I did not like the RRULE transformed into a single VEVENT
with 5 RDATEs. But it is the same thing.
--------------DF7AC1D848A9FBC4CD8DFD4A
Content-Type: text/x-vcard; charset=us-ascii;
 name="doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="doug.vcf"

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

--------------DF7AC1D848A9FBC4CD8DFD4A--

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

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
ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTE0MjAzNTI1WjAjBgkqhkiG9w0BCQQxFgQUx/FGKcNq
YUib9i3KR6fipj8ikekwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYAHe/cJQOxcu0ZwpVGBCR2x0KRH4wFvxj12UUx/nX55EcoCxHHtejYCFAhXrju4
bNaYSDIyC/J81uiPyYNEcM0Rx1M09NumULhUFkEfc/oLo1MjPtuvNH7lG5etTbjZlVhuqDOs
LGGwAr+XmF9Jc6JnBY420ffHMKNcGQWKfIZbkg==
--------------msEE6A10B681B9CC4002C81FA7--


From owner-ietf-calendar  Fri Jan 14 17:33:11 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id RAA07173
	for ietf-calendar-bks; Fri, 14 Jan 2000 17:33:11 -0800 (PST)
Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA07169
	for <ietf-calendar@imc.org>; Fri, 14 Jan 2000 17:32:54 -0800 (PST)
From: pregen@egenconsulting.com
To: Paul Overell <paulo@turnpike.com>
Cc: ietf-calendar@imc.org
Subject: Re: iMIP, RFC2447 and [RFC-1847]-compliant encryption
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF28A84AE4.0F4D144C-ON85256867.00088929@com>
Date: Fri, 14 Jan 2000 20:33:39 -0500
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at
 01/14/2000 08:33:38 PM,
	Serialize complete at 01/14/2000 08:33:38 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0008932D85256867_="
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 0008932D85256867_=
Content-Type: text/plain; charset="us-ascii"

I like the worded suggestion in this note.  It's clear, brief and to the 
point.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652




Paul Overell <paulo@turnpike.com>
Sent by: owner-ietf-calendar@imc.org
01/14/00 05:16 AM

 
        To:     ietf-calendar@imc.org
        cc: 
        Subject:        Re: iMIP, RFC2447 and [RFC-1847]-compliant encryption

In article <387E2DBB.6FE6D426@Software.com>, Doug Royer
<Doug.Royer@Software.com> writes
>
>Paul Overell wrote:
>>
>> iMIP, RFC2447 says:
>>
>> >2.2.3 Confidentiality
>> >
>> >   To ensure confidentiality using iMIP implementations should utilize
>> >   [RFC-1847]-compliant encryption.
>> >
>>
>> This implicitly excludes S/MIME encryption (RFC2633 etc) as S/MIME's
>> encryption is not [RFC-1847]-compliant - i.e. S/MIME does not use
>> multipart/encrypted.
>>
>> Is this exclusion of S/MIME intentional or have I misunderstood
>> something here?
>>


>As I could not find a reply to this, I'll try.
>

Thanks - I was beginning to feel left out  :).

>We want S/MIME, and most of us are not security experts, what
>do you suggest? Is there a better text or RFC, or should
>it be dropped?
>


I know of no better RFC.   PGP/MIME encryption is RFC1847 compliant,
S/MIME encryption isn't.

As S/MIME was not explicitly specified I assume that the intention was
to leave the actual encryption scheme unspecified.

You ask for a suggestion, how about:

        To ensure confidentiality using iMIP implementations SHOULD
        utilize encryption.  It is outside the scope of this memo to
        specify specific encryption schemes.



Regards
-- 
Paul Overell                                        T U R N P I K E  Ltd



--=_alternative 0008932D85256867_=
Content-Type: text/html; charset="us-ascii"




<br><font size=2 face="sans-serif">I like the worded suggestion in this note. &nbsp;It's clear, brief and to the point.<br>
___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Paul Overell &lt;paulo@turnpike.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">01/14/00 05:16 AM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;ietf-calendar@imc.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: iMIP, RFC2447 and [RFC-1847]-compliant encryption</font></table>
<br>
<br><font size=2><tt>In article &lt;387E2DBB.6FE6D426@Software.com&gt;, Doug Royer<br>
&lt;Doug.Royer@Software.com&gt; writes<br>
&gt;<br>
&gt;Paul Overell wrote:<br>
&gt;&gt;<br>
&gt;&gt; iMIP, RFC2447 says:<br>
&gt;&gt;<br>
&gt;&gt; &gt;2.2.3 Confidentiality<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &nbsp; To ensure confidentiality using iMIP implementations should utilize<br>
&gt;&gt; &gt; &nbsp; [RFC-1847]-compliant encryption.<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; This implicitly excludes S/MIME encryption (RFC2633 etc) as S/MIME's<br>
&gt;&gt; encryption is not [RFC-1847]-compliant - i.e. S/MIME does not use<br>
&gt;&gt; multipart/encrypted.<br>
&gt;&gt;<br>
&gt;&gt; Is this exclusion of S/MIME intentional or have I misunderstood<br>
&gt;&gt; something here?<br>
&gt;&gt;<br>
<br>
<br>
&gt;As I could not find a reply to this, I'll try.<br>
&gt;<br>
<br>
Thanks - I was beginning to feel left out &nbsp;:).<br>
<br>
&gt;We want S/MIME, and most of us are not security experts, what<br>
&gt;do you suggest? Is there a better text or RFC, or should<br>
&gt;it be dropped?<br>
&gt;<br>
<br>
<br>
I know of no better RFC. &nbsp; PGP/MIME encryption is RFC1847 compliant,<br>
S/MIME encryption isn't.<br>
<br>
As S/MIME was not explicitly specified I assume that the intention was<br>
to leave the actual encryption scheme unspecified.<br>
<br>
You ask for a suggestion, how about:<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;To ensure confidentiality using iMIP implementations SHOULD<br>
 &nbsp; &nbsp; &nbsp; &nbsp;utilize encryption. &nbsp;It is outside the scope of this memo to<br>
 &nbsp; &nbsp; &nbsp; &nbsp;specify specific encryption schemes.<br>
<br>
<br>
<br>
Regards<br>
-- <br>
Paul Overell &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;T U R N P I K E &nbsp;Ltd<br>
</tt></font>
<br>
<br>
--=_alternative 0008932D85256867_=--

From owner-ietf-calendar  Sat Jan 15 23:59:22 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA00977
	for ietf-calendar-bks; Sat, 15 Jan 2000 23:59:22 -0800 (PST)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00973
	for <ietf-calendar@imc.org>; Sat, 15 Jan 2000 23:59:20 -0800 (PST)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA29769
	for ietf-calendar@imc.org; Sun, 16 Jan 2000 00:00:03 -0800 (PST)
Date: Sun, 16 Jan 2000 00:00:03 -0800 (PST)
From: Doug Royer <Doug@Royer.Com>
Message-Id: <200001160800.AAA29769@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

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

 W-31 NOOP command?				U

 W-32 NOOP advisory only?			U

 W-33 Should DISCONNECT be called QUIT?		U

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

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

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

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

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

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

 C-13 Post CAP-00.txt					Y

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

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

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

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

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

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

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

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

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


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  Sun Jan 16 14:01:31 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id OAA13665
	for ietf-calendar-bks; Sun, 16 Jan 2000 14:01:31 -0800 (PST)
Received: from unknown (caga2pp43.alltel.net [166.102.95.44])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA13659;
	Sun, 16 Jan 2000 14:01:26 -0800 (PST)
From: bmark@crosswinds.net
Subject: laser printer toner advertisement
Date: Mon, 17 Jan 2000 01:55:38
Message-Id: <71.830302.675131@>
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>






BENCHMARK SUPPLY
7540 BRIDGEGATE COURT
ATLANTA GA 30350

***LASER PRINTER TONER CARTRIDGES***
***FAX AND COPIER TONER***

WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS
JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS

 
   CHECK OUT OUR NEW CARTRIDGE PRICES :
 

APPLE 
 
  LASER WRITER  PRO 600 OR 16/600         $69
  LASER WRITER SELECT 300,310.360         $69
  LASER WRITER 300, 320                   $54 
  LASER WRITER LS,NT,2NTX,2F,2G & 2SC     $54 
  LASER WRITER 12/640                     $79 

HEWLETT PACKARD 

  LASERJET SERIES 2,3 & 3D (95A)          $49 
  LASERJET SERIES  2P AND 3P (75A)        $54 
  LASERJET SERIES 3SI AND 4SI (91A)       $75 
  LASERJET SERIES 4L AND 4P               $49 
  LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A)  $59 
  LASERJET SERIES 4000 HIGH YIELD  (27X)  $99 
  LASERJET SERIES 4V                      $95 
  LASERJET SERIES 5SI , 8000              $95 
  LASERJET SERIES 5L AND 6L               $49 
  LASERJET SERIES 5P, 5MP, 6P, 6MP        $59 
  LASERJET SERIES 5000 (29A)             $135
  LASERJET SERIES 1100 (92A)              $49 
  LASERJET SERIES 2100 (96A)              $89
  LASERJET SERIES 8100 (82X)		 $145


HP LASERFAX 

  LASERFAX 500, 700, FX1,                 $59 
  LASERFAX 5000, 7000, FX2,               $59 
  LASERFAX  FX3                           $69 
  LASERFAX  FX4                           $79 
 

LEXMARK 

  OPTRA  4019, 4029  HIGH YIELD          $135 
  OPTRA R, 4039, 4049 HIGH YIELD         $135 
  OPTRA S 4059 HIGH YIELD                $135 
  OPTRA E                                 $59 
  OPTRA  N                               $115 
 

EPSON 

  EPL-7000, 8000                         $105 
  EPL-1000, 1500                         $105 
 

CANON 

  LBP-430                                 $49 
  LBP-460, 465                            $59 
  LBP-8 II                                $54 
  LBP-LX                                  $54 
  LBP-MX                                  $95 
  LBP-AX                                  $49 
  LBP-EX                                  $59 
  LBP-SX                                  $49 
  LBP-BX                                  $95 
  LBP-PX                                  $49 
  LBP-WX                                  $95 
  LBP-VX                                  $59 
  CANON FAX L700 THRU L790 FX1            $59 
  CANONFAX L5000 L70000  FX2              $59 
 

CANON COPIERS 

  PC 20, 25 ETC....                       $89 
  PC 3, 6RE, 7, 11  (A30)                 $69 
  PC 320 THRU 780  (E40)                  $89 
 

NEC 

  SERIES 2 LASER MODEL 90,95             $105


PLEASE NOTE:

1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES.
2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 
3) WE DO NOT FAX QUOTES OR PRICE LISTS.  
4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS
5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS
6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS
7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES    
8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES
9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS

   
               

****OUR  ORDER LINE IS 770-399-0953 ****

****OUR CUSTOMER SERVICE  LINE IS 800-586-0540****
****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-494-8597****

****PLACE YOUR ORDER AS FOLLOWS**** :

BY PHONE   770-399-0953 

BY FAX:    770-698-9700 
BY MAIL:   BENCHMARK PRINT SUPPLY
           7540 BRIDGEGATE COURT
,          ATLANTA GA 30350

MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 

             1)  YOUR PHONE NUMBER 
             2)  COMPANY NAME 
             3)  SHIPPING ADDRESS 
             4)  YOUR NAME 
             5)  ITEMS NEEDED WITH QUANTITIES 
             6)  METHOD OF PAYMENT. (COD OR CREDIT CARD) 
             7)  CREDIT CARD NUMBER WITH EXPIRATION DATE 

 
1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING.
2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST.
2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS.
3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS
4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. 


NOTE NUMBER (1): 

PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL 
ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD 
YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR 
COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS 
WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE 
HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND 
COMPLAINT LINE TO DO THAT.

NOTE NUMBER (2):

OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY 
QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL 
RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT 
THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER
 OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR 
CUSTOMER SERCICE LINE.







 
 
 
 
 
 
 
 
 
 

From owner-ietf-calendar  Mon Jan 17 08:34:37 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA09663
	for ietf-calendar-bks; Mon, 17 Jan 2000 08:34:37 -0800 (PST)
Received: from localhost.localdomain (outbound.ecal.com [209.218.166.156] (may be forged))
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09659
	for <ietf-calendar@imc.org>; Mon, 17 Jan 2000 08:34:36 -0800 (PST)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id LAA31342
	for <ietf-calendar@imc.org>; Mon, 17 Jan 2000 11:35:47 -0500
Message-ID: <388344E2.A426A755@ecal.com>
Date: Mon, 17 Jan 2000 11:35:47 -0500
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: Re: Poll: What goes in...
References: <OF0D231118.BE571D00-ON8525683A.005DD32C@iris.com> <387E305B.8FB050EB@Software.com> <387F621D.98376@msdw.com> <387F888B.F1F85B65@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>

Doug Royer wrote:

> And it is the same. No need to preserve the same data in EXACTLY the same order.
> And this by the way would break a signature that may have come in with the
> original data.  I say - so what - the signature is not an ical object and

> the signature is only for accounting - out of scope.

The signature is for security, which is never out of scope.  We clearly can't mandate
that the server preserve end-to-end signatures (if we did, nobody could build a
conformant server without throwing away their existing data store); but we ought to
provide a protocol that *can* deliver the signature if the server is built to do it.

(Encryption, of course, is another matter; you can't reasonably build a calendar
server that isn't allowed to know what time your events are, or you'll never be able
to search it efficiently.  :-)

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Your reality, sir, is lies & balderdash, and I|
|francis@ecal.com|am pleased to say I have no grasp on it        |
|                |whatsoever!" --Baron Munchausen                |
\================================================================/




From owner-ietf-calendar  Tue Jan 18 01:15:33 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id BAA10396
	for ietf-calendar-bks; Tue, 18 Jan 2000 01:15:33 -0800 (PST)
Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA10391
	for <ietf-calendar@imc.org>; Tue, 18 Jan 2000 01:15:31 -0800 (PST)
Received: from joyce (unknown [193.14.119.6])
	by ljudo.shortlist.se (Postfix) with SMTP
	id A656DB34CE; Tue, 18 Jan 2000 10:16:24 +0100 (CET)
From: "Greg FitzPatrick" <gf@medianet.org>
To: "Michael Krivoruchko" <misha@ireland.sun.com>, <Frank_Dawson@lotus.com>
Cc: <ietf-calendar@imc.org>
Subject: SV: XML DTD update proposition
Date: Tue, 18 Jan 2000 10:15:52 +0100
Message-ID: <NCBBJIFAOLHFMAPPOLHCEEONCLAA.gf@medianet.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <38765E38.24C87BD3@ireland.sun.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA10393
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>

Frank 

How are we doing on this?  Sounds like a very good idea (necessity).  Have you talked to Paul about this - do you want me to do it?

I have the entire SKiCal draft in a DTD/Schema  and I am really in need of agile minds to volley with.

Greg

> We may want to take this
>  to a XML iCalendar mailing list. I can ask IMC if they would host this.



From owner-ietf-calendar  Tue Jan 18 11:52:01 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA24813
	for ietf-calendar-bks; Tue, 18 Jan 2000 11:52:01 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA24804
	for <ietf-calendar@imc.org>; Tue, 18 Jan 2000 11:51:59 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA03098; Tue, 18 Jan 00 14:52:36 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id OAA00140
	for <ietf-calendar@imc.org>; Tue, 18 Jan 2000 14:53:01 -0500 (EST)
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 OAA08518
	for <ietf-calendar@imc.org>; Tue, 18 Jan 2000 14:53:00 -0500 (EST)
Message-Id: <4.2.0.58.20000118143519.018211f0@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 18 Jan 2000 14:49:54 -0500
To: ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: reminder: WG Interim Meeting - January 25-27, looking for
  headcount
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,

I'm trying to get a headcount for the up coming interim meeting. Please let 
me know if you plan to attend.

Current known list of attendees:
Bob Mahoney                     (MIT)
Paul B. Hill                    (MIT)
Frank Dawson                    (Lotus)
Bruce Khan                      (Iris)
Dave Madeo                      (Morgan Stanley Dean Witter and Co.)
Michael Ciavarini               (On Technology)

Meeting logistics:

There will a CALSCH Interim Working Group Meeting held in Boston.  The 
information is included below.  This meeting is to resolve the outstanding 
items that are posted on the CALSCH working group list on a weekly basis.

When:
Tuesday, January 25th
Wednesday, January 26th
Thursday, January 27th (half day)

Where:
MIT, E40
Cambridge, MA

We have a room for an interim meeting on January 25th, 26th, and 27th. The
room is reserved from 8:30am - 5:30pm on Tuesday and Wednesday, and from
8:30am - noon on Thursday.


The main room will be E40-302. The breakout room will be E40-316.

How to get to MIT: <http://whereis.mit.edu/doc/getting-to-mit.html>

Map highlighting the location of Building E40 (aka 1 Amherst Street):
<http://whereis.mit.edu/bin/map?locate=bldg_e40>


Paul

From owner-ietf-calendar  Tue Jan 18 19:53:57 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id TAA10294
	for ietf-calendar-bks; Tue, 18 Jan 2000 19:53:57 -0800 (PST)
Received: from mta1biz.bizmailsrvcs.net (mta1.bizmailsrvcs.net [206.46.164.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10288
	for <ietf-calendar@imc.org>; Tue, 18 Jan 2000 19:53:56 -0800 (PST)
Received: from Software.com ([207.175.94.216]) by mta1biz.bizmailsrvcs.net
          with ESMTP
          id <20000119035435.OYFN4639007.mta1biz.bizmailsrvcs.net@Software.com>;
          Tue, 18 Jan 2000 21:54:35 -0600
Message-ID: <38853567.9601B2BE@Software.com>
Date: Tue, 18 Jan 2000 19:54:15 -0800
From: Doug Royer <Doug.Royer@software.com>
Reply-To: ietf-calendar@imc.org
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: (W-35)SLP and CAP
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB60E84D0C53241CB068D81C5"
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.

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


Would anyone have a problem if the SLP (service location protocol) was
moved out of CAP and into a separate document?

CAP does not depend on SLP.   It was added to the CAP draft
when there were questions about how to locate a CAP server.

However after thinking about it, I think it should be in a
separate document.

Comments?

Steve Mansour and I will be taking it out of CAP unless there
are objections.

THANKS!

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

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


From owner-ietf-calendar  Thu Jan 20 11:06:00 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA25914
	for ietf-calendar-bks; Thu, 20 Jan 2000 11:06:00 -0800 (PST)
Received: from wesync-ex.wesync.com ([204.245.201.138])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25910
	for <ietf-calendar@imc.org>; Thu, 20 Jan 2000 11:05:58 -0800 (PST)
Received: from WILLY ([192.168.1.108]) by wesync-ex.wesync.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id DJGTCHVF; Thu, 20 Jan 2000 11:09:21 -0800
Message-Id: <3.0.6.32.20000120110737.03762470@192.168.1.120>
X-Sender: willy@192.168.1.120
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Thu, 20 Jan 2000 11:07:37 -0800
To: ietf-calendar@imc.org
From: Willy Mills <willy@wesync.com>
Subject: Re: Poll: What goes in...
In-Reply-To: <387F888B.F1F85B65@home.royer.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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>

At 12:35 1/14/00 -0800, you wrote:
>David Madeo wrote:
>> 
>> Doug Royer wrote:
>> >
>> > Bruce_Kahn@iris.com wrote:
>> > >
>> > > must come out?  During some of the hallway converstations in DC I
>got into a
>> > > discussion w/others about data preservation and integrity.  Some
>folks think
>> > > that the data you put into the CS does not have to come back out
>"intact".
>> > >  (By "intact" I do not mean byte for byte exact unless necessary
>for stuff
>> > > like multipart/signed or multipart/encrypted.)  After some heated
>back and
>> > > forth we reset the talk and I tried to learn more about their POV.
>I think
>> > > after a nights sleep we were able to pick up the discussion but I
>left
>> > > somewhat dazed on this issue.
>> > >
>> > > So Im taking a poll of the list to see what others expect from
>their CS.
>> > >  Should the CS return to you the equivalent MIME data that the CUA
>put into
>> > > it?  The 8 possible cases to consider:
>> > > ....
>> 
>> > The CS is not a tape archive. It can manipulate the data, other
>users
>> > can update the data. It can represent the data differently. I recall
>> > a conversation where one vendor wanted to unwind some RRULEs when
>> > they pulled it out (REPEAT 5 days -> 5 unique DATE entries).
>> 
>> As a customer, I can safely say that I'd like to be able to import
>> everything related to a calendar store (calendars, ACL's, etc).  I'd
>> also like to export that same set of things that I can import.  It
>> should be completely bi-directional.  Do not trap me in an
>> implementation or think that it's ok to ask the user to re-enter data.
>
>I think we agree.
>
>	If a CUA deposits a VCALENDAR with the following VEVENT:
>
>			BEGIN:VEVENT
>			DESCRIPTION:.....bla bla baa
>			SUMMARY: boring....
>			.
>			.
>			END:VEVENT
>
>I say the CS may return:
>
>			BEGIN:VEVENT
>			SUMMARY: boring....
>			.
>			.
>			DESCRIPTION:.....bla bla baa
>			.
>			END:VEVENT
>
>And it is the same. No need to preserve the same data in EXACTLY the
>same order.
>And this by the way would break a signature that may have come in with
>the
>original data. I say - so what - the signature is not an ical object and
>the signature is only for accounting - out of scope.
>
>> While I agree that users change things (and thus checksums), I'd like
>to
>> suggest that the CS should not transform the data as it come in. There
>> is a difference between a meeting which repeats for five days and 5
>> unique events.
>
>I agree. And I did not like the RRULE transformed into a single VEVENT
>with 5 RDATEs. But it is the same thing.
>
>
>Attachment Converted: "d:\eudora\attach\doug12.vcf"
>

The general solution is:
Signing:
A) Transform the object to a specified canonical form.
B) Sign the transformed object.
C) Associate the signature with the original object.
Validating:
A) Retrieve the object and the associated signature
B) Transform the retrieved object to the specified canonical form.
C) Verify the signature matches the canonical form.

The transformation to canonical form would seem to be highly dependent upon
the application context. It should delete irrelevant data and provide a
deterministic form (specified sort order, etc.) for the remainder. The
notion of what is "irrelevant" is the application context dependent
aspect. So specifying any canonical form would seem out of scope
as it depends on the application use.
An issue I find relevant is the issue regarding RRULE preservation.
Am I correct in my suspicion that converting RRULE data to
canonical form (equivalently comparing two RRULE items for equality)
is one of those algorithmically hard problems? Is it even computable?
If so then transforming RRULE data makes it difficult to solve
the signature problem. The issue of data inclusion and ordering
is not nearly as problematic.

I'm not proposing any changes, just hoping to clarify
some issues.


Greetings,
Willy <willy@wesync.com>

From owner-ietf-calendar  Fri Jan 21 15:13:31 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id PAA12357
	for ietf-calendar-bks; Fri, 21 Jan 2000 15:13:31 -0800 (PST)
Received: from pivsbh1.ms.com (pivsbh1.ms.com [199.89.64.103])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12353
	for <ietf-calendar@imc.org>; Fri, 21 Jan 2000 15:13:29 -0800 (PST)
Received: (from uucp@localhost)
        by pivsbh1.ms.com (8.9.3/fw v1.30) id SAA11202
        for <ietf-calendar@imc.org>; Fri, 21 Jan 2000 18:14:46 -0500 (EST)
Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1)
	id sma.9484964831.011114; Fri, 21 Jan 00 18:14:43 -0500
Received: by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id SAA11109
	for <ietf-calendar@imc.org>; Fri, 21 Jan 2000 18:14:43 -0500 (EST)
X-Authentication-Warning: pivsbh1.ms.com: Processed from queue /var/spool/mqueue-vs
X-Authentication-Warning: pivsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf
X-Interface: IDMZ
Received: from sasmh4.ms.com(144.14.193.5) by pivsbh1 via smap (4.1)
	id sma.9484964771.011069; Fri, 21 Jan 00 18:14:37 -0500
Received: from msdw.com (vector.morgan.com [144.14.16.149])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id SAA07040
        for <ietf-calendar@imc.org>; Fri, 21 Jan 2000 18:14:36 -0500 (EST)
Message-ID: <3888E85C.B2013B36@msdw.com>
Date: Fri, 21 Jan 2000 18:14:36 -0500
From: David Madeo <David.Madeo@msdw.com>
Reply-To: David.Madeo@msdw.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
MIME-Version: 1.0
To: ietf-calendar@imc.org
Subject: CAP Agenda
References: <200001160800.AAA29769@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>


As some of you may have noticed, Paul Hill of MIT is hosting a CAP
editors meeting next week in Boston.  In an effort to make the time
there as productive as possible and properly involve the mailing list,
I'd like to suggest that we work out the agenda for the meeting NOW and
on the list.  

Doug Royer's list of action items appears to be the best starting
point.  I've removed any "N" or "D" entries from the list.  I have a
question about the "Y"'s  Can we differentiate between the Y's which are
done and the Y's which are not done?

For the rest, I've gone through and indicated either my personal 
interest level or a position on each of the U's.  The number in
parantheseis is a ranking of whether it should be on the agenda in
Boston (1 = yes, 2 = maybe, 3 = later)  The fundamental question is what
will it take to resolve the "U"'s into "Y|N" and then turn that into CAP
text.

If everyone on the list can help by replying to this message and putting
your own levels of interest/positions down, we can pick an agenda that's
worth doing and start identifying who should be stepping up to the
plate.

Thanks,

dmadeo


>                         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-2 CAP If all booked and scheduled            U
>      appointments are in same table

dmadeo - not interested

>  W-3 CAP Use SASL as authentication method      Y
> 
>  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-9 CAP MOVE method. Issues with VCARs.        U
>      [see note in CAP 7.2.1.5]

dmadeo - interested (1)

>  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

dmadeo - not interested (yet)

>  W-18 CAP UPN definition, including anonymous   U
>       user and how UPN's are used in LDAP and
>       certificates.

dmadeo - interested (2)

>  W-19 CAP Group definitions, dynamic and        U
>       static and how groups are used in VCARs.
>       Policy definitions, in a VCAR format.

dmadeo - interested (2)

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

dmadeo - interested (2)

>  W-22 VTIMEZONE and IANA                        U

dmadeo - interested (2)

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

dmadeo -  Yes (1) 

>  W-24 CAP Calendar CHARSET property issues      U

dmadeo - not interested unless its not UTF-8

>  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

dmadeo - not interested

>  W-29 Import/Export                             U

dmadeo - interested (1) 

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

dmadeo - interested (3) 

>  W-31 NOOP command?                             U
>  W-32 NOOP advisory only?                       U

dmadeo - interested (3) 

>  W-33 Should DISCONNECT be called QUIT?         U

dmadeo - not interested

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

dmadeo - not interested





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

Didn't Steve Mansour already do this?

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

From owner-ietf-calendar  Sat Jan 22 11:47:16 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01793
	for ietf-calendar-bks; Sat, 22 Jan 2000 11:47:16 -0800 (PST)
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 LAA01789
	for <ietf-calendar@imc.org>; Sat, 22 Jan 2000 11:47:15 -0800 (PST)
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 PAA09416;
	Sat, 22 Jan 2000 15:03:24 -0500 (EST)
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 OAA22942;
	Sat, 22 Jan 2000 14:48:09 -0500 (EST)
To: Antony Davies <adavies@rim.net>
Cc: ietf-calendar@imc.org
Subject: Re: quoted printable in DESCRIPTION
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF14D0E126.AA11788C-ON8525686E.006CB275@Lotus.com>
Date: Sat, 22 Jan 2000 14:50:06 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/22/2000 02:50:10 PM,
	Serialize complete at 01/22/2000 02:50:10 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006CE4BC8525686E_="
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 006CE4BC8525686E_=
Content-Type: text/plain; charset="us-ascii"

Antony:
Am behind in my email, so apologize if some one else has already answered 
this.
Your note mentions processing a vCalendar object, which allows for 
Quoted-Printable encoding of text property values.
However, you mention this not being allowed by RFC 2445, which is the 
proposed standard specification for iCalendar. iCalendar, as you note, 
does not allow use of Q-P encoding, but makes use of backslash encoded 
formatted text.
vCalendar != iCalendar
You will have to parse both, if you want vCalendar and iCalendar features.
-- Frank


--=_alternative 006CE4BC8525686E_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Antony:</font>
<p><font size=3 face="Courier New">Am behind in my email, so apologize if some one else has already answered this.</font>
<p><font size=3 face="Courier New">Your note mentions processing a vCalendar object, which allows for Quoted-Printable encoding of text property values.</font>
<p><font size=3 face="Courier New">However, you mention this not being allowed by RFC 2445, which is the proposed standard specification for iCalendar. iCalendar, as you note, does not allow use of Q-P encoding, but makes use of backslash encoded formatted text.</font>
<p><font size=3 face="Courier New">vCalendar != iCalendar</font>
<p><font size=3 face="Courier New">You will have to parse both, if you want vCalendar and iCalendar features.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
<p>
--=_alternative 006CE4BC8525686E_=--

From owner-ietf-calendar  Sat Jan 22 23:58:48 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA26322
	for ietf-calendar-bks; Sat, 22 Jan 2000 23:58:48 -0800 (PST)
Received: from royer.com (royer.com [207.177.146.80])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA26318
	for <ietf-calendar@imc.org>; Sat, 22 Jan 2000 23:58:46 -0800 (PST)
Received: (from doug@localhost)
	by royer.com (8.9.1/8.9.1) id AAA07144
	for ietf-calendar@imc.org; Sun, 23 Jan 2000 00:00:03 -0800 (PST)
Date: Sun, 23 Jan 2000 00:00:03 -0800 (PST)
From: Doug Royer <Doug@royer.com>
Message-Id: <200001230800.AAA07144@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

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

 W-31 NOOP command?				U

 W-32 NOOP advisory only?			U

 W-33 Should DISCONNECT be called QUIT?		U

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

 W-35 Move DNS and SLP to seperate draft?	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:

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

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

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

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

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


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  Sun Jan 23 11:39:54 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA08333
	for ietf-calendar-bks; Sun, 23 Jan 2000 11:39:54 -0800 (PST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08329
	for <ietf-calendar@imc.org>; Sun, 23 Jan 2000 11:39:53 -0800 (PST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id LAA21021
	for <ietf-calendar@imc.org>; Sun, 23 Jan 2000 11:37:55 -0800 (PST)
Received: from netscape.com ([198.93.95.223]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FOT00600.VLY; Sun, 23 Jan 2000 11:40:54 -0800 
Message-ID: <388B5973.67345ADA@netscape.com>
Date: Sun, 23 Jan 2000 11:41:40 -0800
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>,
        Chris Newman <Chris.Newman@innosoft.com>
Subject: CAP Transfer Protocol "debug text"
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>

Chris,

In your comments on the CAP protocol
(http://www.imc.org/ietf-calendar/mail-archive/msg02990.html), you made
a sugestion on the response-codes and text:

>  Also, if there's human readable text included with response codes,
then
>  there needs to be a specified language for that text.  It can be done
as:

> The text is "i-default" meaning it's in English intended for
international
> readers, and may also include a translation of the text appropriate to
the
> locale.

I'm don't understand the part about including a translation of the text
into an appropriate locale. Are you saying that the comment would
(could) be in English AND in some other language?  How would we know
what the other charset / locale is?  Could you give a quick example of
what you are suggesting?

-Steve


From owner-ietf-calendar  Sun Jan 23 12:32:59 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08860
	for ietf-calendar-bks; Sun, 23 Jan 2000 12:32:59 -0800 (PST)
Received: from eljefe.innosoft.com (ELJEFE.INNOSOFT.COM [192.160.253.137])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08856
	for <ietf-calendar@imc.org>; Sun, 23 Jan 2000 12:32:57 -0800 (PST)
Received: from nifty-jr.innosoft.com ([192.160.253.35])
 by mail.eljefe.innosoft.com (PMDF V6.0-17 #4409)
 with ESMTPA id <0FOT0094Z219VX@mail.eljefe.innosoft.com> for
 ietf-calendar@imc.org; Sun, 23 Jan 2000 12:24:47 -0800 (PST)
Date: Sun, 23 Jan 2000 12:32:58 -0800
From: Chris Newman <chris.newman@innosoft.com>
Subject: Re: CAP Transfer Protocol "debug text"
In-reply-to: <388B5973.67345ADA@netscape.com>
To: Steve Mansour <sman@netscape.com>, CalSched IETF <ietf-calendar@imc.org>
Message-id: <919146.3157619578@nifty-jr.innosoft.com>
MIME-version: 1.0
X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n S-100003]
Content-type: text/plain; charset=us-ascii; format=flowed
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>

--On Sunday, January 23, 2000 11:41 -0800 Steve Mansour <sman@netscape.com> 
wrote:
> I'm don't understand the part about including a translation of the text
> into an appropriate locale. Are you saying that the comment would
> (could) be in English AND in some other language?  How would we know
> what the other charset / locale is?  Could you give a quick example of
> what you are suggesting?

Read RFC 2277.

Section 4.5 discusses "i-default" language.

		- Chris


From owner-ietf-calendar  Sun Jan 23 12:39:26 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08895
	for ietf-calendar-bks; Sun, 23 Jan 2000 12:39:26 -0800 (PST)
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 MAA08891;
	Sun, 23 Jan 2000 12:39:25 -0800 (PST)
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 PAA23758;
	Sun, 23 Jan 2000 15:55:42 -0500 (EST)
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 PAA18097;
	Sun, 23 Jan 2000 15:40:25 -0500 (EST)
To: sman@netscape.com (Steve Mansour)
Cc: Chris.Newman@innosoft.com, ietf-calendar@imc.org,
        owner-ietf-calendar@imc.org
Subject: Re: CAP Transfer Protocol "debug text"
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OFAA2FA95B.A856A923-ON8525686F.00717006@Lotus.com>
Date: Sun, 23 Jan 2000 15:42:32 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/23/2000 03:41:34 PM,
	Serialize complete at 01/23/2000 03:41:34 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0071B1DA8525686F_="
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 0071B1DA8525686F_=
Content-Type: text/plain; charset="us-ascii"

Steve and Chris:
Why is this there a requirement for this extra text to be localed? Why 
can't it just be in a single language such as English? Isn't this what is 
done in other IETF protocols, such as HTTP command set? For example:
        Server response: "200 OK"
This is an over-the-wire, machine processable command set. I am not 
convinced that this requires localizations of the information.
-- Frank

--=_alternative 0071B1DA8525686F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Steve and Chris:</font>
<p><font size=3 face="Courier New">Why is this there a requirement for this extra text to be localed? Why can't it just be in a single language such as English? Isn't this what is done in other IETF protocols, such as HTTP command set? For example:</font>
<p><font size=3 face="Courier New">&nbsp; &nbsp; &nbsp; &nbsp; Server response: &quot;200 OK&quot;</font>
<p><font size=3 face="Courier New">This is an over-the-wire, machine processable command set. I am not convinced that this requires localizations of the information.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 0071B1DA8525686F_=--

From owner-ietf-calendar  Sun Jan 23 13:51:32 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09420
	for ietf-calendar-bks; Sun, 23 Jan 2000 13:51:32 -0800 (PST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09416
	for <ietf-calendar@imc.org>; Sun, 23 Jan 2000 13:51:31 -0800 (PST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id NAA25581
	for <ietf-calendar@imc.org>; Sun, 23 Jan 2000 13:49:33 -0800 (PST)
Received: from netscape.com ([198.93.95.223]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FOT63L00.6RU for <ietf-calendar@imc.org>; Sun, 23 Jan 2000
          13:52:33 -0800 
Message-ID: <388B784E.22F7DEF7@netscape.com>
Date: Sun, 23 Jan 2000 13:53:18 -0800
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: NOOP command - your feedback needed
Content-Type: multipart/alternative;
 boundary="------------CD6B9C6C1E8E765D44E66CCC"
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>


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

Folks,

Doug and I had a quick talk about the NOOP command. Since CAP currently
states that an idle CAP connection can be dropped by the server, people
wanted a NOOP command as a way to keep a connection to the server
active.

We've seen a problem in the way the NOOP command is used (or misused) in
IMAP. Clients issue NOOP commands to keep the connection to the server
alive. This can cause a situation where lots of clients log in to a
server, hold their connections open for hours during which they sit idle
(except for issuing the NOOP commands). Others trying to access the
server during this time will receive connection refusals or "server too
busy" errors.

It is also used as a way to get the IMAP server to spew back pending
data. That is, the NOOP command is being used in a way it probably
wasn't intended to be.

So, the questions are:

   * Do we really want a NOOP command in CAP?
   * If so, it seems like we might want to allow the server to drop the
     connection anyway to avoid idle connections building up.  So, the
     server should probably be able to drop a connection at its
     discretion.  Do we _really_ want a NOOP command?

We could be overlooking something. We need your feedback.

-Steve

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Folks,
<p>Doug and I had a quick talk about the NOOP command. Since CAP currently
states that an idle CAP connection can be dropped by the server, people
wanted a NOOP command as a way to keep a connection to the server active.
<p>We've seen a problem in the way the NOOP command is used (or misused)
in IMAP. Clients issue NOOP commands to keep the connection to the server
alive. This can cause a situation where lots of clients log in to a server,
hold their connections open for hours during which they sit idle (except
for issuing the NOOP commands). Others trying to access the server during
this time will receive connection refusals or "server too busy" errors.
<p>It is also used as a way to get the IMAP server to spew back pending
data. That is, the NOOP command is being used in a way it probably wasn't
intended to be.
<p>So, the questions are:
<ul>
<li>
Do we really want a NOOP command in CAP?</li>

<li>
If so, it seems like we might want to allow the server to drop the connection
anyway to avoid idle connections building up.&nbsp; So, the server should
probably be able to drop a connection at its discretion.&nbsp; Do we _really_
want a NOOP command?</li>
</ul>
We could be overlooking something. We need your feedback.
<p>-Steve</html>

--------------CD6B9C6C1E8E765D44E66CCC--


From owner-ietf-calendar  Sun Jan 23 14:15:26 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09726
	for ietf-calendar-bks; Sun, 23 Jan 2000 14:15:26 -0800 (PST)
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 OAA09721;
	Sun, 23 Jan 2000 14:15:25 -0800 (PST)
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 RAA25345;
	Sun, 23 Jan 2000 17:31:42 -0500 (EST)
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 RAA19792;
	Sun, 23 Jan 2000 17:16:25 -0500 (EST)
To: sman@netscape.com (Steve Mansour)
Cc: ietf-calendar@imc.org, owner-ietf-calendar@imc.org
Subject: Re: NOOP command - your feedback needed
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OFBF198344.09F6BABD-ON8525686F.007A3458@Lotus.com>
Date: Sun, 23 Jan 2000 17:18:33 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/23/2000 05:17:35 PM,
	Serialize complete at 01/23/2000 05:17:35 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 007A7C038525686F_="
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 007A7C038525686F_=
Content-Type: text/plain; charset="us-ascii"

Steve:
Since you are proposing that servers can drop idle connections or idle 
connections that are just kept alive with NOOP commands, what is the 
practical use of keeping the NOOP?
Can't the CUA request a longer idle interval? In which case the original 
use of NOOP is minimized, wouldn't it?
-- Frank
--=_alternative 007A7C038525686F_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Steve:</font>
<p><font size=3 face="Courier New">Since you are proposing that servers can drop idle connections or idle connections that are just kept alive with NOOP commands, what is the practical use of keeping the NOOP?</font>
<p><font size=3 face="Courier New">Can't the CUA request a longer idle interval? In which case the original use of NOOP is minimized, wouldn't it?</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 007A7C038525686F_=--

From owner-ietf-calendar  Sun Jan 23 14:37:15 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA09998
	for ietf-calendar-bks; Sun, 23 Jan 2000 14:37:15 -0800 (PST)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09993;
	Sun, 23 Jan 2000 14:37:14 -0800 (PST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id OAA13714;
	Sun, 23 Jan 2000 14:36:49 -0800 (PST)
Received: from netscape.com ([198.93.95.223]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FOT87S00.7NP; Sun, 23 Jan 2000 14:38:16 -0800 
Message-ID: <388B8304.F74A0D79@netscape.com>
Date: Sun, 23 Jan 2000 14:39:01 -0800
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: ietf-calendar@imc.org, owner-ietf-calendar@imc.org
Subject: Re: NOOP command - your feedback needed
References: <OFBF198344.09F6BABD-ON8525686F.007A3458@Lotus.com>
Content-Type: multipart/alternative;
 boundary="------------065083E0CE5495855B9D211D"
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>


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


Frank_Dawson@lotus.com wrote:

> Steve:
>
> Since you are proposing that servers can drop idle connections or idle
> connections that are just kept alive with NOOP commands, what is the
> practical use of keeping the NOOP?

Yes, that's basically how I see it.  The benefits of not having it are:
less commands and less chance for misuse. I posted the question to make
sure we're not overlooking something.

> Can't the CUA request a longer idle interval?

hmm... I don't know. This seems like it something that the server would
want to limit. I don't see why a server would want to honor a request
like this from a client.

> In which case the original use of NOOP is minimized, wouldn't it?

yep

>
>
> -- Frank

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>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>Since you are proposing that
servers can drop idle connections or idle connections that are just kept
alive with NOOP commands, what is the practical use of keeping the NOOP?</font></font></blockquote>
Yes, that's basically how I see it.&nbsp; The benefits of not having it
are: less commands and less chance for misuse. I posted the question to
make sure we're not overlooking something.
<blockquote TYPE=CITE><font face="Courier New"><font size=+0>Can't the
CUA request a longer idle interval?</font></font></blockquote>
hmm... I don't know. This seems like it something that the server would
want to limit. I don't see why a server would want to honor a request like
this from a client.
<blockquote TYPE=CITE><font face="Courier New"><font size=+0>In which case
the original use of NOOP is minimized, wouldn't it?</font></font></blockquote>
yep
<blockquote TYPE=CITE><font face="Courier New"><font size=+0></font></font>&nbsp;
<p><font face="Courier New"><font size=+0>-- Frank</font></font></blockquote>
</html>

--------------065083E0CE5495855B9D211D--


From owner-ietf-calendar  Sun Jan 23 14:51:34 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA10088
	for ietf-calendar-bks; Sun, 23 Jan 2000 14:51:34 -0800 (PST)
Received: from hqvsbh1.ms.com (hqvsbh1.ms.com [205.228.12.103])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10084
	for <ietf-calendar@imc.org>; Sun, 23 Jan 2000 14:51:33 -0800 (PST)
Received: (from uucp@localhost)
        by hqvsbh1.ms.com (8.9.3/fw v1.30) id RAA23707;
        Sun, 23 Jan 2000 17:53:01 -0500 (EST)
Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1)
	id sma.9486679631.023239; Sun, 23 Jan 00 17:52:43 -0500
Received: by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id RAA23178;
	Sun, 23 Jan 2000 17:52:42 -0500 (EST)
X-Authentication-Warning: hqvsbh1.ms.com: Processed from queue /var/spool/mqueue-vs
X-Authentication-Warning: hqvsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf
X-Interface: IDMZ
Received: from sasmh4.ms.com(144.14.193.5) by hqvsbh1 via smap (4.1)
	id sma.9486679531.022887; Sun, 23 Jan 00 17:52:33 -0500
Received: from msdw.com (vector.morgan.com [144.14.16.149])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id RAA12367;
        Sun, 23 Jan 2000 17:52:32 -0500 (EST)
Message-ID: <388B8630.7192886E@msdw.com>
Date: Sun, 23 Jan 2000 17:52:32 -0500
From: David Madeo <David.Madeo@msdw.com>
Reply-To: David.Madeo@msdw.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
MIME-Version: 1.0
To: Steve Mansour <sman@netscape.com>
CC: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: NOOP command - your feedback needed
References: <388B784E.22F7DEF7@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>

Steve Mansour wrote:

> We've seen a problem in the way the NOOP command is used (or misused)
> in IMAP. Clients issue NOOP commands to keep the connection to the
> server alive. This can cause a situation where lots of clients log in
> to a server, hold their connections open for hours during which they
> sit idle (except for issuing the NOOP commands). Others trying to
> access the server during this time will receive connection refusals or
> "server too busy" errors.

In corporate type situations where bandwidth isn't an issue and keeping
the connection open is better than the small delay for tearup/down, I'd
configure the server to leave the connection up as long as NOOP's keep
arriving.

In a different situation where the bandwidth is an issue and the small
delay of establishing a connection is better than keeping the
connections open, I'd configure the server to drop the connection after
the 5th consecutive NOOP.

In any case, the client should be responsible for reconnecting to the
server whenever required.  If the "newevents?" timer expires, the client
should ask the server if anything new has arrived.  If the user starts
doing something in the client, it should check the connection and
reestablish with no further action on the part of the user.

Ideally as a user, I won't even know that it was doing so.  

> It is also used as a way to get the IMAP server to spew back pending
> data. That is, the NOOP command is being used in a way it probably
> wasn't intended to be.

This sounds wrong.  It's not a "get new messages", it's the equivalent
of ping.

> So, the questions are:
> 
>    * Do we really want a NOOP command in CAP?

Yes.  

>    * If so, it seems like we might want to allow the server to drop
>      the connection anyway to avoid idle connections building up.  So,
>      the server should probably be able to drop a connection at its
>      discretion.  Do we _really_ want a NOOP command?

The server should be able to ignore the NOOP and drop the connection
whenever required.  The client should attempt to reconnect with a
backoff algorithim to prevent loading.

dmadeo

From owner-ietf-calendar  Sun Jan 23 14:55:18 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA10117
	for ietf-calendar-bks; Sun, 23 Jan 2000 14:55:18 -0800 (PST)
Received: from pivsbh1.ms.com (pivsbh1.ms.com [199.89.64.103])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10113;
	Sun, 23 Jan 2000 14:55:15 -0800 (PST)
Received: (from uucp@localhost)
        by pivsbh1.ms.com (8.9.3/fw v1.30) id RAA13632;
        Sun, 23 Jan 2000 17:56:44 -0500 (EST)
Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1)
	id sma.9486681881.013277; Sun, 23 Jan 00 17:56:28 -0500
Received: by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id RAA13270;
	Sun, 23 Jan 2000 17:56:28 -0500 (EST)
X-Authentication-Warning: pivsbh1.ms.com: Processed from queue /var/spool/mqueue-vs
X-Authentication-Warning: pivsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf
X-Interface: IDMZ
Received: from sasmh4.ms.com(144.14.193.5) by pivsbh1 via smap (4.1)
	id sma.9486681781.013026; Sun, 23 Jan 00 17:56:18 -0500
Received: from msdw.com (vector.morgan.com [144.14.16.149])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id RAA12688;
        Sun, 23 Jan 2000 17:56:18 -0500 (EST)
Message-ID: <388B8712.98926609@msdw.com>
Date: Sun, 23 Jan 2000 17:56:18 -0500
From: David Madeo <David.Madeo@msdw.com>
Reply-To: David.Madeo@msdw.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
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: Steve Mansour <sman@netscape.com>, ietf-calendar@imc.org,
        owner-ietf-calendar@imc.org
Subject: Re: NOOP command - your feedback needed
References: <OFBF198344.09F6BABD-ON8525686F.007A3458@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-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Frank_Dawson@lotus.com wrote:
> 
> Steve:
> 
> Since you are proposing that servers can drop idle connections or idle
> connections that are just kept alive with NOOP commands, what is the
> practical use of keeping the NOOP?

One additional use of a NOOP is to check if the server is still
responding for diagnostic purposes.  

We routinely create mechanisms which know how to log onto a service and
check its health.  While I'd like all vendors to make diagnostic
information available from the command line/API, I'll settle with "I'm
still accepting commands and doing something with them".  NOOP fulfills
that purpose in a standard non-implementation specific way.

dmadeo

From owner-ietf-calendar  Sun Jan 23 15:07:04 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10323
	for ietf-calendar-bks; Sun, 23 Jan 2000 15:07:04 -0800 (PST)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10319
	for <ietf-calendar@imc.org>; Sun, 23 Jan 2000 15:07:04 -0800 (PST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id PAA15047
	for <ietf-calendar@imc.org>; Sun, 23 Jan 2000 15:06:38 -0800 (PST)
Received: from netscape.com ([198.93.95.223]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FOT9LH00.7O2; Sun, 23 Jan 2000 15:08:05 -0800 
Message-ID: <388B8A01.72A56CBF@netscape.com>
Date: Sun, 23 Jan 2000 15:08:50 -0800
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: David.Madeo@msdw.com
CC: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: NOOP command - your feedback needed
References: <388B784E.22F7DEF7@netscape.com> <388B8630.7192886E@msdw.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>


David Madeo wrote:

> Steve Mansour wrote:
>
> > It is also used as a way to get the IMAP server to spew back pending
> > data. That is, the NOOP command is being used in a way it probably
> > wasn't intended to be.
>
> This sounds wrong.  It's not a "get new messages", it's the equivalent
> of ping.

which has been used get "unsolicited" data.

-Steve


From owner-ietf-calendar  Sun Jan 23 18:37:20 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id SAA16555
	for ietf-calendar-bks; Sun, 23 Jan 2000 18:37:20 -0800 (PST)
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 SAA16549;
	Sun, 23 Jan 2000 18:37:18 -0800 (PST)
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 VAA00528;
	Sun, 23 Jan 2000 21:53:35 -0500 (EST)
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 VAA27124;
	Sun, 23 Jan 2000 21:38:18 -0500 (EST)
To: David.Madeo@msdw.com
Cc: dmadeo@ms.com, ietf-calendar@imc.org, owner-ietf-calendar@imc.org,
        sman@netscape.com
Subject: Re: NOOP command - your feedback needed
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF3ECD374A.29F1F341-ON85256870.000E6254@Lotus.com>
Date: Sun, 23 Jan 2000 21:40:27 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/23/2000 09:39:30 PM,
	Serialize complete at 01/23/2000 09:39:30 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 000EA03C85256870_="
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 000EA03C85256870_=
Content-Type: text/plain; charset="us-ascii"

David:
I am not certain that I buy this argument of "checking the health of a 
server". You won't know the "healthiness" any better with a NOOP than a 
CAPABILITIES command (or any other command). If the server isn't healthy, 
then you will have a CUA timeout of the server (instead of the vice a 
versa). This can be achieved with any type of command, not just a NOOP.
-- Frank

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




<br><font size=3 face="Courier New">David:</font>
<p><font size=3 face="Courier New">I am not certain that I buy this argument of &quot;checking the health of a server&quot;. You won't know the &quot;healthiness&quot; any better with a NOOP than a CAPABILITIES command (or any other command). If the server isn't healthy, then you will have a CUA timeout of the server (instead of the vice a versa). This can be achieved with any type of command, not just a NOOP.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 000EA03C85256870_=--

From owner-ietf-calendar  Sun Jan 23 18:50:25 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id SAA17341
	for ietf-calendar-bks; Sun, 23 Jan 2000 18:50:25 -0800 (PST)
Received: from hqvsbh1.ms.com (hqvsbh1.ms.com [205.228.12.103])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17337;
	Sun, 23 Jan 2000 18:50:23 -0800 (PST)
Received: (from uucp@localhost)
        by hqvsbh1.ms.com (8.9.3/fw v1.30) id VAA19655;
        Sun, 23 Jan 2000 21:51:55 -0500 (EST)
Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1)
	id sma.9486823001.019483; Sun, 23 Jan 00 21:51:40 -0500
Received: by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id VAA19459;
	Sun, 23 Jan 2000 21:51:39 -0500 (EST)
X-Authentication-Warning: hqvsbh1.ms.com: Processed from queue /var/spool/mqueue-vs
X-Authentication-Warning: hqvsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf
X-Interface: IDMZ
Received: from sasmh4.ms.com(144.14.193.5) by hqvsbh1 via smap (4.1)
	id sma.9486822921.019350; Sun, 23 Jan 00 21:51:32 -0500
Received: from msdw.com (vector.morgan.com [144.14.16.149])
        by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id VAA03624;
        Sun, 23 Jan 2000 21:51:32 -0500 (EST)
Message-ID: <388BBE34.D2064002@msdw.com>
Date: Sun, 23 Jan 2000 21:51:32 -0500
From: David Madeo <David.Madeo@msdw.com>
Reply-To: David.Madeo@msdw.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
MIME-Version: 1.0
To: Frank_Dawson@lotus.com
CC: dmadeo@ms.com, ietf-calendar@imc.org, owner-ietf-calendar@imc.org,
        sman@netscape.com
Subject: Re: NOOP command - your feedback needed
References: <OF3ECD374A.29F1F341-ON85256870.000E6254@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-ID: <ietf-calendar.imc.org>
List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>

Frank_Dawson@lotus.com wrote:
> 
> David:
> 
> I am not certain that I buy this argument of "checking the health of a
> server". You won't know the "healthiness" any better with a NOOP than
> a CAPABILITIES command (or any other command). If the server isn't
> healthy, then you will have a CUA timeout of the server (instead of
> the vice a versa). This can be achieved with any type of command, not
> just a NOOP.

Good point.  The concern I had was that the command not actually do
anything.  CAPABILITIES fits that criteria as well.  

Thanks,

dmadeo

From owner-ietf-calendar  Mon Jan 24 11:30:28 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA09769
	for ietf-calendar-bks; Mon, 24 Jan 2000 11:30:28 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09758
	for <ietf-calendar@imc.org>; Mon, 24 Jan 2000 11:30:19 -0800 (PST)
From: Bruce_Kahn@iris.com
To: sman@netscape.com (Steve Mansour)
Cc: ietf-calendar@imc.org
Subject: Re: CAP Transfer Protocol "debug text"
X-Mailer: Lotus Notes Release 5.0.2  November 4, 1999
Message-ID: <OF0F7DC34A.CF0F759E-ON85256870.006A5F3D@iris.com>
Date: Mon, 24 Jan 2000 14:31:55 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 01/24/2000
 02:30:40 PM,
	Serialize complete at 01/24/2000 02:30:40 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006B41E385256870_="
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 006B41E385256870_=
Content-Type: text/plain; charset="us-ascii"

Steve asked:
>Are you saying that the comment would
>(could) be in English AND in some other language?  How would we know
>what the other charset / locale is?  Could you give a quick example of
>what you are suggesting?

Im playing a bit of catch up so pardon any rehashing of responses already 
sent... (hack hack)

I believe that since your response can be of the format:

REQUEST-STATUS:2.0;Everything was just hunky dory

that the optional stattext ("Everything was just hunky dory") could be in 
a language OTHER than English (the "i-default" that Chris refers to). 
However I think that we are already covered by the LANG= property 
parameter that can be used:

REQUEST-STATUS;LANG=en-pirate:2.0;Ahoy matey, all's ship shape
REQUEST-STATUS;LANG=es-cuban:2.0;Todo esta bein conmigo

With i-default, a lack of LANG= falls back to being English (LANG=en).  I 
think that this is a non-issue unless I have misunderstood the snippet of 
Chris's comments...  (I leave it as exercise to the reader to confirm that 
RFC 2445 allows LANG= on REQUEST-STATUS...)

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




<br><font size=2 face="sans-serif">Steve asked:</font>
<br><font size=2 face="Courier New">&gt;Are you saying that the comment would<br>
&gt;(could) be in English AND in some other language? &nbsp;How would we know<br>
&gt;what the other charset / locale is? &nbsp;Could you give a quick example of<br>
&gt;what you are suggesting?</font>
<br>
<br><font size=2 face="sans-serif">Im playing a bit of catch up so pardon any rehashing of responses already sent... (hack hack)</font>
<br>
<br><font size=2 face="sans-serif">I believe that since your response can be of the format:</font>
<br>
<br><font size=2 face="sans-serif">REQUEST-STATUS:2.0;Everything was just hunky dory</font>
<br>
<br><font size=2 face="sans-serif">that the optional stattext (&quot;Everything was just hunky dory&quot;) could be in a language OTHER than English (the &quot;i-default&quot; that Chris refers to). &nbsp;However I think that we are already covered by the LANG= property parameter that can be used:</font>
<br>
<br><font size=2 face="sans-serif">REQUEST-STATUS;LANG=en-pirate:2.0;Ahoy matey, all's ship shape</font>
<br><font size=2 face="sans-serif">REQUEST-STATUS;LANG=es-cuban:2.0;Todo esta bein conmigo</font>
<br>
<br><font size=2 face="sans-serif">With i-default, a lack of LANG= falls back to being English (LANG=en). &nbsp;I think that this is a non-issue unless I have misunderstood the snippet of Chris's comments... &nbsp;(I leave it as exercise to the reader to confirm that RFC 2445 allows LANG= on REQUEST-STATUS...)</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 006B41E385256870_=--

From owner-ietf-calendar  Mon Jan 24 12:07:12 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA10369
	for ietf-calendar-bks; Mon, 24 Jan 2000 12:07:12 -0800 (PST)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10365
	for <ietf-calendar@imc.org>; Mon, 24 Jan 2000 12:07:11 -0800 (PST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id MAA22264
	for <ietf-calendar@imc.org>; Mon, 24 Jan 2000 12:06:48 -0800 (PST)
Received: from netscape.com ([207.1.153.248]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FOUVXT00.4SB; Mon, 24 Jan 2000 12:08:17 -0800 
Message-ID: <388CB163.17B07114@netscape.com>
Date: Mon, 24 Jan 2000 12:09:07 -0800
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce_Kahn@iris.com
CC: ietf-calendar@imc.org
Subject: Re: CAP Transfer Protocol "debug text"
References: <OF0F7DC34A.CF0F759E-ON85256870.006A5F3D@iris.com>
Content-Type: multipart/alternative;
 boundary="------------E5DC99F4FE03FBFB5C89033F"
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>


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

Bruce,

  "REQUEST-STATUS:2.0;Everything was just hunky dory"

is application-level data.  The comment text we're talking about is at
the transfer-level.  That is, we're talking about the "debug text" in
the general reply format in CAP is currently:

     <transfer-level response-code>[; debug text ; more text]
     <CRLF>.<CRLF>
     [<application-data>]
     <CRLF>.<CRLF>

I don't see how the lang value of the application-data applies to the
debug text in the transfer-level.

-Steve

Bruce_Kahn@iris.com wrote:

>
> Steve asked:
> >Are you saying that the comment would
> >(could) be in English AND in some other language?  How would we know
> >what the other charset / locale is?  Could you give a quick example
> of
> >what you are suggesting?
>
> Im playing a bit of catch up so pardon any rehashing of responses
> already sent... (hack hack)
>
> I believe that since your response can be of the format:
>
> REQUEST-STATUS:2.0;Everything was just hunky dory
>
> that the optional stattext ("Everything was just hunky dory") could be
> in a language OTHER than English (the "i-default" that Chris refers
> to).  However I think that we are already covered by the LANG=
> property parameter that can be used:
>
> REQUEST-STATUS;LANG=en-pirate:2.0;Ahoy matey, all's ship shape
> REQUEST-STATUS;LANG=es-cuban:2.0;Todo esta bein conmigo
>
> With i-default, a lack of LANG= falls back to being English
> (LANG=en).  I think that this is a non-issue unless I have
> misunderstood the snippet of Chris's comments...  (I leave it as
> exercise to the reader to confirm that RFC 2445 allows LANG= on
> REQUEST-STATUS...)
>
> 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...

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<font face="sans-serif"><font size=-1>Bruce,</font></font><font face="sans-serif"><font size=-1></font></font>
<p><font face="sans-serif"><font size=-1>&nbsp; "REQUEST-STATUS:2.0;Everything
was just hunky dory"</font></font><font face="sans-serif"><font size=-1></font></font>
<p><font face="sans-serif"><font size=-1>is application-level data.&nbsp;
The comment text we're talking about is at the transfer-level.&nbsp; That
is, we're talking about the "debug text" in the general reply format in
CAP is currently:</font></font>
<blockquote><font face="sans-serif"><font size=-1>&lt;transfer-level response-code>[;
debug text ; more text]</font></font>
<br><font face="sans-serif"><font size=-1>&lt;CRLF>.&lt;CRLF></font></font>
<br><font face="sans-serif"><font size=-1>[&lt;application-data>]</font></font>
<br><font face="sans-serif"><font size=-1>&lt;CRLF>.&lt;CRLF></font></font></blockquote>
<font face="sans-serif"><font size=-1>I don't see how the lang value of
the application-data applies to the debug text in the transfer-level.</font></font><font face="sans-serif"><font size=-1></font></font>
<p><font face="sans-serif"><font size=-1>-Steve</font></font>
<p>Bruce_Kahn@iris.com wrote:
<blockquote TYPE=CITE>&nbsp;
<br><font face="sans-serif"><font size=-1>Steve asked:</font></font>
<br><font face="Courier New"><font size=-1>>Are you saying that the comment
would</font></font>
<br><font face="Courier New"><font size=-1>>(could) be in English AND in
some other language?&nbsp; How would we know</font></font>
<br><font face="Courier New"><font size=-1>>what the other charset / locale
is?&nbsp; Could you give a quick example of</font></font>
<br><font face="Courier New"><font size=-1>>what you are suggesting?</font></font>
<p><font face="sans-serif"><font size=-1>Im playing a bit of catch up so
pardon any rehashing of responses already sent... (hack hack)</font></font>
<p><font face="sans-serif"><font size=-1>I believe that since your response
can be of the format:</font></font>
<p><font face="sans-serif"><font size=-1>REQUEST-STATUS:2.0;Everything
was just hunky dory</font></font>
<p><font face="sans-serif"><font size=-1>that the optional stattext ("Everything
was just hunky dory") could be in a language OTHER than English (the "i-default"
that Chris refers to).&nbsp; However I think that we are already covered
by the LANG= property parameter that can be used:</font></font>
<p><font face="sans-serif"><font size=-1>REQUEST-STATUS;LANG=en-pirate:2.0;Ahoy
matey, all's ship shape</font></font>
<br><font face="sans-serif"><font size=-1>REQUEST-STATUS;LANG=es-cuban:2.0;Todo
esta bein conmigo</font></font>
<p><font face="sans-serif"><font size=-1>With i-default, a lack of LANG=
falls back to being English (LANG=en).&nbsp; I think that this is a non-issue
unless I have misunderstood the snippet of Chris's comments...&nbsp; (I
leave it as exercise to the reader to confirm that RFC 2445 allows LANG=
on REQUEST-STATUS...)</font></font>
<p><font face="sans-serif"><font size=-1>Bruce</font></font>
<br><font face="sans-serif"><font size=-1>===========================================================================</font></font>
<br><font face="sans-serif"><font size=-1>Bruce Kahn&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;
INet: Bruce_Kahn@iris.com</font></font>
<br><font face="sans-serif"><font size=-1>Iris Associates&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;
Phone: 978.392.5335</font></font>
<br><font face="sans-serif"><font size=-1>Westford, MA, USA 01886&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FAX: and nothing but the FAX...</font></font>
<br><font face="sans-serif"><font size=-1>Standard disclaimers apply, even
where prohibited by law...</font></font></blockquote>
</html>

--------------E5DC99F4FE03FBFB5C89033F--


From owner-ietf-calendar  Mon Jan 24 13:01:52 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA11121
	for ietf-calendar-bks; Mon, 24 Jan 2000 13:01:52 -0800 (PST)
Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11116
	for <ietf-calendar@imc.org>; Mon, 24 Jan 2000 13:01:51 -0800 (PST)
Received: from Software.com ([207.175.94.139]) by mta2biz.bizmailsrvcs.net
          with ESMTP
          id <20000124210257.JPIN4647450.mta2biz.bizmailsrvcs.net@Software.com>;
          Mon, 24 Jan 2000 15:02:57 -0600
Message-ID: <388CBD9B.E1967F0B@Software.com>
Date: Mon, 24 Jan 2000 13:01:15 -0800
From: Doug Royer <Doug.Royer@software.com>
Reply-To: CalSched IETF <ietf-calendar@imc.org>
Organization: Software.com
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: CalSched IETF <ietf-calendar@imc.org>
Subject: Re: NOOP command - your feedback needed
References: <388B784E.22F7DEF7@netscape.com> <388B8630.7192886E@msdw.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8B16580A513D58FE29D07A30"
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.

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

David Madeo wrote:

> 
> In corporate type situations where bandwidth isn't an issue and keeping
> the connection open is better than the small delay for tearup/down, I'd
> configure the server to leave the connection up as long as NOOP's keep
> arriving.
> 
> In a different situation where the bandwidth is an issue and the small
> delay of establishing a connection is better than keeping the
> connections open, I'd configure the server to drop the connection after
> the 5th consecutive NOOP.
> 
> In any case, the client should be responsible for reconnecting to the
> server whenever required.  If the "newevents?" timer expires, the client
> should ask the server if anything new has arrived.  If the user starts
> doing something in the client, it should check the connection and
> reestablish with no further action on the part of the user.
> 
> Ideally as a user, I won't even know that it was doing so.
> 
> > It is also used as a way to get the IMAP server to spew back pending
> > data. That is, the NOOP command is being used in a way it probably
> > wasn't intended to be.
> 
> This sounds wrong.  It's not a "get new messages", it's the equivalent
> of ping.

It unfortunately is an overloaded command in IMAP. It mans both.

> > So, the questions are:
> >
> >    * Do we really want a NOOP command in CAP?
> 
> Yes.
> 
> >    * If so, it seems like we might want to allow the server to drop
> >      the connection anyway to avoid idle connections building up.  So,
> >      the server should probably be able to drop a connection at its
> >      discretion.  Do we _really_ want a NOOP command?
> 
> The server should be able to ignore the NOOP and drop the connection
> whenever required.  The client should attempt to reconnect with a
> backoff algorithim to prevent loading.

I agree, the CS should be the final authority. And I agree that
CAP should state the CUA needs to auto-reconnect (to summarize
what David said).

How about we rename NOOP to PING to avoid the undesired IMAP meaning?
--------------ms8B16580A513D58FE29D07A30
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

MIIKKgYJKoZIhvcNAQcCoIIKGzCCChcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw
MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG
SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI
AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh
3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe
BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg
Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ
YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4
NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi
ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4
RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig
JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA
A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK
GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh
/D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u
DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ
bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL
Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC
LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi
c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI
4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO
f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH
BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j
b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI
hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF
pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8
kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggHQMIIBzAIBATCB4TCBzDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx
RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS
ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp
ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut
FTAJBgUrDgMCGgUAoIGGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDEyNDIxMDExNlowIwYJKoZIhvcNAQkEMRYEFD6B+xUmkRxjQ0UXXtJna00RLfdQ
MCcGCSqGSIb3DQEJDzEaMBgwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB
BQAEQLqwxTqZFrAgHofayh8ROwWWp4cHI3KWshR5jMcJxTwCaDF3OzGA3obSAVHcPK1qoyxV
yjv0LXes/nqqVB5jkPM=
--------------ms8B16580A513D58FE29D07A30--


From owner-ietf-calendar  Tue Jan 25 15:21:43 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id PAA01623
	for ietf-calendar-bks; Tue, 25 Jan 2000 15:21:43 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA01619
	for <ietf-calendar@imc.org>; Tue, 25 Jan 2000 15:21:42 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA00759; Tue, 25 Jan 00 18:22:54 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id SAA00209
	for <ietf-calendar@imc.org>; Tue, 25 Jan 2000 18:23:22 -0500 (EST)
Received: from [18.177.0.98] (WINGNUT.MIT.EDU [18.177.0.98])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id SAA04701
	for <ietf-calendar@imc.org>; Tue, 25 Jan 2000 18:23:22 -0500 (EST)
Mime-Version: 1.0
X-Sender: bobmah@po12.mit.edu
Message-Id: <v04220805b4b3df056fac@[18.177.0.98]>
Date: Tue, 25 Jan 2000 18:22:52 -0500
To: ietf-calendar@imc.org
From: Bob Mahoney <bobmah@mit.edu>
Subject: W-19 CAP Group Definitions
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>

 From Day One of the Interim meeting:

We've made an attempt on Group Definitions and Operations.  Our 
suggested text follows, referenced by CAP sections (not by section 
number).   We're also working on other security-related portions of 
the draft, and are likely to borrow some text from section 6 of 
draft-ietf-ldaptext-authmeth-04.txt.   More to follow tomorrow.

Please post comments to the list:

-Bob, for the members in attendance

--------------------------------
(CAP section "Definitions")

Calendar Group (CG)

A collection of Calendar Users and/or other Calendar Groups.  These 
groups are expanded by the CS and may reside either locally or in an 
external database or directory.  The group membership may be fixed or 
dynamic over time.


(Global modification for UPN definition)

Change " CU" to "CU or CG"; Change "user@example.com" to 
"user@example.com or group@example.com"


(CAP section "Calendar Group")

A Calendar Group is used to represent a collection of calendar users 
or other Calendar Groups that can be specified as ATTENDEEs or 
referenced in VCARS.  A CG is represented in CAP as a UPN.  The CUA 
cannot distinguish between user and group UPNs.

Calendar Groups are expanded as necessary by the CS.  Subject to 
administrator configuration (as with the EXPN command in SMTP), the 
CS MUST respond to a CUA request for group expansion.  When relevant 
to completing an operation, the CS may expand a CG (including nested 
CGs) to obtain a list of unique CUs.  Duplicate UPNs are filtered 
during expansion.  Incomplete expansion should be treated as a 
failure.

The CS SHOULD not preserve CG expansions across operations.  A CG may 
reference a static list of members, or it may represent a dynamic 
list.  Each operation SHOULD generate its own expansion in order to 
recognize changes to group membership.  However, during fan out to 
other CSs, the originating CS SHOULD expand all CGs so that the 
target CS receives only a list of unique CUs.  This is to prevent 
confusion when two CSs do not share the same CG database or directory.


CAP does not define commands or methods for managing Calendar Groups.

Examples:

      Small CG - The Three Stooges.  There is only and always three at 
any one time.
      Large CG - The MIT graduating class of 1999.  This is a static list.
      Dynamic CG - The IETF membership, which is a large and changing 
list of CUs.
      Nested CG - The National Football League, made up of the AFC and 
NFC, which are made up of 3 divisions each...

(CAP table "CAP Calendaring Commands")

Add:

Command		Description

EXPAND		Return the members of the argument UPN.  Successful 
result yields only CU UPNs.


(CAP section "VCalendar Access Rights")

Change: "Calendar User" to "Calendar User or Calendar Group"

(CAP section "Access Rights")

Change: "Calendar User" to "Calendar User or Calendar Group"

Add:

VCARS principals can be Calendar User or Calendar Group UPNs. 
Whenever VCARs are evaluated, all referenced Calendar Groups MUST be 
evaluated as an expanded list.  Calendar Group expansion SHOULD NOT 
persist across operations.

(CAP section "State Diagram")

Add:

While in the Identified state, allow EXPAND command.

(CAP section "Capability Command")

Add:

MAXEXPANDLIST to list of capabilities returned

MAXEXPANDLIST   0 or 1

An integer value that specifies the maximum number of UPNs that can 
be returned by the EXPAND Method.

(CAP section "Transfer Protocol Commands")

Add:

EXPAND Command

Arguments:   UPN

Data:        data as described below

Result:      2.0 Successful, and requested data follows
              2.1 Permission Denied
              2.2 Requested UPN not found
              2.3 Result exceeds MAXEXPANDLIST
              2.4 Misc. EXPAND error

Example #1: Request expansion of UPN which is a Calendar Group

C: EXPAND group@example.com
S: 2.0 group@example.com
S: IDENTITY=a@example.com
S: IDENTITY=b@example.com
S: IDENTITY=c@example.com
S: .

Example #2: Request expansion of a UPN which is a Calendar User

C: EXPAND upn@example.com
S: 2.0 upn@example.com
S: IDENTITY=upn@example.com
S: .

Example #3: CS loses contact with directory server during EXPAND

C: EXPAND group@example.com
S: 2.0 group@example.com
S: IDENTITY=a@example.com
S: IDENTITY=b@example.com
S: 2.4 Lost contact with directory server
S: .


(CAP section "RIGHTS Value Type")

Change:

"The UPN rule part specifies the authenticated calendar user that the 
calendar access rights applies to."

to

"The UPN rule part specifies the Calendar User or Calendar Group that 
the calendar access rights applies to.


From owner-ietf-calendar  Tue Jan 25 19:47:12 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id TAA20488
	for ietf-calendar-bks; Tue, 25 Jan 2000 19:47:12 -0800 (PST)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA20477
	for <ietf-calendar@imc.org>; Tue, 25 Jan 2000 19:47:07 -0800 (PST)
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.8.5/8.8.5) with ESMTP id TAA13935
	for <ietf-calendar@imc.org>; Tue, 25 Jan 2000 19:46:46 -0800 (PST)
Received: from netscape.com ([198.93.95.223]) by dredd.mcom.com
          (Netscape Messaging Server 4.1 Aug  9 1999 18:28:31) with ESMTP
          id FOXBWF00.FHN; Tue, 25 Jan 2000 19:48:15 -0800 
Message-ID: <388E6EAB.4D4F35BC@netscape.com>
Date: Tue, 25 Jan 2000 19:49:00 -0800
From: sman@netscape.com (Steve Mansour)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Mahoney <bobmah@mit.edu>
CC: ietf-calendar@imc.org
Subject: Re: W-19 CAP Group Definitions
References: <v04220805b4b3df056fac@[18.177.0.98]>
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>

Bob,

Good job getting this text together! This is _very_ helpful in getting the
draft completed. I'll watch for comments. If there are no issues raised I'll
use it to update the draft.

-Steve

Bob Mahoney wrote:

>  From Day One of the Interim meeting:
>
> We've made an attempt on Group Definitions and Operations.  Our
> suggested text follows, referenced by CAP sections (not by section
> number).   We're also working on other security-related portions of
> the draft, and are likely to borrow some text from section 6 of
> draft-ietf-ldaptext-authmeth-04.txt.   More to follow tomorrow.
>
> Please post comments to the list:
>
> -Bob, for the members in attendance
>
> --------------------------------
> (CAP section "Definitions")
>
> Calendar Group (CG)
>
> A collection of Calendar Users and/or other Calendar Groups.  These
> groups are expanded by the CS and may reside either locally or in an
> external database or directory.  The group membership may be fixed or
> dynamic over time.
>
> (Global modification for UPN definition)
>
> Change " CU" to "CU or CG"; Change "user@example.com" to
> "user@example.com or group@example.com"
>
> (CAP section "Calendar Group")
>
> A Calendar Group is used to represent a collection of calendar users
> or other Calendar Groups that can be specified as ATTENDEEs or
> referenced in VCARS.  A CG is represented in CAP as a UPN.  The CUA
> cannot distinguish between user and group UPNs.
>
> Calendar Groups are expanded as necessary by the CS.  Subject to
> administrator configuration (as with the EXPN command in SMTP), the
> CS MUST respond to a CUA request for group expansion.  When relevant
> to completing an operation, the CS may expand a CG (including nested
> CGs) to obtain a list of unique CUs.  Duplicate UPNs are filtered
> during expansion.  Incomplete expansion should be treated as a
> failure.
>
> The CS SHOULD not preserve CG expansions across operations.  A CG may
> reference a static list of members, or it may represent a dynamic
> list.  Each operation SHOULD generate its own expansion in order to
> recognize changes to group membership.  However, during fan out to
> other CSs, the originating CS SHOULD expand all CGs so that the
> target CS receives only a list of unique CUs.  This is to prevent
> confusion when two CSs do not share the same CG database or directory.
>
> CAP does not define commands or methods for managing Calendar Groups.
>
> Examples:
>
>       Small CG - The Three Stooges.  There is only and always three at
> any one time.
>       Large CG - The MIT graduating class of 1999.  This is a static list.
>       Dynamic CG - The IETF membership, which is a large and changing
> list of CUs.
>       Nested CG - The National Football League, made up of the AFC and
> NFC, which are made up of 3 divisions each...
>
> (CAP table "CAP Calendaring Commands")
>
> Add:
>
> Command         Description
>
> EXPAND          Return the members of the argument UPN.  Successful
> result yields only CU UPNs.
>
> (CAP section "VCalendar Access Rights")
>
> Change: "Calendar User" to "Calendar User or Calendar Group"
>
> (CAP section "Access Rights")
>
> Change: "Calendar User" to "Calendar User or Calendar Group"
>
> Add:
>
> VCARS principals can be Calendar User or Calendar Group UPNs.
> Whenever VCARs are evaluated, all referenced Calendar Groups MUST be
> evaluated as an expanded list.  Calendar Group expansion SHOULD NOT
> persist across operations.
>
> (CAP section "State Diagram")
>
> Add:
>
> While in the Identified state, allow EXPAND command.
>
> (CAP section "Capability Command")
>
> Add:
>
> MAXEXPANDLIST to list of capabilities returned
>
> MAXEXPANDLIST   0 or 1
>
> An integer value that specifies the maximum number of UPNs that can
> be returned by the EXPAND Method.
>
> (CAP section "Transfer Protocol Commands")
>
> Add:
>
> EXPAND Command
>
> Arguments:   UPN
>
> Data:        data as described below
>
> Result:      2.0 Successful, and requested data follows
>               2.1 Permission Denied
>               2.2 Requested UPN not found
>               2.3 Result exceeds MAXEXPANDLIST
>               2.4 Misc. EXPAND error
>
> Example #1: Request expansion of UPN which is a Calendar Group
>
> C: EXPAND group@example.com
> S: 2.0 group@example.com
> S: IDENTITY=a@example.com
> S: IDENTITY=b@example.com
> S: IDENTITY=c@example.com
> S: .
>
> Example #2: Request expansion of a UPN which is a Calendar User
>
> C: EXPAND upn@example.com
> S: 2.0 upn@example.com
> S: IDENTITY=upn@example.com
> S: .
>
> Example #3: CS loses contact with directory server during EXPAND
>
> C: EXPAND group@example.com
> S: 2.0 group@example.com
> S: IDENTITY=a@example.com
> S: IDENTITY=b@example.com
> S: 2.4 Lost contact with directory server
> S: .
>
> (CAP section "RIGHTS Value Type")
>
> Change:
>
> "The UPN rule part specifies the authenticated calendar user that the
> calendar access rights applies to."
>
> to
>
> "The UPN rule part specifies the Calendar User or Calendar Group that
> the calendar access rights applies to.


From owner-ietf-calendar  Tue Jan 25 21:18:39 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id VAA25348
	for ietf-calendar-bks; Tue, 25 Jan 2000 21:18:39 -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 VAA25344
	for <ietf-calendar@imc.org>; Tue, 25 Jan 2000 21:18:37 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id VAA16623
	for <ietf-calendar@imc.org>; Tue, 25 Jan 2000 21:20:06 -0800 (PST)
Message-ID: <388E83FE.2E8923A6@home.royer.com>
Date: Tue, 25 Jan 2000 21:19:58 -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: W-19 CAP Group Definitions
References: <v04220805b4b3df056fac@[18.177.0.98]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4F97B25992596A6653B13EC7"
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.

--------------ms4F97B25992596A6653B13EC7
Content-Type: multipart/mixed;
 boundary="------------531C8E7FD4061A1B998A423C"

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

Bob Mahoney wrote:
> 
>  From Day One of the Interim meeting:
> 
> We've made an attempt on Group Definitions and Operations.  Our
> suggested text follows, referenced by CAP sections (not by section
> number).   We're also working on other security-related portions of
> the draft, and are likely to borrow some text from section 6 of
> draft-ietf-ldaptext-authmeth-04.txt.   More to follow tomorrow.
> 
> Please post comments to the list:
> 
> -Bob, for the members in attendance
> 
> --------------------------------
> (CAP section "Definitions")
> 
> Calendar Group (CG)
> 
> A collection of Calendar Users and/or other Calendar Groups.  These
> groups are expanded by the CS and may reside either locally or in an
> external database or directory.  The group membership may be fixed or
> dynamic over time.
> 
> (Global modification for UPN definition)
> 
> Change " CU" to "CU or CG"; Change "user@example.com" to
> "user@example.com or group@example.com"
> 
> (CAP section "Calendar Group")
> 
> A Calendar Group is used to represent a collection of calendar users
> or other Calendar Groups that can be specified as ATTENDEEs or
> referenced in VCARS.  A CG is represented in CAP as a UPN.  The CUA
> cannot distinguish between user and group UPNs.
> 
> Calendar Groups are expanded as necessary by the CS.  Subject to
> administrator configuration (as with the EXPN command in SMTP), the
> CS MUST respond to a CUA request for group expansion.  When relevant
> to completing an operation, the CS may expand a CG (including nested
> CGs) to obtain a list of unique CUs.  Duplicate UPNs are filtered
> during expansion.  Incomplete expansion should be treated as a
> failure.

Given if CG-1 contains list-A and list-B. Then what if you  have
permission to see list-A but not list-B. How should that be
treated?

> The CS SHOULD not preserve CG expansions across operations.  A CG may
> reference a static list of members, or it may represent a dynamic
> list.  Each operation SHOULD generate its own expansion in order to
> recognize changes to group membership.  However, during fan out to
> other CSs, the originating CS SHOULD expand all CGs so that the
> target CS receives only a list of unique CUs.  This is to prevent
> confusion when two CSs do not share the same CG database or directory.

If during fanout CS-1 and CS-2 do NOT contain the same CG database
or directory, then do you mean that CS-1 SHOULD request CS-2 to
do the expansion, then CS-1 MUST apply unique filters? What if
CS-2 says 'no I will not expand this list', yet CS-1 can
expand its list? Does it return the CS-1 list, plus the group-name/UPN
from CS-2?


> CAP does not define commands or methods for managing Calendar Groups.
> 
> Examples:
> 
>       Small CG - The Three Stooges.  There is only and always three at
> any one time.
>       Large CG - The MIT graduating class of 1999.  This is a static list.
>       Dynamic CG - The IETF membership, which is a large and changing
> list of CUs.
>       Nested CG - The National Football League, made up of the AFC and
> NFC, which are made up of 3 divisions each...
> 
> (CAP table "CAP Calendaring Commands")
> 
> Add:
> 
> Command         Description
> 
> EXPAND          Return the members of the argument UPN.  Successful
> result yields only CU UPNs.

How does a CS say that it will not expand the list?

> (CAP section "VCalendar Access Rights")
> 
> Change: "Calendar User" to "Calendar User or Calendar Group"
> 
> (CAP section "Access Rights")
> 
> Change: "Calendar User" to "Calendar User or Calendar Group"
> 
> Add:
> 
> VCARS principals can be Calendar User or Calendar Group UPNs.
> Whenever VCARs are evaluated, all referenced Calendar Groups MUST be
> evaluated as an expanded list.  Calendar Group expansion SHOULD NOT
> persist across operations.
> 
> (CAP section "State Diagram")
> 
> Add:
> 
> While in the Identified state, allow EXPAND command.
> 
> (CAP section "Capability Command")
> 
> Add:
> 
> MAXEXPANDLIST to list of capabilities returned
> 
> MAXEXPANDLIST   0 or 1
> 
> An integer value that specifies the maximum number of UPNs that can
> be returned by the EXPAND Method.

How do you say unlimited? How about:

	0   = I will not expand any lists, everything request will yield 2.1 
	-1  = Unlimited.

> (CAP section "Transfer Protocol Commands")
> 
> Add:
> 
> EXPAND Command
> 
> Arguments:   UPN
> 
> Data:        data as described below
> 
> Result:      2.0 Successful, and requested data follows
>               2.1 Permission Denied
>               2.2 Requested UPN not found
>               2.3 Result exceeds MAXEXPANDLIST
>               2.4 Misc. EXPAND error
> 
> Example #1: Request expansion of UPN which is a Calendar Group
> 
> C: EXPAND group@example.com
> S: 2.0 group@example.com
> S: IDENTITY=a@example.com
> S: IDENTITY=b@example.com
> S: IDENTITY=c@example.com
> S: .
> 
> Example #2: Request expansion of a UPN which is a Calendar User
> 
> C: EXPAND upn@example.com
> S: 2.0 upn@example.com
> S: IDENTITY=upn@example.com
> S: .
> 
> Example #3: CS loses contact with directory server during EXPAND
> 
> C: EXPAND group@example.com
> S: 2.0 group@example.com
> S: IDENTITY=a@example.com
> S: IDENTITY=b@example.com
> S: 2.4 Lost contact with directory server
> S: .

And how about:

 C: EXPAND group2@example.com
 S: 2.1
 S: .

> (CAP section "RIGHTS Value Type")
> 
> Change:
> 
> "The UPN rule part specifies the authenticated calendar user that the
> calendar access rights applies to."
> 
> to
> 
> "The UPN rule part specifies the Calendar User or Calendar Group that
> the calendar access rights applies to.
--------------531C8E7FD4061A1B998A423C
Content-Type: text/x-vcard; charset=us-ascii;
 name="doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="doug.vcf"

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

--------------531C8E7FD4061A1B998A423C--

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

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
ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI2MDUyMDAwWjAjBgkqhkiG9w0BCQQxFgQUg+87Yqe2
zYXYpLxXMz5SfjBwMCwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYBdpkYqQQCif+bkSKeqdCpJG8UsDLwvLMh5ocJqusSucDvBPact9wJSJvqev/cH
aQJBLI6ZiYjVKWDCmmFqU6k0vXrWhMy1lQ5uFfb+7n/dK7QFPe1v3WtEhlNyVxb+v5U1wD1F
yH5TFwqb/aDnZjHeNNf+uIAtUWO8rLLJi/yL8Q==
--------------ms4F97B25992596A6653B13EC7--


From owner-ietf-calendar  Wed Jan 26 07:40:19 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA26430
	for ietf-calendar-bks; Wed, 26 Jan 2000 07:40:19 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26426
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 07:40:10 -0800 (PST)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: Bob Mahoney <bobmah@mit.edu>
Cc: ietf-calendar@imc.org
Subject: Re: W-19 CAP Group Definitions
X-Mailer: Lotus Notes Release 5.0.2  November 4, 1999
Message-ID: <OF9984742A.7F1CC245-ON85256872.0055A115@iris.com>
Date: Wed, 26 Jan 2000 10:39:44 -0500
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/26/2000 10:40:11 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/26/2000 10:40:11 AM,
	Serialize complete at 01/26/2000 10:40:11 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/26/2000 10:40:11 AM,
	S/MIME Sign complete at 01/26/2000 10:40:11 AM,
	Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 01/26/2000
 10:41:46 AM,
	Serialize complete at 01/26/2000 10:41:46 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z01886_boundary_sign
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 an S/MIME signed message.

---------z01886_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0056138D85256872_="

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

Bob proposed:
>EXPAND Command
>
>Arguments:   UPN
>
>Data:        data as described below
>
>Result:      2.0 Successful, and requested data follows
>              2.1 Permission Denied
>              2.2 Requested UPN not found
>              2.3 Result exceeds MAXEXPANDLIST
>              2.4 Misc. EXPAND error
>

Very helpful.  Id like to add one more example:

Example #4: Request expansion exceeds MAXEXPANDLIST

C: EXPAND group@example.com
S: 2.0 group@example.com
S: IDENTITY=a@example.com
S: IDENTITY=b@example.com
S: IDENTITY=c@example.com
S: 2.3 Expansion resulted in too much data
S: .

That is to say, I propose that if the limit is exceeded then the CS should 
send what it has and notify the CUA of partial results.

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




<br><font size=2 face="sans-serif">Bob proposed:</font>
<br><font size=2 face="Courier New">&gt;EXPAND Command<br>
&gt;<br>
&gt;Arguments: &nbsp; UPN<br>
&gt;<br>
&gt;Data: &nbsp; &nbsp; &nbsp; &nbsp;data as described below<br>
&gt;<br>
&gt;Result: &nbsp; &nbsp; &nbsp;2.0 Successful, and requested data follows<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;2.1 Permission Denied<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;2.2 Requested UPN not found<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;2.3 Result exceeds MAXEXPANDLIST<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;2.4 Misc. EXPAND error<br>
&gt;<br>
</font>
<br><font size=2 face="sans-serif">Very helpful. &nbsp;Id like to add one more example:</font>
<br>
<br><font size=2 face="Courier New">Example #4: Request expansion exceeds MAXEXPANDLIST</font>
<br><font size=2 face="Courier New"><br>
C: EXPAND group@example.com<br>
S: 2.0 group@example.com<br>
S: IDENTITY=a@example.com<br>
S: IDENTITY=b@example.com<br>
S: IDENTITY=c@example.com<br>
S: 2.3 Expansion resulted in too much data<br>
S: .<br>
</font>
<br><font size=2 face="sans-serif">That is to say, I propose that if the limit is exceeded then the CS should send what it has and notify the CUA of partial results.</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 0056138D85256872_=--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIAwggHZMIIBg6ADAgECAiBgUF6eflpWh6h9PfgYD7sAlMCM8enGl8RXOcIo9uhg
ezANBgkqhkiG9w0BAQQFADBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzEN
MAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTAeFw05OTEx
MTcxOTEzMjdaFw0wMTExMTYxOTEyNTNaMEgxDTALBgNVBAoTBElyaXMxEzARBgNV
BAMTCkJydWNlIEthaG4xIjAgBgkqhkiG9w0BCQEWE0JydWNlX0thaG5AaXJpcy5j
b20wWzANBgkqhkiG9w0BAQEFAANKADBHAkEA495S/vcTouExtWuNrF33Q28Lcjjk
4lj2W6ERZ3MhEBR5vHL3wTaXoRWVhPeoDaUcCc54oig8YQlC/hwSp3YF4QICQlGj
PDA6MBEGA1UdDgQKBAhG2i3x0db2dzAPBgNVHQ8BAf8EBQMDB7AAMBQGC2CGSAGG
+A4CAgMCBAUDAweAADANBgkqhkiG9w0BAQQFAANBAJnY7BPUuh9G4grcCnmNPlMH
JsE0/KULlvaqMab5uWQd0nFkZg64TIWwlYMLrwKqzenyrEkVF4QO6yjiShaej/Aw
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVT
MQ0wCwYDVQQIEwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIElu
dGVybmV0IENBMB4XDTk4MTEwMjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkG
A1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMT
EElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAw+BjK0cg
xCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5yBLD
j5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwz
cO3Ltq2HlXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/wi
ngAAMYAwggF5AgEBMGowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0ECIGBQXp5+WlaH
qH09+BgPuwCUwIzx6caXxFc5wij26GB7MAkGBSsOAwIaBQCggaswGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI2MTU0MDExWjAj
BgkqhkiG9w0BCQQxFgQUFG4Az9HS1cMoM7eFXMwojMcO1bIwTAYJKoZIhvcNAQkP
MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D
AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQAY6hUUE/gTC9g8KxUkQ
nfSSvokTyMxa+UAr5RqiqXaZteTSe23cmUyCMFAuqad2wdbRq/8EZ2VfpMIYpX/b
JqsAAAAAAAAAAA==

---------z01886_boundary_sign--

From owner-ietf-calendar  Wed Jan 26 08:43:40 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27469
	for ietf-calendar-bks; Wed, 26 Jan 2000 08:43:40 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27465
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 08:43:38 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA24133; Wed, 26 Jan 00 11:44:53 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id LAA19361
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 11:39:26 -0500 (EST)
Received: from [18.177.0.98] (WINGNUT.MIT.EDU [18.177.0.98])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id LAA00226
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 11:39:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: bobmah@po12.mit.edu
Message-Id: <v04220807b4b4c5f03843@[18.177.0.98]>
In-Reply-To: <v04220805b4b3df056fac@[18.177.0.98]>
References: <v04220805b4b3df056fac@[18.177.0.98]>
Date: Wed, 26 Jan 2000 11:39:02 -0500
To: ietf-calendar@imc.org
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: W-19 CAP Group Definitions
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>

We need to change our definition of groups.

We now realize there are two types of groups, Users and Calendars.

Definitions:

Users are represented as UPNs.  A given UPN can be either a Calendar 
User (CU) or a User Group (UG).  We do not want to continue using the 
term Calendar Group (CG).   By looking at a UPN, a CUA cannot 
determine whether it is a CU or a UG.   Only the CS can expand a UG 
into a list of CUs.

Calendars are represented as CSIDs.  A given CSID can be either a 
Calendar (C), a Calendar Collection (CC), or a Resource Calendar 
(RC).  By looking at a CSID, a CUA cannot determine whether it is a 
C, CC, or RC.  Only the CS can expand a CC into a list of Cs or RCs.

(There is no syntactic difference between a C and RC. They are only 
different in the semantic content that is imposed by the data that 
they contain and by their calendar properties.)


Commands:

We want to keep the EXPAND command from yesterday.  EXPAND will 
accept a CSID and return one or more Cs or RCs.  More than one C or 
RC returned implies that the CSID was a CC.

We want to add a new command called LOOKUP, which will accept a UPN, 
and returns one or more CSIDs.  More than one CSID returned implies 
that the UPN was a UG.

The reverse lookup from a CSID to a UPN is accomplished by looking at 
the owner property of the calendar.

Read this aloud- it will help.  We'll follow up later with revisions 
to yesterday's text.

-Bob

From owner-ietf-calendar  Wed Jan 26 09:42:42 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00154
	for ietf-calendar-bks; Wed, 26 Jan 2000 09:42:42 -0800 (PST)
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 JAA00150;
	Wed, 26 Jan 2000 09:42:41 -0800 (PST)
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 MAA06877;
	Wed, 26 Jan 2000 12:59:13 -0500 (EST)
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 MAA09968;
	Wed, 26 Jan 2000 12:43:49 -0500 (EST)
To: Bob Mahoney <bobmah@mit.edu>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@imc.org
Subject: Re: W-19 CAP Group Definitions
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF52012F0E.A3ED873C-ON85256872.006138EB@Lotus.com>
Date: Wed, 26 Jan 2000 12:45:20 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/26/2000 12:44:46 PM,
	Serialize complete at 01/26/2000 12:44:46 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 006193F385256872_="
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 006193F385256872_=
Content-Type: text/plain; charset="us-ascii"

Bob:
Do you all realize we already differentiate in RFC2445 different CUTYPEs? 
This discussion about Group Definitions seems to be unnecessarily 
conflicting with existing definitions of CU Types already codified in 
iCalendar.
Calendar user type is identified in the ATTENDEE property parameter 
CUTYPE. The current enumerated values are INDIVIDUAL, GROUP, RESOURCE or 
UNKNOWN.
-- Frank

--=_alternative 006193F385256872_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Bob:</font>
<p><font size=3 face="Courier New">Do you all realize we already differentiate in RFC2445 different CUTYPEs? </font>
<p><font size=3 face="Courier New">This discussion about Group Definitions seems to be unnecessarily conflicting with existing definitions of CU Types already codified in iCalendar.</font>
<p><font size=3 face="Courier New">Calendar user type is identified in the ATTENDEE property parameter CUTYPE. The current enumerated values are INDIVIDUAL, GROUP, RESOURCE or UNKNOWN.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 006193F385256872_=--

From owner-ietf-calendar  Wed Jan 26 09:49:06 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01470
	for ietf-calendar-bks; Wed, 26 Jan 2000 09:49:06 -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 JAA01451
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 09:49:04 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id JAA17566;
	Wed, 26 Jan 2000 09:50:27 -0800 (PST)
Message-ID: <388F33E2.99FF0F43@home.royer.com>
Date: Wed, 26 Jan 2000 09:50:26 -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: Bob Mahoney <bobmah@mit.edu>
CC: ietf-calendar@imc.org
Subject: Re: W-19 CAP Group Definitions
References: <v04220805b4b3df056fac@[18.177.0.98]> <v04220807b4b4c5f03843@[18.177.0.98]>
Content-Type: multipart/mixed;
 boundary="------------35B72F04EF5009DB7BD5B8CB"
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.
--------------35B72F04EF5009DB7BD5B8CB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Mahoney wrote:
> 
> We need to change our definition of groups.
> 
> We now realize there are two types of groups, Users and Calendars.
> 
> Definitions:
> 
> Users are represented as UPNs.  A given UPN can be either a Calendar
> User (CU) or a User Group (UG).  We do not want to continue using the
> term Calendar Group (CG).   By looking at a UPN, a CUA cannot
> determine whether it is a CU or a UG.   Only the CS can expand a UG
> into a list of CUs.
> 
> Calendars are represented as CSIDs.  A given CSID can be either a
> Calendar (C), a Calendar Collection (CC), or a Resource Calendar
> (RC).  By looking at a CSID, a CUA cannot determine whether it is a
> C, CC, or RC.  Only the CS can expand a CC into a list of Cs or RCs.
> 
> (There is no syntactic difference between a C and RC. They are only
> different in the semantic content that is imposed by the data that
> they contain and by their calendar properties.)

Where is the definition of "Resource Calendar (RC)". I could
make a guess :-) And which properties or property values? From
you text above I do not know what an RC is.

> Commands:
> 
> We want to keep the EXPAND command from yesterday.  EXPAND will
> accept a CSID and return one or more Cs or RCs.  More than one C or
> RC returned implies that the CSID was a CC.
> 
> We want to add a new command called LOOKUP, which will accept a UPN,
> and returns one or more CSIDs.  More than one CSID returned implies
> that the UPN was a UG.
> 
> The reverse lookup from a CSID to a UPN is accomplished by looking at
> the owner property of the calendar.

We allow more than one owner for a calendar. What would that tell you?

And why is it different than just asking for the calendar owner
properties? It looks to me as if it is the same as just doing a VQUERY
for the calendar owner property values? If so, lets not  invent
another way to do the same thing.


> Read this aloud- it will help.  We'll follow up later with revisions
> to yesterday's text.
> 
> -Bob
--------------35B72F04EF5009DB7BD5B8CB
Content-Type: text/x-vcard; charset=us-ascii;
 name="doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="doug.vcf"

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

--------------35B72F04EF5009DB7BD5B8CB--


From owner-ietf-calendar  Wed Jan 26 10:21:01 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA07899
	for ietf-calendar-bks; Wed, 26 Jan 2000 10:21:01 -0800 (PST)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA07895
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 10:20:59 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA09551; Wed, 26 Jan 00 13:23:52 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id NAA19461;
	Wed, 26 Jan 2000 13:22:45 -0500 (EST)
Received: from [18.177.0.98] (WINGNUT.MIT.EDU [18.177.0.98])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id NAA04132;
	Wed, 26 Jan 2000 13:22:44 -0500 (EST)
Mime-Version: 1.0
X-Sender: bobmah@po12.mit.edu
Message-Id: <v04220809b4b4eb360423@[18.177.0.98]>
In-Reply-To: <388F33E2.99FF0F43@home.royer.com>
References: <v04220805b4b3df056fac@[18.177.0.98]>
 <v04220807b4b4c5f03843@[18.177.0.98]> <388F33E2.99FF0F43@home.royer.com>
Date: Wed, 26 Jan 2000 13:22:02 -0500
To: ietf-calendar@imc.org
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: W-19 CAP Group Definitions
Cc: Bob Mahoney <bobmah@mit.edu>, ietf-calendar@imc.org
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>


>Where is the definition of "Resource Calendar (RC)". I could
>make a guess :-) And which properties or property values? From
>you text above I do not know what an RC is.

We're adding that.  :-)

>  > The reverse lookup from a CSID to a UPN is accomplished by looking at
>  > the owner property of the calendar.
>
>We allow more than one owner for a calendar. What would that tell you?

That's ok- it doesn't need to be a one-to-one mapping.

>And why is it different than just asking for the calendar owner
>properties? It looks to me as if it is the same as just doing a VQUERY
>for the calendar owner property values? If so, lets not  invent
>another way to do the same thing.

Exactly.  We were just including that for the sake of completeness.

-Bob


From owner-ietf-calendar  Wed Jan 26 11:31:19 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA09754
	for ietf-calendar-bks; Wed, 26 Jan 2000 11:31:19 -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 LAA09750
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 11:31:18 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA18032;
	Wed, 26 Jan 2000 11:33:01 -0800 (PST)
Message-ID: <388F4BE0.30FBEA0B@home.royer.com>
Date: Wed, 26 Jan 2000 11:32:48 -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: Bob Mahoney <bobmah@mit.edu>
CC: ietf-calendar@imc.org
Subject: Re: W-19 CAP Group Definitions
References: <v04220805b4b3df056fac@[18.177.0.98]>
	 <v04220807b4b4c5f03843@[18.177.0.98]> <388F33E2.99FF0F43@home.royer.com> <v04220809b4b4eb360423@[18.177.0.98]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms47F9AEE196BDB21C66903652"
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.

--------------ms47F9AEE196BDB21C66903652
Content-Type: multipart/mixed;
 boundary="------------7E73F20F3460FDDD7CBF213F"

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

Bob Mahoney wrote:
 
> >And why is it different than just asking for the calendar owner
> >properties? It looks to me as if it is the same as just doing a VQUERY
> >for the calendar owner property values? If so, lets not  invent
> >another way to do the same thing.
> 
> Exactly.  We were just including that for the sake of completeness.

Exactly what? :-)

Exactly you agree it is not needed as it is the same?

Or exactly (because it is not the same) we need it?

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

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

--------------7E73F20F3460FDDD7CBF213F--

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

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
ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI2MTkzMjUzWjAjBgkqhkiG9w0BCQQxFgQU1a9FDyj9
JtkwIYpsq7qaH/9RD0swUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYBsd2O7Uoyky4IMagYSzIOWYi7TsWR7Sb7xs/61JQnhgkQWR5a5TxfqUvqExBci
E7KBOl8lumlIShCDOKYXaqX7Gc8QU6Q8UREdtw4jn9JEFyU9eXX7z52QznWe06sEo+BADb6+
CmNXtU9M1UPjuhqTgtKCcGDUKrQxijz4pHchIg==
--------------ms47F9AEE196BDB21C66903652--


From owner-ietf-calendar  Wed Jan 26 11:39:19 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA10026
	for ietf-calendar-bks; Wed, 26 Jan 2000 11:39:19 -0800 (PST)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10022
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 11:39:18 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA07337; Wed, 26 Jan 00 14:42:11 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id OAA11618;
	Wed, 26 Jan 2000 14:41:03 -0500 (EST)
Received: from [18.177.0.98] (WINGNUT.MIT.EDU [18.177.0.98])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id OAA28963;
	Wed, 26 Jan 2000 14:41:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: bobmah@po12.mit.edu
Message-Id: <v0422080db4b4fcb71adc@[18.177.0.98]>
In-Reply-To: <388F4BE0.30FBEA0B@home.royer.com>
References: <v04220805b4b3df056fac@[18.177.0.98]>	
 <v04220807b4b4c5f03843@[18.177.0.98]> <388F33E2.99FF0F43@home.royer.com>
 <v04220809b4b4eb360423@[18.177.0.98]> <388F4BE0.30FBEA0B@home.royer.com>
Date: Wed, 26 Jan 2000 14:40:50 -0500
To: ietf-calendar@imc.org
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: W-19 CAP Group Definitions
Cc: Bob Mahoney <bobmah@mit.edu>, ietf-calendar@imc.org
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>


>Exactly what? :-)
>
>Exactly you agree it is not needed as it is the same?
>
>Or exactly (because it is not the same) we need it?

Sorry!

"We included this for completeness only in our email (not the CAP 
text)- you are correct that it is the same as a VQUERY against a 
Calendar."

We should have made the statement:

>  The reverse lookup from a CSID to a UPN is accomplished by looking at
>  the owner property of the calendar.

read:

"The reverse lookup from a CSID to one or more UPNs is accomplished 
by issuing a VQUERY and looking at the OWNER attribute."

-Bob


From owner-ietf-calendar  Wed Jan 26 11:49:59 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA10341
	for ietf-calendar-bks; Wed, 26 Jan 2000 11:49:59 -0800 (PST)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10337
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 11:49:57 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA11317; Wed, 26 Jan 00 14:52:48 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id OAA12865;
	Wed, 26 Jan 2000 14:45:23 -0500 (EST)
Received: from [18.177.0.98] (WINGNUT.MIT.EDU [18.177.0.98])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id OAA00416;
	Wed, 26 Jan 2000 14:45:22 -0500 (EST)
Mime-Version: 1.0
X-Sender: bobmah@po12.mit.edu
Message-Id: <v0422080ab4b4ebd82a42@[18.177.0.98]>
In-Reply-To: <OF52012F0E.A3ED873C-ON85256872.006138EB@Lotus.com>
References: <OF52012F0E.A3ED873C-ON85256872.006138EB@Lotus.com>
Date: Wed, 26 Jan 2000 14:45:09 -0500
To: <Frank_Dawson@lotus.com>
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: W-19 CAP Group Definitions
Cc: ietf-calendar@imc.org
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>


>Do you all realize we already differentiate in RFC2445 different CUTYPEs?
>
>This discussion about Group Definitions seems to be unnecessarily 
>conflicting with existing definitions of CU Types already codified 
>in iCalendar.
>
>Calendar user type is identified in the ATTENDEE property parameter 
>CUTYPE. The current enumerated values are INDIVIDUAL, GROUP, 
>RESOURCE or UNKNOWN.

We need to start carefully distinguishing between calendars and 
users.  ATTENDEEs are calendars, and should be referred to by CSIDs. 


We're not adding new group semantics to a CSID.  A CUA cannot 
distinguish between a C, a CC, or an RC.  However, if the CU knows 
that this CSID refers to a group or resource, the CU could instruct 
their CUA to use the CUTYPE of GROUP or RESOURCE.   However, the CS 
must take every CSID and evaluate it for expansion as a potential CC.

-Bob


From owner-ietf-calendar  Wed Jan 26 12:39:16 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA11410
	for ietf-calendar-bks; Wed, 26 Jan 2000 12:39:16 -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 MAA11406
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 12:39:14 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id MAA18990;
	Wed, 26 Jan 2000 12:40:57 -0800 (PST)
Message-ID: <388F5BCF.CBB94BA2@home.royer.com>
Date: Wed, 26 Jan 2000 12:40:47 -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: Bob Mahoney <bobmah@mit.edu>, ietf-calendar@imc.org
Subject: Re: W-19 CAP Group Definitions
References: <v04220805b4b3df056fac@[18.177.0.98]>	
	 <v04220807b4b4c5f03843@[18.177.0.98]> <388F33E2.99FF0F43@home.royer.com>
	 <v04220809b4b4eb360423@[18.177.0.98]> <388F4BE0.30FBEA0B@home.royer.com> <v0422080db4b4fcb71adc@[18.177.0.98]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB2150ACBD492FFD6D9F66B75"
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.

--------------msB2150ACBD492FFD6D9F66B75
Content-Type: multipart/mixed;
 boundary="------------F6AA351B9AD9F29D18955E70"

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

Bob Mahoney wrote:
> 
> >Exactly what? :-)
> >
> >Exactly you agree it is not needed as it is the same?
> >
> >Or exactly (because it is not the same) we need it?
> 
> Sorry!
> 
> "We included this for completeness only in our email (not the CAP
> text)- you are correct that it is the same as a VQUERY against a
> Calendar."
> 
> We should have made the statement:
> 
> >  The reverse lookup from a CSID to a UPN is accomplished by looking at
> >  the owner property of the calendar.
> 
> read:
> 
> "The reverse lookup from a CSID to one or more UPNs is accomplished
> by issuing a VQUERY and looking at the OWNER attribute."
> 
> -Bob

Sorry - I associated it with the LOOKUP command.
So now I am confused differently.

> > We want to add a new command called LOOKUP, which will accept a UPN,
> > and returns one or more CSIDs.  More than one CSID returned implies
> > that the UPN was a UG.

If my UPN is UPN-doug, and I own X different calendars, What would
you get back? One CSID for each calendar?

Or are you saying that if 'LOOKUP UPN-doug' returns more than one CSID
then any reference to UPN-doug applies to ALL of those CSID's.

What do you do with that information? Why is it needed?

Can you authenticate with a UG UPN? If not, when would you see them?
If you can authenticate with a UG UPN, do your operations apply
to all CSID's that it expands to? If so, we are introducing transaction
problems and we have deferred that to CAP-<later.version>.

If the CS says you do not have permission to access that information,
what feature(s) do you loose? I can still VQUERY on the CSID's, I can
still authenticate as UPN-doug. I am not sure what LOOKUP does for
me other than allow a CUA to look at the list (what for?).

If the CS (in previous email to this list) says that a UG can be
dynamicily altered and MUST NOT treat a UG as a static list. What
is to keep the LOOKUP results from being invalid the instant they
are returned? It looks to me that it allows a CUA to store a static
list? Which looks to me as if it also should not be allowed. So I 
do not yet see a need for LOOKUP. 

> > The reverse lookup from a CSID to a UPN is accomplished by looking at
> > the owner property of the calendar.
>
--------------F6AA351B9AD9F29D18955E70
Content-Type: text/x-vcard; charset=us-ascii;
 name="doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="doug.vcf"

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

--------------F6AA351B9AD9F29D18955E70--

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

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
ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI2MjA0MDQ5WjAjBgkqhkiG9w0BCQQxFgQUOA/ffiZy
Y38Y+wxeUfn3/8W3Og0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYAQXS4/p+xMyaJvgFpCrObFrQ4l/7ErZLYmEEH/XnIU7q8z1DhtbWHsHFAZSIjO
SPJRKr4aIOnMMySS34Rr5k2DTRow19w9m/Nen7p8pZpuruVow+dpaGZ6Tcowv7xsC2CpIOcV
b1aAj4rSRNMuGozzy4VFryBYIpZkQiWPor9v7w==
--------------msB2150ACBD492FFD6D9F66B75--


From owner-ietf-calendar  Wed Jan 26 12:47:14 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA11642
	for ietf-calendar-bks; Wed, 26 Jan 2000 12:47:14 -0800 (PST)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11638
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 12:47:12 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA02411; Wed, 26 Jan 00 15:50:04 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id PAA01607
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 15:48:57 -0500 (EST)
Received: from [18.177.0.98] (WINGNUT.MIT.EDU [18.177.0.98])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id PAA21551
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 15:48:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: bobmah@po12.mit.edu
Message-Id: <v0422080bb4b4f10b63bb@[18.177.0.98]>
Date: Wed, 26 Jan 2000 15:48:26 -0500
To: ietf-calendar@imc.org
From: Bob Mahoney <bobmah@mit.edu>
Subject: W-19 CAP Group Definitions - corrections to yesterday's work
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>

Updates and corrections to yesterday's Group proposal (Throw away 
yesterday's mail).  Commentary is in []'s.


--------------------------------
(CAP section "Definitions")

User Group (UG)

A collection of Calendar Users and/or User Groups.  These groups are 
expanded by the CS and may reside either locally or in an external 
database or directory.  The group membership may be fixed or dynamic 
over time.

Calendar (C)

<definition remains unchanged>

Calendar Collection (CC)

A collection of Calendars, Resource Calendars, and/or other Calendar 
Collections.  These collections are expanded by the CS and may reside 
either locally or in an external database or directory.  The 
calendars in the collection may be fixed or dynamic over time.

Resource Calendar (RC)

A non-human Calendar, associated with an organizational resource. 
There is no syntactic difference between an RC and a Calendar.

(Global modification for UPN definition)

Change " CU" to "CU or UG"; Change "user@example.com" to 
"user@example.com or group@example.com"


(CAP section "User Group")

A User Group is used to represent a collection of CUs or other UGs 
that can be referenced in VCARS.  A UG is represented in CAP as a 
UPN.  The CUA cannot distinguish between CUs and UGs.

UGs are expanded as necessary by the CS.  The CS MUST accept a CUA 
request for UG expansion, although the CS may be configured to 
restrict some responses.  The CS MAY expand a UG (including nested 
UGs) to obtain a list of unique CUs.  Duplicate UPNs are filtered 
during expansion.  Incomplete expansion should be treated as a 
failure.

[ Editor's Note: We need to explore the issue and impact of directory 
permissions and precedence.]

The CS SHOULD not preserve UG expansions across operations.  A UG may 
reference a static list of members, or it may represent a dynamic 
list.  Each operation SHOULD generate its own expansion in order to 
recognize changes to UG membership.  However, during fan out to other 
CSs, the originating CS SHOULD expand all UGs so that the target CS 
receives only a list of unique CUs.  This is to prevent confusion 
when two CSs do not share the same UG database or directory.

[Editor's Note: Doug had an issue here relating to multiple CUs not 
having a common directory.  We think the above text resolves this]

CAP does not define commands or methods for managing UGs.

Examples:

      Small UG - The Three Stooges.  There is only and always three at 
any one time.
      Large UG - The MIT graduating class of 1999.  This is a static list.
      Dynamic UG - The IETF membership, which is a large and changing 
list of members.
      Nested UG - The National Football League, made up of the AFC and 
NFC, which are made up of 3 divisions each...

(CAP table "CAP Calendaring Commands")

Add:

Command		Description

EXPAND		Return the members of the argument CSID.  Successful 
result yields one or more Calendars and/or Resource Calendars.  More 
than one C or RC returned implies that the CSID was a CC.

LOOKUP                      Return the members of the argument UPN. 
Successful result yields one or more CSIDs.  More than one CSID 
returned implies that the UPN was a UG.


(CAP section "VCalendar Access Rights")

Change: "Calendar User" to "CU or UG"

(CAP section "Access Rights")

Change: "Calendar User" to "CU or UG"

Add:

VCARS principals can be CU or UG UPNs. Whenever VCARs are evaluated, 
all referenced User Groups MUST be evaluated as an expanded list.  UG 
expansion SHOULD NOT persist across operations.

[Editor's Note: This is where we need to define precedence rules.]

(CAP section "State Diagram")

Add:

While in the Identified state, allow EXPAND and LOOKUP commands.

(CAP section "Capability Command")

Add:

Capability                 Occurs                 Description
-------------------------------------------------------------------
MAXEXPANDLIST   0 or 1                   An integer value that 
specifies the maximum number
                                                                 of 
UPNs that can be returned by the EXPAND Command.


MAXLOOKUPLIST   0 or 1                   An integer value that 
specifies the maximum number
                                                                 of 
CSIDs that can be returned by the LOOKUP Command.

[Doug- this is structured to mirror the other entries in the 
Capabilities Section...]

(CAP section "Transfer Protocol Commands")

Add:

EXPAND Command

Arguments:   CSID

Data:        data as described below

Result:      2.0 Successful, and requested data follows
              2.1 Permission Denied
              2.2 Requested CSID not found
              2.3 Result exceeds MAXEXPANDLIST
              2.4 Misc. EXPAND error

Example #1: Request lookup of CSID which is a Calendar Collection

C: EXPAND cap://cal.example.com/calid14
S: 2.0 cap://cal.example.com/calid14
S: cap://cal.example.com/calid2
S: cap://cal.example.com/calid5
S: cap://cal.example.com/calid66
S: .

Example #2: Request lookup of a CSID which is a Resource Calendar

C: EXPAND cap://cal.example.com/conf5
S: 2.0 cap://cal.example.com/conf5
S: cap://cal.example.com/conf5
S: .

Example #3: Request CSID which exceeds MAXEXPANDLIST

C: EXPAND cap://cal.example.com/calid76
S: 2.0 cap://cal.example.com/calid76
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid12
S: cap://cal.example.com/calid21
S: cap://cal.example.com/calid33
S: 2.3 Expansion resulted in too much data
S: .

Example #4: CS loses contact with directory server during EXPAND

C: EXPAND cap://cal.example.com/calid76
S: 2.0 cap://cal.example.com/calid76
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid5
S: 2.4 Lost contact with directory server
S: .


LOOKUP Command

Arguments:   UPN

Data:        data as described below

Result:      2.0 Successful, and requested data follows
              2.1 Permission Denied
              2.2 Requested UPN not found
              2.3 Result exceeds MAXLOOKUPLIST
              2.4 Misc. LOOKUP error

Example #1: Request lookup of a UPN which is a CU

C: LOOKUP upn@example.com
S: 2.0 upn@example.com
S: cap://cal.example.com/calid3
S: .

Example #2: Request lookup of UPN which is a UG

C: LOOKUP group@example.com
S: 2.0 group@example.com
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid6
S: cap://cal.example.com/calid1342
S: .

Example #3: Request lookup exceeds MAXLOOKUPLIST

C: LOOKUP group@example.com
S: 2.0 group@example.com
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid12
S: cap://cal.example.com/calid21
S: cap://cal.example.com/calid33
S: 2.3 Lookup resulted in too much data
S: .

Example #4: CS loses contact with directory server during LOOKUP

C: LOOKUP group@example.com
S: 2.0 group@example.com
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid5
S: 2.4 Lost contact with directory server
S: .


(CAP section "RIGHTS Value Type")

Change:

"The UPN rule part specifies the authenticated CU that the calendar 
access rights applies to."

to

"The UPN rule part specifies the CU or UG that the VCARs apply to.


From owner-ietf-calendar  Wed Jan 26 12:49:43 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11823
	for ietf-calendar-bks; Wed, 26 Jan 2000 12:49:43 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11819
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 12:49:42 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA24233; Wed, 26 Jan 00 15:50:59 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id PAA02404
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 15:51:28 -0500 (EST)
Received: from miles-davis (MILES-DAVIS.MIT.EDU [18.177.0.37])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id PAA22480
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 15:51:28 -0500 (EST)
Message-Id: <4.2.0.58.20000126153144.01aaf988@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 26 Jan 2000 15:47:46 -0500
To: ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: revised UPN definition
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>

Definitions section:

User Principal Name (UPN)

An identifier that denotes a unique CU. A UPN is an RFC 822 compliant email 
address and in most cases it is deliverable to the CU. In some cases it is 
identical to the CU's well known email address.  A CU's UPN MUST never be 
deliverable to a different person. It consists of a realm in the form of a 
valid, and unique, DNS domain name and a unique username. In it's simplest 
form it looks like "user@example.com".


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

Please let everyone know if you disagree or have concerns.

Paul

From owner-ietf-calendar  Wed Jan 26 12:55:22 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11951
	for ietf-calendar-bks; Wed, 26 Jan 2000 12:55:22 -0800 (PST)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA11947
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 12:55:18 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA05340; Wed, 26 Jan 00 15:58:11 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id PAA03947;
	Wed, 26 Jan 2000 15:57:03 -0500 (EST)
Received: from [18.177.0.98] (WINGNUT.MIT.EDU [18.177.0.98])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id PAA24226;
	Wed, 26 Jan 2000 15:57:03 -0500 (EST)
Mime-Version: 1.0
X-Sender: bobmah@po12.mit.edu
Message-Id: <v0422080fb4b50e1d35c5@[18.177.0.98]>
In-Reply-To: <388F5BCF.CBB94BA2@home.royer.com>
References: <v04220805b4b3df056fac@[18.177.0.98]>		
 <v04220807b4b4c5f03843@[18.177.0.98]> <388F33E2.99FF0F43@home.royer.com>	
 <v04220809b4b4eb360423@[18.177.0.98]> <388F4BE0.30FBEA0B@home.royer.com>
 <v0422080db4b4fcb71adc@[18.177.0.98]> <388F5BCF.CBB94BA2@home.royer.com>
Date: Wed, 26 Jan 2000 15:56:37 -0500
To: ietf-calendar@imc.org
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: W-19 CAP Group Definitions
Cc: Bob Mahoney <bobmah@mit.edu>, ietf-calendar@imc.org
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>


>  > > We want to add a new command called LOOKUP, which will accept a UPN,
>  > > and returns one or more CSIDs.  More than one CSID returned implies
>  > > that the UPN was a UG.
>
>If my UPN is UPN-doug, and I own X different calendars, What would
>you get back? One CSID for each calendar?
>
>Or are you saying that if 'LOOKUP UPN-doug' returns more than one CSID
>then any reference to UPN-doug applies to ALL of those CSID's.

This is addressed in the revised text we just sent.

>What do you do with that information? Why is it needed?

You have a UPN, and you need a CSID to schedule with, i.e., this is 
the ATTENDEE.  Another example is that you have a group of users that 
I want to invite to an event, and you want the list to be static.  (a 
snapshot of the current expansion of that UG)

>Can you authenticate with a UG UPN? If not, when would you see them?

No, but you want to see them for the reason above, as well as for VCARs.

>If you can authenticate with a UG UPN, do your operations apply
>to all CSID's that it expands to? If so, we are introducing transaction
>problems and we have deferred that to CAP-<later.version>.
>
>If the CS says you do not have permission to access that information,
>what feature(s) do you loose? I can still VQUERY on the CSID's, I can
>still authenticate as UPN-doug. I am not sure what LOOKUP does for
>me other than allow a CUA to look at the list (what for?).
>
>If the CS (in previous email to this list) says that a UG can be
>dynamicily altered and MUST NOT treat a UG as a static list. What
>is to keep the LOOKUP results from being invalid the instant they
>are returned?

Nothing...

>It looks to me that it allows a CUA to store a static
>list? Which looks to me as if it also should not be allowed. So I
>do not yet see a need for LOOKUP.

We say that neither the CS nor the CUA should preserve UG expansions 
across operations.  (Obviously some implementations will cache that 
expansion for a short period of time)

-bob


From owner-ietf-calendar  Wed Jan 26 14:11:12 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id OAA13597
	for ietf-calendar-bks; Wed, 26 Jan 2000 14:11:12 -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 OAA13593
	for <ietf-calendar@imc.org>; Wed, 26 Jan 2000 14:11:10 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id OAA19062;
	Wed, 26 Jan 2000 14:12:53 -0800 (PST)
Message-ID: <388F715F.CC3837A1@home.royer.com>
Date: Wed, 26 Jan 2000 14:12:47 -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: Bob Mahoney <bobmah@mit.edu>, ietf-calendar@imc.org
Subject: Re: W-19 CAP Group Definitions
References: <v04220805b4b3df056fac@[18.177.0.98]>		
	 <v04220807b4b4c5f03843@[18.177.0.98]> <388F33E2.99FF0F43@home.royer.com>	
	 <v04220809b4b4eb360423@[18.177.0.98]> <388F4BE0.30FBEA0B@home.royer.com>
	 <v0422080db4b4fcb71adc@[18.177.0.98]> <388F5BCF.CBB94BA2@home.royer.com> <v0422080fb4b50e1d35c5@[18.177.0.98]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD3A30C1A961B81E85D65E2F9"
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.

--------------msD3A30C1A961B81E85D65E2F9
Content-Type: multipart/mixed;
 boundary="------------A1581B6836AB3EB23227406A"

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

Bob Mahoney wrote:

> 
> >What do you do with that information? Why is it needed?
> 
> You have a UPN, and you need a CSID to schedule with, i.e., this is
> the ATTENDEE.  Another example is that you have a group of users that
> I want to invite to an event, and you want the list to be static.  (a
> snapshot of the current expansion of that UG)

I can see its usage as long as you can not schedule to a group name.
If you could then as people get added and deleted from the group name
then your original schedule request is bogus. As are (if you included
the entire ATTENDEE list in the REQUEST) the other ATTENDEE coppies.
I could see a flurry of updates to REQUEST if the list changes daily.

So if the CUA via an EXPAND gets a list name, then shows the CU
the list. And if only non-CG names are in the ATTENDEE list, I
can see how a CUA might use the list to generate an original REQUEST.
How would they update the component as members are added/deleted?

What if someone move between group-a to group-b, then they reply
that they will be attending - Is there a way for the CS or CUA
to know that they should be un-invited?

What if the CS policy is not to expand CG's. Can you still
schedule? If so, how would you send out the REQUEST's?

The CS NEEDS to know individuals (MAILTO) or individual calendars (CSID) only
in the ATTENDEE property. There needs to be a 1:1 mapping in the ATTENDEE lists. 
so status information can be maintained. Otherwise the 1st user in the
list to say 'no I will not attend' speaks for the entire group (CG).

We MUST never allow a CG in an ATTENDEE list? As there would be no way
to track who replied or what their ATTENDEE status was.

How do you get that CG-UPN?  It can not be in an ATTENDEE list.
So you could not have gotten it from a PUBLISH or REQUEST.
Were did it come from? Is it external to CAP (As in you just know
via email or something)?

I can see how a CG-UPN could be in a VCAR for dynamic expansion
of permissions. But how does it get specified? I could pass
down one with a VCAR/create, but how did I know the name in
order to specify it?

You can send email to a list expander, not the same problem.
You could send components to a CG, but not schedule with a CG - correct?
--------------A1581B6836AB3EB23227406A
Content-Type: text/x-vcard; charset=us-ascii;
 name="doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Doug Royer
Content-Disposition: attachment;
 filename="doug.vcf"

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

--------------A1581B6836AB3EB23227406A--

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

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
ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI2MjIxMjQ4WjAjBgkqhkiG9w0BCQQxFgQURe7rvXJY
/1KK77tPVWyztrqO7JMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYBJS8bjo+lQChvxe8HzVxx90dC4PW1S/lVQEmGoYSIkqcPDGe2PFdIMjPIapocE
3qYwH9CJ7ijN3s1lGqlGi2Cu9Hs6uel6Dz/Vrf6QWPXoCtiyKBJDEOJ6Ib6UgTyMdXDXsT0K
dDzrPrF3qIKcbwDlgyyOwwxqnxgPiNg/93c3Kg==
--------------msD3A30C1A961B81E85D65E2F9--


From owner-ietf-calendar  Thu Jan 27 08:00:53 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA22822
	for ietf-calendar-bks; Thu, 27 Jan 2000 08:00:53 -0800 (PST)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA22817
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 08:00:51 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA11928; Thu, 27 Jan 00 11:03:48 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id LAA19324
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 11:02:40 -0500 (EST)
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 LAA18715
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 11:02:38 -0500 (EST)
Message-Id: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 27 Jan 2000 10:59:19 -0500
To: ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: revised security section
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
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>

Hi,

Rich, Dave, Bob and I thought that we sent this out on Wednesday afternoon 
but it never made it to the list :(

---

Suggested replacements to existing sections: 2.4, 2.5, 2.7, 6.0. These 
changes create sections:

2.4 Security Model
2.4.1 Authentication, Credentials, and Identity
2.4.2   Calendar User and UPNs
2.4.2.1 UPNs and Certificates
2.4.2.2 Anonymous Users and Authentication
2.4.3   User Groups
2.4.4   Access Rights
2.4.4.1 VCalendar  Access Right (VCAR)
2.4.4.2 Enforced VCARs
2.4.4.3 Inheritance
2.4.4.4 Policies



This text will later be followed by new text for the AUTHENTICATE command. 
And even later more text of calendar addresses, including stuff on mapping 
UPNs to CSIDs, Calendar Collections, and Resource Calendars.

Paul

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

2.4 Security Model

Authentication to the CS will be performed using SASL [RFC2222].

As noted in the CAP system model section, a variety of connectivity 
scenarios are possible. This complicates the security model considerably, 
and a thorough familiarity with the concepts is required to ensure 
interoperability.

Basic threats to a Calendaring and Scheduling System include:

(1)     Unauthorized access to data via data-fetching operations,
(2)     Unauthorized access to reusable client authentication information 
by monitoring others' access,
(3)     Unauthorized access to data by monitoring others' access,
(4)     Unauthorized modification of data,
(5)     Unauthorized or excessive use of resources (denial of service), and
(6)     Spoofing of CS: Tricking a client into believing that information 
came from the CS when in fact it did not, either by modifying data in 
transit or misdirecting the client's connection.

Threats (1), (4), (5) and (6) are due to hostile clients. Threats (2), and 
(3) are due to hostile agents on the path between client and server, or 
posing as a server.

CAP can be protected with the following security mechanisms:

(1)     Client authentication by means of the SASL [RFC2222] mechanism set, 
possibly backed by the TLS credentials exchange mechanism,
(2)     Client authorization by means of access control based on the 
requestor's authenticated identity,
(3)     Data integrity protection by means of the TLS protocol or 
data-integrity SASL mechanisms,
(4)     Protection against snooping by means of the TLS protocol or 
data-encrypting SASL mechanisms,
(5)     Resource limitation by means of administrative limits on service 
controls, and
(6)     Server authentication by means of the TLS protocol or SASL mechanism.

Imposition of access controls (authorizations) is done by means of VCARs, 
an overview is provided in section 2.4.4.1, and a detailed syntax is 
provided in section 14.5.  Authentication is explained in detail in section 
7.1.3.

2.4.1 Authentication, Credentials, and Identity

Generically, authentication credentials are the evidence supplied by one 
party to another, asserting the identity of the supplying party (e.g. a 
user) who is attempting to establish an association with the other party 
(typically a server). Authentication is the process of generating, 
transmitting, and verifying these credentials and thus the identity they 
assert. An authentication identity is the name presented in a credential.

There are many forms of authentication credentials. The form used depends 
upon the particular authentication mechanism negotiated by the parties. For 
example: X.509 certificates, Kerberos tickets, simple identity and password 
pairs. Note that an authentication mechanism may constrain the form of 
authentication identities used with it.

SASL only provides a protocol to negotiate a mutually acceptable 
authentication mechanism. SASL itself does not constrain or dictate the 
form of the authentication identities used to perform the authentication.
2.4.2   Calendar User and UPNs
A Calendar User(CU) is an entity that can be authenticated. It is 
represented in CAP as a UPN. A UPN is the owner of a calendar and the 
subject of access rights.
The UPN representation is independent of the authentication mechanism used 
during a particular CUA/CS interaction. This is because UPNs are used 
within VCARs. If the UPN were dependant on the authentication mechanism, a 
VCAR could not be consistently evaluated. A CU may use one mechanism while 
using one CUA but the same CU may use a different authentication mechanism 
when using a different CUA, or while connecting from a different location.

The user may also have multiple UPNs for various purposes.

Note that the immutability of the user's UPN may be achieved by using 
SASL's authorization identity feature. (The transmitted authorization 
identity may be different than the identity in the client's authentication 
credentials.) [RFC2222, section 3] This also permits a CU to authenticate 
using their own credentials, yet request the access privileges of the 
identity for which they are proxying [RFC2222]. Also, the form of 
authentication identity supplied by a service like TLS may not correspond 
to the UPNs used to express a server's access control policy, requiring a 
server-specific mapping to be done. The method by which a server composes 
and validates an authorization identity from the authentication credentials 
supplied by a client is implementation-specific.

The authorization identity feature SHOULD not be used to provide an 
alternate mechanism to implement the ACTONBEHALFOF policy, that is 
described in section 2.4.4.3[ editor check before final cut].

For Calendaring and Scheduling Systems that are integrated with a directory 
system, the CS MUST support the ability to configure which schema attribute 
stores the UPN. The CS MAY allow one or more attributes to be searched for 
the UPN.
2.4.2.1 UPNs and Certificates
When using X.509 certificates for purposes of CAP authentication, the UPN 
should appear in the certificate. Unfortunately there is no single correct 
guideline for which field should contain the UPN.

 From RFC-2459, section 4.1.2.6 (Subject):
 If subject naming information is present only in the subjectAltName 
extension (e.g., a key bound only to an email address or URI), then the 
subject name MUST be an empty sequence and the subjectAltName extension 
MUST be critical.

Implementations of this specification MAY use these comparison rules to 
process unfamiliar attribute types (i.e., for name chaining). This allows 
implementations to process certificates with unfamiliar attributes in the 
subject name.

In addition, legacy implementations exist where an RFC 822 name is embedded 
in the subject distinguished name as an EmailAddress attribute.  The 
attribute value for EmailAddress is of type IA5String to permit inclusion 
of the character '@', which is not part of the PrintableString character 
set.  EmailAddress attribute values are not case sensitive (e.g., 
"fanfeedback@redsox.com" is the same as "FANFEEDBACK@REDSOX.COM").

Conforming implementations generating new certificates with electronic mail 
addresses MUST use the rfc822Name in the subject alternative name field 
(see sec. 4.2.1.7 [of RFC 2459]) to describe such identities.  Simultaneous 
inclusion of the EmailAddress attribute in the subject distinguished name 
to support legacy implementations is deprecated but permitted.











Since no single method of including the UPN in the certificate will work in 
all cases, CAP implementations MUST support the ability to configure what 
the mapping will be by the CS administrator. Implementations MAY support 
multiple mapping definitions, for example, the UPN may be found in either 
the subject alternative name field, or the UPN may be embedded in the 
subject distinguished name as an EmailAddress attribute.


Note: If a CS or CUA is validating data received via iMIP, if the 
"ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe Random 
User:juser@example.com" then the email address should be checked against 
the UPN, and the CN should also be checked. This is so the "ATTENDEE" 
property couldn't be munged to something misleading like "ATTENDEE;CN=Joe 
Rictus User:juser@example.com" and have it pass validation. This validation 
will also defeat other attempts at confusion.


2.4.2.2 Anonymous Users and Authentication
Anonymous access is often desirable. For example an organization may 
publish calendar information that does not require any access control for 
viewing or login. Conversely, a user may wish to view unrestricted calendar 
information without revealing their identity.


For anonymous access the UPN that MUST be used by the CUA is "@", a UPN 
with a null username and null realm. A UPN with a null username, but 
non-null realm, such as "@foo.com" may be used to mean any identity from 
that realm, which is useful to grant access rights to all users in a given 
realm. A UPN with a non-null username and null realm, such as "bob@" could 
be a security risk and MUST not be used.

For detailed syntax information on anonymous authentication please refer to 
the AUTHENTICATE command in section 7.1.3.
2.4.3   User Groups
A User Group is used to represent a collection of CUs or other UGs that can 
be referenced in VCARS.  A UG is represented in CAP as a UPN.  The CUA 
cannot distinguish between CUs and UGs.

UGs are expanded as necessary by the CS.  The CS MUST accept a CUA request 
for UG expansion, although the CS may be configured to restrict some 
responses.  The CS MAY expand a UG (including nested UGs) to obtain a list 
of unique CUs.  Duplicate UPNs are filtered during expansion.  Incomplete 
expansion should be treated as a failure.

[ Editor's Note: We need to explore the issue and impact of directory 
permissions and precedence.]

The CS SHOULD not preserve UG expansions across operations.  A UG may 
reference a static list of members, or it may represent a dynamic 
list.  Each operation SHOULD generate its own expansion in order to 
recognize changes to UG membership.  However, during fan out to other CSs, 
the originating CS SHOULD expand all UGs so that the target CS receives 
only a list of unique CUs.  This is to prevent confusion when two CSs do 
not share the same UG database or directory.

[Editor's Note: Doug had an issue here relating to multiple CUs not having 
a common directory.  We think the above text resolves this]

CAP does not define commands or methods for managing UGs.

Examples:

      Small UG - The Three Stooges.  There is only and always three at any 
one time.
      Large UG - The MIT graduating class of 1999.  This is a static list.
      Dynamic UG - The IETF membership, which is a large and changing list 
of members.
      Nested UG - The National Football League, made up of the AFC and NFC, 
which are made up of 3 divisions each...
2.4.4   Access Rights
In simple terms, access rights are used to grant or deny access to a 
calendar for a CU. CAP defines a new component type called a 
VCalendar  Access Right (VCAR). Specifically, a VCAR grants, or denies, 
UPNs the right to read and write components, properties, and parameters on 
calendars within a CS.

The VCAR model does not put any restriction on the sequence in which the 
object and access rights are created. That is, an event associated with a 
particular VCAR might be created before or after the actual VCAR is 
defined. In addition, the VCAR and VEVENT definition might be created in 
the same iCalendar object and passed together in a single command.

All rights MUST be denied unless specifically granted; individual VCARs 
MUST be specifically granted to an authenticated CU.
2.4.4.1 VCalendar  Access Right (VCAR)



Access rights within CAP are specified with the "VCAR" calendar component, 
"RIGHTS" value type and the "GRANT", "DENY" and "CARID" component properties.

Properties within an iCalendar object are unordered. This also is the 
case      for the "GRANT", "DENY" and "CARID" properties. Likewise, there 
is no implied ordering required for components of a "RIGHTS" value type 
other than that specified by the ABNF. [ editor's note, this requires a lot 
of review. We think that this paragraph may be incorrect. ]

For details on the VCAR syntax please see section 14.4
2.4.4.2 Enforced VCARs
[ editor's note: new concept. This will also require some syntax 
modification 14.4]

A CS MAY choose to allow forced VCARs on all calendars. This is not the 
same as inheritance.

2.4.4.3 Inheritance

Calendars inherit VCARs from their parent.

VCARs specified in a calendar or a sub-calendar override all inherited VCARs.
2.4.4.4 Policies
Calendar access policies are individual sets of well-defined VCARs that can 
be referenced by their policy name. CAP specifies some standard POLICIES 
that are necessary for interoperability between CS and CUA implementations. 
The POLICY rule part of a VCAR is used to specify these policies.

For details on the VCAR syntax please see section 14.4

NOTE: Possible calendar access policy that may be standardized by CAP  include:


- READBUSYTIMEINFO - Specifies rights for reading busy time data.

- ACTONBEHALFOF - Specifies rights for any CAP function taken on PUBLIC or 
PRIVATE calendar components. However, no CAP function can be taken on 
CONFIDENTIAL classified calendar components.

- REQUESTONLY - Specifies rights for creating new event invitations, to-do 
assignments and journal entries.

- UPDATEPARTSTATUS - Specifies rights for modifying ones own participation 
status.

- OWNER - Specifies the same rights given to the owner of the  calendar 
store or calendar.






From owner-ietf-calendar  Thu Jan 27 08:18:57 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA23320
	for ietf-calendar-bks; Thu, 27 Jan 2000 08:18:57 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23316
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 08:18:52 -0800 (PST)
From: Bruce_Kahn@iris.com
Importance: High
X-Priority: 1 (High)
To: Bob Mahoney <bobmah@mit.edu>
Cc: Frank_Dawson@lotus.com, ietf-calendar@imc.org
Subject: Re: W-19 CAP Group Definitions
X-Mailer: Lotus Notes Release 5.0.2  November 4, 1999
Message-ID: <OFF4C60F3B.BD6CDF68-ON85256873.00596A81@iris.com>
Date: Thu, 27 Jan 2000 11:20:43 -0500
X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/27/2000 11:20:24 AM,
	Serialize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/27/2000 11:20:24 AM,
	Serialize complete at 01/27/2000 11:20:24 AM,
	Itemize by Notes Client on Bruce Kahn/Iris(Release 5.0.2 |November 4, 1999) at
 01/27/2000 11:20:24 AM,
	S/MIME Sign complete at 01/27/2000 11:20:24 AM,
	Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 01/27/2000
 11:21:29 AM,
	Serialize complete at 01/27/2000 11:21:29 AM
MIME-Version: 1.0
Content-Type: multipart/signed;
	 protocol="application/x-pkcs7-signature";
	 micalg=sha1;
	 boundary=-------z01886_boundary_sign
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 an S/MIME signed message.

---------z01886_boundary_sign
Content-Type: multipart/alternative; boundary="=_alternative 0059C23C85256873_="

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

Bob wrote:
>We need to start carefully distinguishing between calendars and 
>users.  ATTENDEEs are calendars, and should be referred to by CSIDs. 

You need to be careful about using CSID vs CalID in your texts.  Calendar 
Stores are identified by CSIDs.  Calendars are identified by CalIDs.  Just 
because a Fully Qualified CalID contains a CSID, they are NOT 
interchangable; Relative CalIDs do not contain any CSID info.

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




<br><font size=2 face="sans-serif">Bob wrote:</font>
<br><font size=2 face="Courier New">&gt;We need to start carefully distinguishing between calendars and <br>
&gt;users. &nbsp;ATTENDEEs are calendars, and should be referred to by CSIDs. <br>
</font>
<br><font size=2 face="sans-serif">You need to be careful about using CSID vs CalID in your texts. &nbsp;Calendar Stores are identified by CSIDs. &nbsp;Calendars are identified by CalIDs. &nbsp;Just because a Fully Qualified CalID contains a CSID, they are NOT interchangable; Relative CalIDs do not contain any CSID info.</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 0059C23C85256873_=--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIAwggHZMIIBg6ADAgECAiBgUF6eflpWh6h9PfgYD7sAlMCM8enGl8RXOcIo9uhg
ezANBgkqhkiG9w0BAQQFADBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzEN
MAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTAeFw05OTEx
MTcxOTEzMjdaFw0wMTExMTYxOTEyNTNaMEgxDTALBgNVBAoTBElyaXMxEzARBgNV
BAMTCkJydWNlIEthaG4xIjAgBgkqhkiG9w0BCQEWE0JydWNlX0thaG5AaXJpcy5j
b20wWzANBgkqhkiG9w0BAQEFAANKADBHAkEA495S/vcTouExtWuNrF33Q28Lcjjk
4lj2W6ERZ3MhEBR5vHL3wTaXoRWVhPeoDaUcCc54oig8YQlC/hwSp3YF4QICQlGj
PDA6MBEGA1UdDgQKBAhG2i3x0db2dzAPBgNVHQ8BAf8EBQMDB7AAMBQGC2CGSAGG
+A4CAgMCBAUDAweAADANBgkqhkiG9w0BAQQFAANBAJnY7BPUuh9G4grcCnmNPlMH
JsE0/KULlvaqMab5uWQd0nFkZg64TIWwlYMLrwKqzenyrEkVF4QO6yjiShaej/Aw
ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVT
MQ0wCwYDVQQIEwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIElu
dGVybmV0IENBMB4XDTk4MTEwMjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkG
A1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMT
EElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAw+BjK0cg
xCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5yBLD
j5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwz
cO3Ltq2HlXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/wi
ngAAMYAwggF5AgEBMGowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL
BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0ECIGBQXp5+WlaH
qH09+BgPuwCUwIzx6caXxFc5wij26GB7MAkGBSsOAwIaBQCggaswGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI3MTYyMDI0WjAj
BgkqhkiG9w0BCQQxFgQU1rC9DY3ZVb6vLfPX731lq8DyQ9MwTAYJKoZIhvcNAQkP
MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D
AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQKh+7MVv9U47f/JI/ryj
H+q2Zr88wD4ueipsZ7HVBwKFKOqzu/jgBJB4FZ65fqScogK0ldIxxemrt1Mw6hCF
VFgAAAAAAAAAAA==

---------z01886_boundary_sign--

From owner-ietf-calendar  Thu Jan 27 08:59:57 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23910
	for ietf-calendar-bks; Thu, 27 Jan 2000 08:59:57 -0800 (PST)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA23906
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 08:59:55 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA03021; Thu, 27 Jan 00 12:02:46 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id LAA05728;
	Thu, 27 Jan 2000 11:56:17 -0500 (EST)
Received: from [18.177.0.98] (WINGNUT.MIT.EDU [18.177.0.98])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id LAA07129;
	Thu, 27 Jan 2000 11:56:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: bobmah@po12.mit.edu
Message-Id: <v04220802b4b6253260a5@[18.177.0.98]>
In-Reply-To: <OFF4C60F3B.BD6CDF68-ON85256873.00596A81@iris.com>
References: <OFF4C60F3B.BD6CDF68-ON85256873.00596A81@iris.com>
Date: Thu, 27 Jan 2000 11:55:54 -0500
To: <Bruce_Kahn@iris.com>
From: Bob Mahoney <bobmah@mit.edu>
Subject: Re: W-19 CAP Group Definitions
Cc: Bob Mahoney <bobmah@mit.edu>, Frank_Dawson@lotus.com,
        ietf-calendar@imc.org
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>


>You need to be careful about using CSID vs CalID in your texts. 
> Calendar Stores are identified by CSIDs.  Calendars are identified 
>by CalIDs.  Just because a Fully Qualified CalID contains a CSID, 
>they are NOT interchangable; Relative CalIDs do not contain any CSID 
>info.

:-)

We spent a *while* yesterday trying to fix little inconsistencies 
like this...  (we had, for example, used "group" several hundred 
times, and very often incorrectly)

I hope everyone continues to find problematic language or misuse of 
terms- frequently those folks most familiar with the drafts miss 
these gotchas, because they understand what was *intended*, even when 
it was stated poorly.

-Bob


From owner-ietf-calendar  Thu Jan 27 10:11:04 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA25468
	for ietf-calendar-bks; Thu, 27 Jan 2000 10:11:04 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA25461
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 10:11:01 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA13845; Thu, 27 Jan 00 13:12:21 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id NAA25878
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 13:12:51 -0500 (EST)
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 NAA29693
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 13:12:51 -0500 (EST)
Message-Id: <4.2.0.58.20000127130402.01a48e90@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 27 Jan 2000 13:09:32 -0500
To: ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: CAP Roles?
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,

The CAP draft has the following section of text:

CAP defines methods for managing [RFC2445] objects on a Calendar Store and 
exchanging [RFC2445] objects for the purposes of group calendaring and 
scheduling between "Calendar Users" (CUs). There are two	distinct roles 
taken on by CUs in CAP. The CU	who creates an initial event or to-do and 
invites other CUs as attendees takes on the role of "Organizer". The CUs 
asked to participate in the group event or to-do take on the role of 
"Attendee". Note that "role" is also a descriptive parameter to the 
"ATTENDEE" property. Its use is to convey descriptive context to	an 
"Attendee" such as "chair", "REQ-PARTICIPANT" or NON- PARTICIPANT" and has 
nothing to do with the scheduling workflow.

---------

Should the above text belong in CAP? As I recall, yesterday Richard 
convinced Dave, Bob, and I that it really belonged in an iCalendar 
extension document.

Paul

From owner-ietf-calendar  Thu Jan 27 10:11:51 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id KAA25481
	for ietf-calendar-bks; Thu, 27 Jan 2000 10:11:51 -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 KAA25477
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 10:11:49 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id KAA20261
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 10:13:39 -0800 (PST)
Message-ID: <38908ACB.D86F9DFB@home.royer.com>
Date: Thu, 27 Jan 2000 10:13:31 -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: VCAR unorderd (was: revised security section)
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms924A9EAB3D5FD16C929E664E"
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.

--------------ms924A9EAB3D5FD16C929E664E
Content-Type: multipart/mixed;
 boundary="------------82BB45D396EC2AAC5EDC5F4D"

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

"Paul B. Hill" wrote:

> Properties within an iCalendar object are unordered. This also is the
> case      for the "GRANT", "DENY" and "CARID" properties. Likewise, there
> is no implied ordering required for components of a "RIGHTS" value type
> other than that specified by the ABNF. [ editor's note, this requires a lot
> of review. We think that this paragraph may be incorrect. ]

This looks convenient:

	BEGIN:VCAR
	GRANT:UPN=all;<rule-set-Alpha>
	DENY:UPN=IDoNotLikeYou@example.com;<rule-set-Alpha>
	DENY:UPN...;<rule-set-Alpha>
	...
	END:VCAR

and might be different than:

	BEGIN:VCAR
	DENY:UPN=IDoNotLikeYou@example.com;<rule-set-Alpha>
	DENY:UPN...;rule-set-Alpha>
	...
	GRANT:UPN=all;<rule-set-Alpha>
	END:VCAR

If we do not order them, how can we do this? I think we
need to be able to do this. I don't think that we can
specify process ordering (as in DENY then GRANT) as
the example can be reversed:



	BEGIN:VCAR
	DENY:UPN=all;<rule-set-Alpha>
	GRANT:UPN=IDoNotLikeYou@example.com;<rule-set-Alpha>
	GRANT:UPN...;<rule-set-Alpha>
	...
	END:VCAR

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

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

--------------82BB45D396EC2AAC5EDC5F4D--

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

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
ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI3MTgxMzMzWjAjBgkqhkiG9w0BCQQxFgQUF4gn/veC
D2GBcOyMXvD3HTFOdTcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN
AQEBBQAEgYC7/XSqPLQOZlCkafUS9b5V9hpbmWkl4d58mULCvmBCP3zHAa6P43dlaArltMIs
DIuCrQOWc8C1oqmVlMMVq3NUUzkGePIGjDWFfkfUhBv4ZsEXl1dZmGsKEoVKUInWCRQzXmGE
dvLeIRpxezwq8ZT8ArRHVCo8RgQj0/5HeHFQrw==
--------------ms924A9EAB3D5FD16C929E664E--


From owner-ietf-calendar  Thu Jan 27 10:12:09 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA25505
	for ietf-calendar-bks; Thu, 27 Jan 2000 10:12:09 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA25499
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 10:12:07 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA14274; Thu, 27 Jan 00 13:13:25 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id NAA23905
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 13:04:58 -0500 (EST)
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 NAA27373
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 13:04:56 -0500 (EST)
Message-Id: <4.2.0.58.20000127121344.01a48e90@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 27 Jan 2000 13:01:37 -0500
To: ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: further suggestion for section 2.4.2.1
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,

Below are further suggested modifications to section 2.4.2.1 and section 
[TBD] for the syntactic details of anonymous authentication.
2.4.2.1 Anonymous Users and Authentication
Anonymous access is often desirable. For example an organization may 
publish calendar information that does not require any access control for 
viewing or login. Conversely, a user may wish to view unrestricted calendar 
information without revealing their identity.

For detailed syntax information on anonymous authentication please refer to 
the AUTHENTICATE command in section 7.1.3.



[7.1.?.?] ATHENTICATE - ANONYMOUS

RFC-2245 defines the Anonymous SASL mechanism. This RFC states that "the 
mechanism consists of a single message from the client to the server. The 
client sends optional trace information in the form of a human readable 
string. The trace information should take one of three forms: an Internet 
email address, an opaque string which does not contain the '@' character 
and can be interpreted by the system administrator of the client's domain, 
or nothing. For privacy reasons, an Internet email address should only be 
used with permission from the user. "

RFC-2245 goes on to state, " A client which uses the user's correct email 
address as trace information without explicit permission may violate that 
user's privacy." Information about who accesses an anonymous CS on a 
sensitive subject (e.g., AA meeting times and locations) has strong privacy 
needs. "Clients should not send the email address without explicit 
permission of the user and should offer the option of supplying no trace 
token -- thus only exposing the source IP address and time. "


Example of CUA using the Capability command followed by an anonymous 
authentication:

C: CAPABILITY
       S: 2.0
         S:CAPVERSION=1.0
         S:AUTH=KERBEROS_V4
         S:AUTH=DIGEST_MD5
         S:AUTH=ANONYMOUS
         S:.
         C:AUTHENTICATE ANONYMOUS
         S:+
         C:c21yaGM=
         S:2.0


Subsequent to the initial Anonymous Authentication with a CS, a CUA will 
have to provide a UPN for some CAP operations. For anonymous access the UPN 
that MUST be used by the CUA is "@", a UPN with a null username and null 
realm. A UPN with a null username, but non-null realm, such as 
"@example.com" may be used to mean any identity from that realm, which is 
useful to grant access rights to all users in a given realm. A UPN with a 
non-null username and null realm, such as "bob@" could MUST not be used.

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

As always, please send questions, comments, or concerns to the list.

Thanks.

Paul

From owner-ietf-calendar  Thu Jan 27 10:17:16 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA25588
	for ietf-calendar-bks; Thu, 27 Jan 2000 10:17:16 -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 KAA25583
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 10:17:15 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id KAA20266
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 10:19:06 -0800 (PST)
Message-ID: <38908C19.18A01472@home.royer.com>
Date: Thu, 27 Jan 2000 10:19:05 -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: forced VCAR (was: revised security section)
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
Content-Type: multipart/mixed;
 boundary="------------D3E90BF4B7B3255E9473A061"
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.
--------------D3E90BF4B7B3255E9473A061
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Paul B. Hill" wrote:

> 2.4.4.2 Enforced VCARs
> [ editor's note: new concept. This will also require some syntax
> modification 14.4]
> 
> A CS MAY choose to allow forced VCARs on all calendars. This is not the
> same as inheritance.

Also needs new text. What is a 'forced' VCAR?

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

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

--------------D3E90BF4B7B3255E9473A061--


From owner-ietf-calendar  Thu Jan 27 10:56:00 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA26192
	for ietf-calendar-bks; Thu, 27 Jan 2000 10:56:00 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA26188
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 10:55:59 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA29660; Thu, 27 Jan 00 13:57:17 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id NAA07714
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 13:57:47 -0500 (EST)
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 NAA12862;
	Thu, 27 Jan 2000 13:57:47 -0500 (EST)
Message-Id: <4.2.0.58.20000127134930.01a9dc30@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 27 Jan 2000 13:54:44 -0500
To: ietf-calendar@imc.org, ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: Re: forced VCAR (was: revised security section)
In-Reply-To: <38908C19.18A01472@home.royer.com>
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
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,

A CS MAY choose to implement and allow persistent immutable VCARs, that are 
configured by the CS Administrator, which apply to all calendars on the 
server. For example a company may decide that it wants all calendars on its 
server to have the Policy READBUSYTIMEINFO.

They made me use the shorter sentence. :)

Paul

At 10:19 AM 1/27/2000 -0800, Doug Royer wrote:
>"Paul B. Hill" wrote:
>
> > 2.4.4.2 Enforced VCARs
> > [ editor's note: new concept. This will also require some syntax
> > modification 14.4]
> >
> > A CS MAY choose to allow forced VCARs on all calendars. This is not the
> > same as inheritance.
>
>Also needs new text. What is a 'forced' VCAR?
>
>-Doug


From owner-ietf-calendar  Thu Jan 27 11:01:05 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26363
	for ietf-calendar-bks; Thu, 27 Jan 2000 11:01:05 -0800 (PST)
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 LAA26358;
	Thu, 27 Jan 2000 11:01:04 -0800 (PST)
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 OAA25730;
	Thu, 27 Jan 2000 14:17:46 -0500 (EST)
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 OAA04710;
	Thu, 27 Jan 2000 14:02:22 -0500 (EST)
To: "Paul B. Hill" <pbh@mit.edu>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@imc.org
Subject: Re: CAP Roles?
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF25157566.65E1E3B3-ON85256873.00680647@Lotus.com>
Date: Thu, 27 Jan 2000 14:03:22 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/27/2000 02:03:29 PM,
	Serialize complete at 01/27/2000 02:03:29 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0068D46185256873_="
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 0068D46185256873_=
Content-Type: text/plain; charset="us-ascii"

Paul:
Roles in iCalendar are participation roles within a meeting. Participation 
is identified by an ATTENDEE property. The valid roles are CHAIR, 
REQ-PARTICIPANT, OPT-PARTICIPANT, NON-PARTICIPANT. The ORGANIZER role is 
explicit by the specification of the ORGANIZER property within a group 
scheduled calendar component. The addition of ORGANIZER to the enumerated 
values of the ATTENDEE ROLE parameter is unnecessary and confuses the 
meaning of the original parameter.
If you want to know who created the event, this can be found by parsing 
for the ORGANIZER property. 
The suggestion of adding ORGANIZER value should not be included in either 
CAP or an iCalendar extension.
-- Frank

--=_alternative 0068D46185256873_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Paul:</font>
<p><font size=3 face="Courier New">Roles in iCalendar are participation roles within a meeting. Participation is identified by an ATTENDEE property. The valid roles are CHAIR, REQ-PARTICIPANT, OPT-PARTICIPANT, NON-PARTICIPANT. The ORGANIZER role is explicit by the specification of the ORGANIZER property within a group scheduled calendar component. The addition of ORGANIZER to the enumerated values of the ATTENDEE ROLE parameter is unnecessary and confuses the meaning of the original parameter.</font>
<p><font size=3 face="Courier New">If you want to know who created the event, this can be found by parsing for the ORGANIZER property. </font>
<p><font size=3 face="Courier New">The suggestion of adding ORGANIZER value should not be included in either CAP or an iCalendar extension.</font>
<p><font size=3 face="Courier New">-- Frank</font>
<p>
--=_alternative 0068D46185256873_=--

From owner-ietf-calendar  Thu Jan 27 11:08:23 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26488
	for ietf-calendar-bks; Thu, 27 Jan 2000 11:08:23 -0800 (PST)
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 LAA26483;
	Thu, 27 Jan 2000 11:08:22 -0800 (PST)
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 OAA26984;
	Thu, 27 Jan 2000 14:25:04 -0500 (EST)
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 OAA06145;
	Thu, 27 Jan 2000 14:09:39 -0500 (EST)
To: "Paul B. Hill" <pbh@mit.edu>
Cc: ietf-calendar@imc.org, owner-ietf-calendar@imc.org
Subject: Re: revised security section
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OFD4C0A565.2B64B014-ON85256873.00693D27@Lotus.com>
Date: Thu, 27 Jan 2000 14:10:36 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/27/2000 02:10:45 PM,
	Serialize complete at 01/27/2000 02:10:45 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 00697E0F85256873_="
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 00697E0F85256873_=
Content-Type: text/plain; charset="us-ascii"

Paul:
Shouldn't:
2.4.4.1 VCalendar  Access Right (VCAR)

Read:

2.4.4.1 Calendar Access Rights (CAR)

Yes, the component is probably identified as BEGIN:VCAR/END:VCAR. But, it 
defines a calendar access rights object, none the less.

-- Frank
--=_alternative 00697E0F85256873_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Paul:</font>
<p><font size=3 face="Courier New">Shouldn't:</font>
<p><font size=2 face="Courier New">2.4.4.1 VCalendar &nbsp;Access Right (VCAR)</font>
<br>
<br><font size=3 color=blue face="Courier New">Read:</font>
<br>
<br><font size=3 color=blue face="Courier New">2.4.4.1 Calendar Access Rights (CAR)</font>
<br>
<br><font size=3 color=blue face="Courier New">Yes, the component is probably identified as BEGIN:VCAR/END:VCAR. But, it defines a calendar access rights object, none the less.</font>
<br>
<br><font size=3 color=blue face="Courier New">-- Frank</font>
--=_alternative 00697E0F85256873_=--

From owner-ietf-calendar  Thu Jan 27 11:13:03 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26625
	for ietf-calendar-bks; Thu, 27 Jan 2000 11:13:03 -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 LAA26621
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 11:13:02 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA20315
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 11:14:48 -0800 (PST)
Message-ID: <38909927.A861FF28@home.royer.com>
Date: Thu, 27 Jan 2000 11:14:47 -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: CLASS ordering (was:  revised security section)
Content-Type: multipart/mixed;
 boundary="------------A7DC998C1AE7F3DC253911C2"
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.
--------------A7DC998C1AE7F3DC253911C2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> 2.4.4.4 Policies
> Calendar access policies are individual sets of well-defined VCARs that can
> be referenced by their policy name. CAP specifies some standard POLICIES
> that are necessary for interoperability between CS and CUA implementations.
> The POLICY rule part of a VCAR is used to specify these policies.

 
> - ACTONBEHALFOF - Specifies rights for any CAP function taken on PUBLIC or
> PRIVATE calendar components. However, no CAP function can be taken on
> CONFIDENTIAL classified calendar components.


I think the new "iCalendar" MUST specify the importance of PUBLIC, PRIVATE,
and CONFIDENTIAL!


We need to specify the ordering for PRIVATE, PUBLIC, and CONFIDENTIAL. The
above text almost does. Example on some existing CUA's, PRIVATE is more
restrictive than CONFIDENTIAL, others CONFIDENTIAL is more restrictive
than PRIVATE. Reading the above text it implies that CONFIDENTIAL is 
the most restrictive.

This can cause real security issues. CUA-A thinks CONFIDENTIAL is more
restrictive, CS-B thinks that PRIVATE is more restrictive. So CU-A
puts personal information in CONFIDENTIAL. CU-B might now see it as
their CS (CS-B) calendar policy allows CU-B to read it.

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

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

--------------A7DC998C1AE7F3DC253911C2--


From owner-ietf-calendar  Thu Jan 27 10:52:43 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id KAA26152
	for ietf-calendar-bks; Thu, 27 Jan 2000 10:52:43 -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 KAA26148
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 10:52:42 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id KAA20280
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 10:54:33 -0800 (PST)
Message-ID: <38909469.EECEB436@home.royer.com>
Date: Thu, 27 Jan 2000 10:54:33 -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: READBUSYTIMEINFO (was: revised security section)
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
Content-Type: multipart/mixed;
 boundary="------------BA8E2EF3C4CD16F4B373BB18"
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.
--------------BA8E2EF3C4CD16F4B373BB18
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


(I know the text I am commenting below is mostly from the existing CAP-DRAFT,
but I think they need comments).

> 2.4.4.4 Policies
> Calendar access policies are individual sets of well-defined VCARs that can
> be referenced by their policy name. CAP specifies some standard POLICIES
> that are necessary for interoperability between CS and CUA implementations.
> The POLICY rule part of a VCAR is used to specify these policies.
> 
> For details on the VCAR syntax please see section 14.4
> 
> NOTE: Possible calendar access policy that may be standardized by CAP include:
> 
> - READBUSYTIMEINFO - Specifies rights for reading busy time data.

Not specific... 
 
Does:

	BEGIN:VCAR
	CARID:my carid
	GRANT:UPN=<upnlist>;POLICY=READBUSYTIMEINFO
	END:VCAR

(1) Specify the rights for reading VFREEBUSY components? As in:

	BEGIN:VCAR
	CARID:READBUSYTIMEINFO
	GRANT:UPN=<upnlist>;OBJECT=VFREEBUSY;ACTION=READ
	END:VCAR

(2) Or do you mean perform any VQUERY with DTSTART/DTEND/DURATION ?
    as in:

	BEGIN:VCAR
	CARID:READBUSYTIMEINFO
	GRANT:UPN=<upnlist>;OBJECT=DTSTART,DTEND,DURATION;ACTION=READ
	END:VCAR

(3) Or do you mean both? As in:

	BEGIN:VCAR
	CARID:READBUSYTIMEINFO
	GRANT:UPN=<upnlist>:OBJECT=VFREEBUSY,DTSTART,DTEND,DURATION;ACTION=READ
	BEGIN:VCAR

I think the talks in the past meant (1), I am not sure and we
need to exactly specify its meaning.

If we mean (1), then what is to keep CUs from doing a VQUERY for
DTSTART/DTEND/DURATION and getting the same information outside of
using a VFREEBUSY?  Perhaps circumventing what the CU/administrator
thought they were getting with POLICY READBUSYTIMEINFO + DENY.
As in:

	BEGIN:VCAR
	CARID:my carid-2
	GRANT:UPN=<upnlist2>;POLICY=READBUSYTIMEINFO
	DENY:UPN=pain@example.com;POLICY=READBUSYTIMEINFO
	END:VCAR

What (if (1) above) would keep 'pain@example.com' from a VQUERY
for DTSTART/DTEND/DRUATION and the the same results?

If you say that you can allways in this case add extra DENY properties ...

	BEGIN:VCAR
	CARID:my carid-2
	GRANT:UPN=<upnlist2>;POLICY=READBUSYTIMEINFO
	DENY:UPN=pain@example.com;POLICY=READBUSYTIMEINFO
	DENY:UPN=pain@example.com;OBJECT=DTSTART,DTEND,DURATION;ACTION=READ
	END:VCAR

 ... then why not say that READBUSYTIMEINFO is (3)? When
 would you not want both of the DENY lines when you DENY any UPN VFREEBUSY?

If we mean (3) or (2) then how can we VQUERY for -ANY- component
where including DTSTART/DTEND/DURATION was restricted with
a POLICY READBUSYTIMEINFO + DENY?

VFREEBUSY is an iTIP idea that I do not think maps well into CAP.

Ether you want or do not want a UPN to be able to see your busy time.
If you do not want a UPN to see your busy time, then how usfull is
it to get 1+ VEVENTs without DTSTART/DTEND/DURATION ?

So in other words - WHY do we have READBUSYTIMEINFO? I think it does not
provide a generic policy that can work in an interoperable way.
And the access control can be provided exactly as the CU-owner
or CS-administrator whished using  non-POLICY VCARs. (as shown
above).

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

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

--------------BA8E2EF3C4CD16F4B373BB18--


From owner-ietf-calendar  Thu Jan 27 11:10:01 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26516
	for ietf-calendar-bks; Thu, 27 Jan 2000 11:10:01 -0800 (PST)
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 LAA26512;
	Thu, 27 Jan 2000 11:10:00 -0800 (PST)
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 OAA27226;
	Thu, 27 Jan 2000 14:26:41 -0500 (EST)
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 OAA06415;
	Thu, 27 Jan 2000 14:11:17 -0500 (EST)
To: ietf-calendar@imc.org
Cc: ietf-calendar@imc.org, owner-ietf-calendar@imc.org
Subject: Re: forced VCAR (was: revised security section)
X-Mailer: Lotus Notes Release 5.0.2b  December 16, 1999
Message-ID: <OF71E4B3B7.975B1D72-ON85256873.00696BAA@Lotus.com>
Date: Thu, 27 Jan 2000 14:12:19 -0500
X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/27/2000 02:12:23 PM,
	Serialize complete at 01/27/2000 02:12:24 PM,
	Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 01/27/2000 02:12:24 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0069A64085256873_="
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 0069A64085256873_=
Content-Type: text/plain; charset="us-ascii"

Is this a CS overriding the request CAR specified by a CUA with it's own 
default CAR?
If so, I assume that an exception would also be returned to the requesting 
CUA by the CS.
-- Frank
--=_alternative 0069A64085256873_=
Content-Type: text/html; charset="us-ascii"




<br><font size=3 face="Courier New">Is this a CS overriding the request CAR specified by a CUA with it's own default CAR?</font>
<p><font size=3 face="Courier New">If so, I assume that an exception would also be returned to the requesting CUA by the CS.</font>
<p><font size=3 face="Courier New">-- Frank</font>
--=_alternative 0069A64085256873_=--

From owner-ietf-calendar  Thu Jan 27 12:06:59 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA28211
	for ietf-calendar-bks; Thu, 27 Jan 2000 12:06:59 -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 MAA28207
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:06:57 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id MAA20346
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:08:49 -0800 (PST)
Message-ID: <3890A5D0.894404CD@home.royer.com>
Date: Thu, 27 Jan 2000 12:08:48 -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: REQUESTONLY (was: revised security section)
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
Content-Type: multipart/mixed;
 boundary="------------0AC8EB67BC3D080B5545FD80"
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.
--------------0AC8EB67BC3D080B5545FD80
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


 
> - REQUESTONLY - Specifies rights for creating new event invitations, to-do
> assignments and journal entries.

What exactly is this?

Does it mean I can  create new (direct book) an appointment? If so
why not name it CREATEONLY?

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

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

--------------0AC8EB67BC3D080B5545FD80--


From owner-ietf-calendar  Thu Jan 27 12:01:44 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28067
	for ietf-calendar-bks; Thu, 27 Jan 2000 12:01:44 -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 MAA28062
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:01:43 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id MAA20338
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:03:34 -0800 (PST)
Message-ID: <3890A496.89ACBD02@home.royer.com>
Date: Thu, 27 Jan 2000 12:03:34 -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: ACTONBEHALFOF (was: revised security section)
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
Content-Type: multipart/mixed;
 boundary="------------C949CEA0C7036599635D70AB"
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.
--------------C949CEA0C7036599635D70AB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> 2.4.4.4 Policies
> Calendar access policies are individual sets of well-defined VCARs that can
> be referenced by their policy name. CAP specifies some standard POLICIES
> that are necessary for interoperability between CS and CUA implementations.
> The POLICY rule part of a VCAR is used to specify these policies.
>
> ...
 
> - ACTONBEHALFOF - Specifies rights for any CAP function taken on PUBLIC or
> PRIVATE calendar components. However, no CAP function can be taken on
> CONFIDENTIAL classified calendar components.


This has been a request from day one. What 'exactly' is it?

Does this mean I can book using your name, with STATUS=CONFIRMED?
Does this mean I can book using your name , with STATUS=NEEDSACTION?
Both? Nether?

Does this mean I can REPLY for you?
Does this mean I can do anything except REPLY for you?
Does this mean I can ONLY REPLY for you and ONLY update STATUS and nothing else?

Does this mean I can REQUEST using your name, and update your calendar?
Does this mean I can REQUEST using your name, except I can not update your
calendar?

Does it mean I can alter your CAP calendar properties?
Does it mean I can do anything except alter your CAP calendar properties?

What exactly are the rules ?

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

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

--------------C949CEA0C7036599635D70AB--


From owner-ietf-calendar  Thu Jan 27 12:35:14 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28723
	for ietf-calendar-bks; Thu, 27 Jan 2000 12:35:14 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA28719
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:35:12 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA07129; Thu, 27 Jan 00 15:36:32 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id PAA05721;
	Thu, 27 Jan 2000 15:37:02 -0500 (EST)
Received: from miles-davis (MILES-DAVIS.MIT.EDU [18.177.0.37])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id PAA14569;
	Thu, 27 Jan 2000 15:37:01 -0500 (EST)
Message-Id: <4.2.0.58.20000127153336.01ab19d0@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 27 Jan 2000 15:33:52 -0500
To: Frank_Dawson@lotus.com, ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: Re: forced VCAR (was: revised security section)
In-Reply-To: <OF71E4B3B7.975B1D72-ON85256873.00696BAA@Lotus.com>
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>

At 02:12 PM 1/27/2000 -0500, Frank_Dawson@lotus.com wrote:

>Is this a CS overriding the request CAR specified by a CUA with it's own 
>default CAR?
>
>If so, I assume that an exception would also be returned to the requesting 
>CUA by the CS.
>
>-- Frank


Yes.

From owner-ietf-calendar  Thu Jan 27 12:30:39 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28643
	for ietf-calendar-bks; Thu, 27 Jan 2000 12:30:39 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA28639
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:30:38 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA05441; Thu, 27 Jan 00 15:31:58 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id PAA04389
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 15:32:28 -0500 (EST)
Received: from miles-davis (MILES-DAVIS.MIT.EDU [18.177.0.37])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id PAA13006;
	Thu, 27 Jan 2000 15:32:28 -0500 (EST)
Message-Id: <4.2.0.58.20000127135707.01b5ed60@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 27 Jan 2000 13:58:31 -0500
To: ietf-calendar@imc.org, ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: Re: READBUSYTIMEINFO (was: revised security section)
In-Reply-To: <38909469.EECEB436@home.royer.com>
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
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>

At 10:54 AM 1/27/2000 -0800, Doug Royer wrote:
> > - READBUSYTIMEINFO - Specifies rights for reading busy time data.
>
>Not specific...
>
>...

>I think the talks in the past meant (1), I am not sure and we
>need to exactly specify its meaning.

I think we originally said that we do need to specify the policies very 
clearly. But nobody has sat down and taken the time to write up a proposal yet.

Paul

From owner-ietf-calendar  Thu Jan 27 12:42:55 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28791
	for ietf-calendar-bks; Thu, 27 Jan 2000 12:42:55 -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 MAA28787
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:42:54 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id MAA20366
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:44:45 -0800 (PST)
Message-ID: <3890AE3C.31C5A7C1@home.royer.com>
Date: Thu, 27 Jan 2000 12:44:44 -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: OWNER (was: revised security section)
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
Content-Type: multipart/mixed;
 boundary="------------F5AF1E7BEE9C261609670E00"
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.
--------------F5AF1E7BEE9C261609670E00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 
> - OWNER - Specifies the same rights given to the owner of the  calendar
> store or calendar.

The OWNER is given rights. CS policy may mandate that certain operations
can not be done by an OWNER. An example given at the LA IETF was
some calendars might NEVER allow deletions - for government tracking.

So, if the OWNER policy is the SAME RIGHTS GIVEN TO OWNER. Why
not make them an OWNER? 

And why do we need an OWNER policy?

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

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

--------------F5AF1E7BEE9C261609670E00--


From owner-ietf-calendar  Thu Jan 27 12:47:45 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28855
	for ietf-calendar-bks; Thu, 27 Jan 2000 12:47:45 -0800 (PST)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA28850
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:47:44 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA24322; Thu, 27 Jan 00 15:50:38 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id PAA09301
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 15:49:30 -0500 (EST)
Received: from miles-davis (MILES-DAVIS.MIT.EDU [18.177.0.37])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id PAA18603
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 15:49:29 -0500 (EST)
Message-Id: <4.2.0.58.20000127154336.01a7e538@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 27 Jan 2000 15:46:40 -0500
To: ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: Re: OWNER (was: revised security section)
In-Reply-To: <3890AE3C.31C5A7C1@home.royer.com>
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
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 Doug,

A short sidebar not intended for the list...

At 12:44 PM 1/27/2000 -0800, you wrote:
>And why do we need an OWNER policy?


:) I think you were the person that wrote all of the policy text :) It was 
not anyone at the meeting that took place this week.

Seriously, I think the time has come for submitting suggested changes to 
this section, possibly along with some comments explaining the reasoning, 
instead of asking someone else to justify and explain. If all we ever do is 
ask, the section is unlikely to get finished.

Paul

From owner-ietf-calendar  Thu Jan 27 12:43:43 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA28805
	for ietf-calendar-bks; Thu, 27 Jan 2000 12:43:43 -0800 (PST)
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA28801
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 12:43:42 -0800 (PST)
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA10801; Thu, 27 Jan 00 15:45:02 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id PAA08109
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 15:45:31 -0500 (EST)
Received: from miles-davis (MILES-DAVIS.MIT.EDU [18.177.0.37])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id PAA17231
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 15:45:31 -0500 (EST)
Message-Id: <4.2.0.58.20000127153625.01bf4850@po12.mit.edu>
X-Sender: pbh@po12.mit.edu (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 27 Jan 2000 15:42:24 -0500
To: ietf-calendar@imc.org
From: "Paul B. Hill" <pbh@mit.edu>
Subject: Re: ACTONBEHALFOF (was: revised security section)
In-Reply-To: <3890A496.89ACBD02@home.royer.com>
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu>
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>

At 12:03 PM 1/27/2000 -0800, Doug Royer wrote:

> > 2.4.4.4 Policies

I'm glad the discussion has started but at the interim meeting  we did not 
modify the VCAR and Policy text. In this area all we started on was a 
reorganization so that a reader didn't half to traverse the entire document 
several times to find the relevant sections.

Paul

From owner-ietf-calendar  Thu Jan 27 13:31:30 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA29540
	for ietf-calendar-bks; Thu, 27 Jan 2000 13:31:30 -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 NAA29536
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 13:31:29 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id NAA20390
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 13:33:20 -0800 (PST)
Message-ID: <3890B9A0.3E3C906D@home.royer.com>
Date: Thu, 27 Jan 2000 13:33:20 -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: OWNER (was: revised security section)
References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu> <4.2.0.58.20000127154336.01a7e538@po12.mit.edu>
Content-Type: multipart/mixed;
 boundary="------------EF88001D5B158BC38007683A"
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.
--------------EF88001D5B158BC38007683A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Paul B. Hill" wrote:
> 
> Hi Doug,
> 
> A short sidebar not intended for the list...
> 
> At 12:44 PM 1/27/2000 -0800, you wrote:
> >And why do we need an OWNER policy?
> 
> :) I think you were the person that wrote all of the policy text :) It was
> not anyone at the meeting that took place this week.

No, it was Frank. I have always been opposed to POLICY. I have
yet to see any one that can not be done with a VCAR (I wrote VCAR - then
VACL).

> Seriously, I think the time has come for submitting suggested changes to
> this section, possibly along with some comments explaining the reasoning,
> instead of asking someone else to justify and explain.

I am sill looking for a reason for them to exist. I was not complaining,
just starting to do what I can to get rid if them. Someone needs to
justify and explain them, especially in the draft, or we need to  drop them.

I did not mean to imply that they were modified or reviewed this week.

> If all we ever do is
> ask, the section is unlikely to get finished.

I would like to delete the POLICY section and all references to POLICY.
My next email (formulating it now), I'll propose how to delete POLICY
and replace them with VCARs. I just needed to set the framework for
my next comments.

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

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

--------------EF88001D5B158BC38007683A--


From owner-ietf-calendar  Thu Jan 27 17:53:10 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id RAA03811
	for ietf-calendar-bks; Thu, 27 Jan 2000 17:53:10 -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 RAA03807
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 17:53:09 -0800 (PST)
Received: from home.royer.com (home.royer.com [192.168.168.10])
	by home.royer.com (8.9.1/8.9.1) with ESMTP id RAA20550
	for <ietf-calendar@imc.org>; Thu, 27 Jan 2000 17:55:01 -0800 (PST)
Message-ID: <3890F6EE.D3D2363D@home.royer.com>
Date: Thu, 27 Jan 2000 17:54:54 -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: POLICY in general.
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBB6F460385A37E01AC0BB6BB"
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.

--------------msBB6F460385A37E01AC0BB6BB
Content-Type: multipart/mixed;
 boundary="------------37C9DFF6386FCE28DBB395CB"

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




Originally the discussions surrounding POLICY it was started when some said
they wanted a simplified access rules for thinner CS's.

Now we can have a compatibility problem if we do not map from
one model into another. So if we keep POLICY, it is time now
to define them, or drop them and only use VCARs. And I think
we can drop them and specify a minimum set of VCARs that
a CS MUST support. And report that set with CAPABILITY.

Will call this minimum set 'CAR-MIN'.

Can a CS support POLICY only? Not from reading the cap-draft-text.
It does not state that anywhere and the ABNF implies both MUST be
supported. It looks like all CS's must support POLICY and
non-POLICY VCAR's. However from hallway conversations, I think
others will have strong opinions on this ...

	... if so SPEAK UP NOW!

(1) READBUSYTIMEINFO - Specifies rights for reading busy time data.

    As I have pointed out in previous email, I think we can eliminate
    this entirely. (See CAPABILITY below also).

	Example:

		replace:
			BEGIN:VCAR
			CARID:name
			GRANT:UPN=<...>;POLICY=READBUSYTIMEINFO
			END:VCAR

		With:

			BEGIN:VCAR
			CARID:READBUSYTIMEINFO
			GRANT:UPN=<...>;OBJECT=VFREEBUSY;ACTION=READ
			DENY:UPN=<...>;OBJECT=VFREEBUSY;ACTION=READ
			END:VCAR

			(or OBJECT=VFREEBUSY,DTSTART,DTEND,DURATION if the WG
			 wants READBUSYTIMEINFO to mean that).


(2) REQUESTONLY - Specifies righ