From owner-ietf-calendar@imc.org Sun Jan 2 03:27:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02215 for ; Sun, 2 Jan 2000 03:27:55 -0500 (EST) 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 ; 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 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: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled 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? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. U [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema U W-14 CAP VEVENT Schema U W-15 CAP VTODO Schema U W-16 CAP VJOURNAL Schema U W-17 CAP VCAR Schema U W-18 CAP UPN definition, including anonymous U user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and U static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED U and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA U W-23 CAP Calendar property to allow/disallow U overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues U W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH U (CAP-00 - 12.2) Will there need to be one? U Optional? U W-29 Import/Export U ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@imc.org Mon Jan 3 10:12:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02400 for ; Mon, 3 Jan 2000 10:12:21 -0500 (EST) 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 ; 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Mon Jan 3 12:00:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04203 for ; Mon, 3 Jan 2000 12:00:15 -0500 (EST) 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 ; 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: 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: List-ID: List-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"
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_=-- ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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@imc.org Tue Jan 4 07:31:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27666 for ; Tue, 4 Jan 2000 07:31:06 -0500 (EST) 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 ; 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: Date: Tue, 4 Jan 2000 12:03:16 +0000 To: ietf-calendar@imc.org From: Paul Overell Subject: iMIP, RFC2447 and [RFC-1847]-compliant encryption MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.00 beta 1 M Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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@imc.org Tue Jan 4 10:35:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00510 for ; Tue, 4 Jan 2000 10:35:27 -0500 (EST) 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 ; 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 ; 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 ; 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 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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 : > > > > So, a rule looks like : > FREQ=YEARLY;COUNT=5;BYDAY=1MO > > 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@imc.org Tue Jan 4 11:46:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02129 for ; Tue, 4 Jan 2000 11:46:39 -0500 (EST) 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 ; 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: 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: List-ID: List-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"
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:

  1. Usigned, unencrypted entries (no outter MIME wrappers):
  1. text/calendar MIME (a basic calendar entry; no attachments)
  2. multipart/related MIME (a basic calendar entry; 1+ attachments)
  3. Signed, unencrypted entries (outter multipart/signed MIME wrapper):
  1. text/calendar MIME (a basic calendar entry; no attachments)
  2. multipart/related MIME (a basic calendar entry; 1+ attachments)
  3. Unsigned, Encrypted entries (outter multipart/encrypted MIME wrapper):
  1. text/calendar MIME (a basic calendar entry; no attachments)
  2. multipart/related MIME (a basic calendar entry; 1+ attachments)
  3. Signed, Encrypted entries (outter multipart/signed and multipart/encrypted MIME wrappers):
  1. text/calendar MIME (a basic calendar entry; no attachments)
  2. 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_=-- ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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@imc.org Tue Jan 4 21:47:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12933 for ; Tue, 4 Jan 2000 21:47:28 -0500 (EST) 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 ; 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 ; Tue, 4 Jan 2000 19:19:48 -0800 From: Philippe Lesage 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: In-Reply-To: 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > 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 : 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@imc.org Wed Jan 5 08:55:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04914 for ; Wed, 5 Jan 2000 08:55:53 -0500 (EST) 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Wed Jan 5 11:06:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08939 for ; Wed, 5 Jan 2000 11:06:41 -0500 (EST) 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 ; 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 ; 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 ; 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 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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" --------------------------------------------------- --------------------------------------------------- Philippe Lesage wrote: > What do you think about it ? > > --------------------------------------------------- > freq CDATA #IMPLIED > until CDATA #IMPLIED > count CDATA #IMPLIED > wkst CDATA #IMPLIED > interval CDATA #IMPLIED "> > > > > > %attr.recrule; > value NOTATION (RECUR) #IMPLIED> > > > %attr.recrule; > value NOTATION (RECUR) #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@imc.org Wed Jan 5 12:42:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11618 for ; Wed, 5 Jan 2000 12:42:57 -0500 (EST) 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 ; 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 ; 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 ; 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 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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Wed Jan 5 21:35:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19668 for ; Wed, 5 Jan 2000 21:35:50 -0500 (EST) 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 ; 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 Cc: ietf-calendar@imc.org Subject: Re: XML DTD update proposition X-Mailer: Lotus Notes Build V5010624 June 24, 1999 Message-ID: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Wed Jan 5 21:39:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19697 for ; Wed, 5 Jan 2000 21:39:25 -0500 (EST) 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 ; 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 Cc: ietf-calendar@imc.org Subject: Re: XML DTD update proposition X-Mailer: Lotus Notes Build V5010624 June 24, 1999 Message-ID: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Thu Jan 6 01:18:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24484 for ; Thu, 6 Jan 2000 01:18:50 -0500 (EST) 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 ; 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 ; Wed, 5 Jan 2000 22:56:53 -0800 From: Philippe Lesage 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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@imc.org Thu Jan 6 12:14:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16892 for ; Thu, 6 Jan 2000 12:14:24 -0500 (EST) 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 ; 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 ; 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 ; 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 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Thu Jan 6 12:42:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17869 for ; Thu, 6 Jan 2000 12:42:03 -0500 (EST) 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 ; 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 ; Thu, 6 Jan 2000 10:00:07 -0800 From: Philippe Lesage 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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 tags ? Or if you choose the limit to be at the component level then the recipient would get an xml structure containing some , , ... , 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@imc.org Thu Jan 6 14:09:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20072 for ; Thu, 6 Jan 2000 14:09:58 -0500 (EST) 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 ; 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 ; 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 ; 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 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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Fri Jan 7 12:11:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22977 for ; Fri, 7 Jan 2000 12:11:45 -0500 (EST) 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 ; 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 Cc: ietf-calendar@imc.org Subject: Re: XML DTD update proposition X-Mailer: Lotus Notes Build V5010624 June 24, 1999 Message-ID: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Fri Jan 7 17:11:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28252 for ; Fri, 7 Jan 2000 17:11:15 -0500 (EST) 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 ; 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 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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: misha 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@imc.org Sat Jan 8 07:08:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17909 for ; Sat, 8 Jan 2000 07:08:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09739 for ietf-calendar-bks; Sat, 8 Jan 2000 03:52:54 -0800 (PST) Received: from energy.ogu.edu.tr (root@energy.ogu.edu.tr [193.140.141.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09475; Sat, 8 Jan 2000 03:48:40 -0800 (PST) From: blilrel16@aol.com Received: from energy.ogu.edu.tr (98C9FD37.ipt.aol.com [152.201.253.55]) by energy.ogu.edu.tr (8.8.8/8.8.4) with SMTP id NAA03399; Sat, 8 Jan 2000 13:42:37 +0200 Date: Sat, 08 Jan 00 01:43:26 EST To: Friend@public.com Subject: A Search Engine Just For You ! Message-ID: <> Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This e-mail is to inform you of a new search engine for adult web sites: http://www.adultfairlinks.com. Fairlinks is being built at this time and will be launched in a few months. We are contacting webmasters now so you can take a look at the site and give us any input you may have. This site will be unique since it will be a TRUE SEARCH ENGINE FOR ADULT SITES. There will be no banner ads, no support from any adult site. All categories will rotate so that each site will be at the top. Two thirds of all money collected will then be used to promote Fairlinks. Most advertising will be done off the web with plans already made to market the site on the Internet. We are going to pool thousands of adult sites together to form a partnership that will make a formidable force and to have funds for national advertising. Please take a look, join in and get your site promoted as it should be! http://www.adultfairlinks.com To be removed, call (888) 341-4786 and Clearly spell your email address and you will be removed. From owner-ietf-calendar@imc.org Sun Jan 9 03:21:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01764 for ; Sun, 9 Jan 2000 03:21:15 -0500 (EST) 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 ; 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 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: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled 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? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. U [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema U W-14 CAP VEVENT Schema U W-15 CAP VTODO Schema U W-16 CAP VJOURNAL Schema U W-17 CAP VCAR Schema U W-18 CAP UPN definition, including anonymous U user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and U static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED U and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA U W-23 CAP Calendar property to allow/disallow U overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues U W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH U (CAP-00 - 12.2) Will there need to be one? U Optional? U W-29 Import/Export U ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@imc.org Mon Jan 10 03:08:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27662 for ; Mon, 10 Jan 2000 03:08:28 -0500 (EST) 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 ; 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 ; 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 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: <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: List-ID: List-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 : > > 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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTEwMDczNTAzWjAjBgkqhkiG9w0BCQQxFgQUiy0lJUek Uly3ucQIyR+OpHBEUMUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYC4VQv2c/EmEVRynPODok/nvDQsBmPZY4ON+RLQ/jCWqBc7fUSpQyTEP0mGJPqI L4ax+mvEy9vc3hSsuZRal6zCstXr3Ty2gM31exQWG2fV69CynuTSrgT2YngVQuoK3FvyuzRy b4fRQ4t14ynLiW1vpoGW3CPUI2oZundxgY3d3A== --------------msF914FF377866CEBD644A89C6-- From owner-ietf-calendar@imc.org Mon Jan 10 05:10:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28386 for ; Mon, 10 Jan 2000 05:10:59 -0500 (EST) 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 ; 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 ; Mon, 10 Jan 2000 01:41:14 -0800 From: Philippe Lesage 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: <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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit >> >> > >> > 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 : >> >> 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@imc.org Mon Jan 10 10:02:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05428 for ; Mon, 10 Jan 2000 10:02:28 -0500 (EST) 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 ; 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Tue Jan 11 11:27:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14405 for ; Tue, 11 Jan 2000 11:27:28 -0500 (EST) 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 ; 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 ; 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 ; Tue, 11 Jan 2000 10:48:15 -0500 Message-ID: From: Antony Davies To: "'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: List-ID: List-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@imc.org Tue Jan 11 12:50:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16867 for ; Tue, 11 Jan 2000 12:50:33 -0500 (EST) 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 ; 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 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Tue Jan 11 15:50:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20945 for ; Tue, 11 Jan 2000 15:50:13 -0500 (EST) 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 ; 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 ; 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 ; 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: 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: List-ID: List-Unsubscribe: Folks: What are the plans for the CalConnect? Is this still planned for February? -- Frank From owner-ietf-calendar@imc.org Tue Jan 11 20:34:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24138 for ; Tue, 11 Jan 2000 20:34:03 -0500 (EST) 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 ; 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 ; 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 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: <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: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjAxMDY1NlowIwYJKoZIhvcNAQkEMRYEFNEE 3NEEOHu5JtUW/FH71l+ZpV8SMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAd675VnGixpbSGM7iuNy1Rm/YOh3tVQTE+AGPtPdg2zxxsHBixy3WkAe9 9oIOCeDQLNwG/6DR7LHjpihi6uKHmeXXBlPweE2P4oLSearQAQGk5d04uo3ao2MtALA/Bthr RNfNUs0xjr+99mqVT+6n6MmskuL3MWcVYK24cMsYISA= --------------ms97A31D930FCD5A1F7EC7CCC4-- From owner-ietf-calendar@imc.org Tue Jan 11 20:42:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24180 for ; Tue, 11 Jan 2000 20:42:18 -0500 (EST) 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 ; 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 ; 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 Reply-To: CalSched IETF Organization: Software.com X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: W-19 - open item - can we defer it? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEA48C6DBAB54887547F5B1CF" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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=... > >GRANT:UPN=... > >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=:< Querying-CU's-UPN> END:VCAR Or: BEGIN:VCAR CARID:Permisssions for group 'A' DENY;MEMBER=:< 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=:UPN=<...> ... DENY;GROUP=: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-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjAwNTQzMFowIwYJKoZIhvcNAQkEMRYEFHOV IggqORDC/+99BpIRrifBXFzgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGATTd2FgLaP8anjkAh81Y1h4Rsx52oZVs5v+hnzoKb1gS1hOPcgrnrt/TU T3gmJW5uHot4UdzIzs1wergUOX61/rp+pWREmcMlXE7J7Yf8LDRG5AyWrQaoviD37TEDSY7h nTNNGkmV9sTcQp8t3maABRUWJMUSnzk35hXt+s/8aLU= --------------msEA48C6DBAB54887547F5B1CF-- From owner-ietf-calendar@imc.org Tue Jan 11 20:42:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24193 for ; Tue, 11 Jan 2000 20:42:55 -0500 (EST) 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 ; 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 ; 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 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: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms35360E07EA2B2696B970F636" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjAxMTMzN1owIwYJKoZIhvcNAQkEMRYEFJyD bzEk9xdR+87FoY6X+t++7Z3mMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAlZD0bR4rv2BJnjXD+GIvA+sIFfzmeqYKOGY61XVvt/KL5t6PcorjgtNx uKZbRb/ZkRGorg+VaYo8pBpOcGan1i7JFx0sgC1g05sdyNItfW65XP7l1bVRIK7u3BjQ2o3T WVqI+u5RE+1U4LWfIQxImqRpPKEhlitT7bNjcrtg7Qg= --------------ms35360E07EA2B2696B970F636-- From owner-ietf-calendar@imc.org Wed Jan 12 10:25:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17700 for ; Wed, 12 Jan 2000 10:25:37 -0500 (EST) 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 ; 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 ; Wed, 12 Jan 2000 09:58:25 -0500 (EST) Message-ID: <002601bf5d0d$a2030c50$b94b6ed1@ANAND> From: "Anand Sancheti" To: 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: List-ID: List-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

Unsubscribe
------=_NextPart_000_0023_01BF5CE3.B8C51AC0-- From owner-ietf-calendar@imc.org Wed Jan 12 10:25:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17717 for ; Wed, 12 Jan 2000 10:25:53 -0500 (EST) 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 ; 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: 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: List-ID: List-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@imc.org Wed Jan 12 11:01:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18248 for ; Wed, 12 Jan 2000 11:01:10 -0500 (EST) 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 ; 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Wed Jan 12 11:48:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19329 for ; Wed, 12 Jan 2000 11:48:21 -0500 (EST) 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 ; 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 ; 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 ; 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: 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: List-ID: List-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 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"
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_=-- From owner-ietf-calendar@imc.org Wed Jan 12 11:59:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19482 for ; Wed, 12 Jan 2000 11:58:59 -0500 (EST) 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 ; 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" To: Cc: "Gilles Fortin" Subject: SV: New Topic: Export of calendar data and metadata Date: Wed, 12 Jan 2000 17:43:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Wed Jan 12 11:59:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19494 for ; Wed, 12 Jan 2000 11:59:09 -0500 (EST) 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 ; 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 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 , ietf-calendar@imc.org Subject: Re: New Topic: Export of calendar data and metadata References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Wed Jan 12 12:30:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20137 for ; Wed, 12 Jan 2000 12:30:09 -0500 (EST) 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 ; 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Wed Jan 12 12:33:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20249 for ; Wed, 12 Jan 2000 12:33:25 -0500 (EST) 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 ; 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 ; 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 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: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8E5E22D99119C2F30CDE2939" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjE3MTEyM1owIwYJKoZIhvcNAQkEMRYEFD6c CteI21xaBDYe61JokTzV7ZvMMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAPO7Nf169di9ZLiu8wekQKCSdJD/RwCpJxEgm4H1xiNF9IIGPwVN1epup t+VLC7QKZNRBrumzzAd1FDVx+DYfRdMfy3oofv/yTdhoECBEuJQ4QyAYoEGNBSk3yn3nFtjD Y/jiL+L33IfuokI1zrH4BkzSopl0kHOO4eBD5Zt+2h8= --------------ms8E5E22D99119C2F30CDE2939-- From owner-ietf-calendar@imc.org Wed Jan 12 12:37:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20351 for ; Wed, 12 Jan 2000 12:37:26 -0500 (EST) 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" 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Wed Jan 12 12:38:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20392 for ; Wed, 12 Jan 2000 12:38:42 -0500 (EST) 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 ; 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 ; 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 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: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0A77A06B5D4725489E3ED6FF" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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 > 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-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjE3MTUyNFowIwYJKoZIhvcNAQkEMRYEFO8o 4QTMnqV49USr67mKToTAb0hiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAOzxHWg3tdFGBiB1SbXNKOH1rpTNyfCtVXXqGuWKezZyg52JCpeNMd3X9 RxQaS+TBbyog8bVgM9+J/X08/gAVM7hMmQPZk55YLvQvIWgajWtrlzR6kcWfhDrnOSswn/fF 5PAU5lkQMQFA+LRGUNgLJ3oWSF8/Axgz7nNrgJfD1M8= --------------ms0A77A06B5D4725489E3ED6FF-- From owner-ietf-calendar@imc.org Wed Jan 12 13:17:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21127 for ; Wed, 12 Jan 2000 13:17:34 -0500 (EST) 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 ; 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 ; 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 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: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms9BF6CBE00E24D951F7553CBD" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjE3NDUzNVowIwYJKoZIhvcNAQkEMRYEFNkP LH5lKEU5ZYPdxIuHcENd4aIOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAFUF2wY+AxwUibzR5G4JuPdIp+/gV7VriztY7XhNFzfrXEh3dwGG+5ZQF JbzQ8c2idMVpgp8e2uuqhQuHcHIt+Gh9UqRuxfCQTVqg8TwsF3Fcr54L7FvFkekyUfn45Wom N6yBUs4rLktf32FqNkGYOMBBgy5C9RtkuNmzRt47Mn4= --------------ms9BF6CBE00E24D951F7553CBD-- From owner-ietf-calendar@imc.org Thu Jan 13 10:26:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19793 for ; Thu, 13 Jan 2000 10:26:23 -0500 (EST) 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 ; 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 ; 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 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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Thu Jan 13 15:29:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24794 for ; Thu, 13 Jan 2000 15:29:58 -0500 (EST) 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 ; 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 Organization: Software.com X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Overell CC: ietf-calendar@imc.org Subject: (I-3)Re: iMIP, RFC2447 and [RFC-1847]-compliant encryption References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF3AF3FC6D5125697B64C367A" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMzE5NTU0MFowIwYJKoZIhvcNAQkEMRYEFLlX NlepqIYIheNfYOlr9ACNBeoUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAxg3GuE8/hqaBb7AQXmdG5s/yrIGx2gkR7it/WG89GgFO59YZ7SpH/kbQ JBfg5wIfZEd1Vd1YHM4xdGE0tOpnY3XSbONexXInpmOynl3r85vYB9UmErsS0Nn00nAjvDd+ mU9QA+tdoyG/qryVYhZqtKZhnOxmSy5gjmVCQhDESdc= --------------msF3AF3FC6D5125697B64C367A-- From owner-ietf-calendar@imc.org Thu Jan 13 15:30:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24820 for ; Thu, 13 Jan 2000 15:30:50 -0500 (EST) 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 ; 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 ; 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 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: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBDBC56C37F16D27350B98A35" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMzIwMDY1MlowIwYJKoZIhvcNAQkEMRYEFBnk AAVNAMdypWa7/gCSS8oxof/KMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAUApzboRLR+9y7KdxPn/mc2VDZZ6kKKRRPTWUYeceVaSdaGRJjkI1LlrI ztwtrndwowl67Dz2m4zyGoR9XOH04qprsOZO/bl2McaW3/BdkDme05kZvvmx32UGPcEYEeGy r4c8kw/VH5leCDS8KXSLNBz/4HhxCHprwmQi+tad0X4= --------------msBDBC56C37F16D27350B98A35-- From owner-ietf-calendar@imc.org Thu Jan 13 16:39:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25505 for ; Thu, 13 Jan 2000 16:39:51 -0500 (EST) 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 ; 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 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: List-ID: List-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 > > . > and others show just: > #.#.# text CRLF > > So either the 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-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMzIwMjg0OFowIwYJKoZIhvcNAQkEMRYEFG4h ll1SoYhkBoJGWUpQwMzfz+SDMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGATBfwFc5/wW2Pfv6fXuWCr0P5lmP+io8DozX6SDmlwGocvxYVKFCISuSH BWAX8fazndkv8AwqhKQK51MsLuVbIetJiJsgXkkWpqwjckbOJ1xP/xt9mGG5Jx5atNbp6zhh SwedDLtZvKvdbvUs8brzkoWo+MU/HQjSL0VKZvNdJ8o= --------------ms68942174B153F891C24CEDC4-- From owner-ietf-calendar@imc.org Thu Jan 13 18:17:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26203 for ; Thu, 13 Jan 2000 18:17:34 -0500 (EST) 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 ; 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 ; Thu, 13 Jan 2000 14:56:14 -0800 Message-ID: <9BE3A7FF0D67C341819FCA57736D5BC59D0674@dino.platinum.corp.microsoft.com> From: Naveen Kachroo To: ietf-calendar@imc.org Cc: "'Frank_Dawson@lotus.com'" , "'Steve Mansour'" 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: List-ID: List-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 Netscape Meeting Responses

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-- From owner-ietf-calendar@imc.org Thu Jan 13 18:18:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26215 for ; Thu, 13 Jan 2000 18:18:24 -0500 (EST) 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 ; 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 Subject: Re: Issues with CAP "transport" protocol In-reply-to: <387E357F.F2C0732D@Software.com> To: Doug Royer , 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Thursday, January 13, 2000 12:28 -0800 Doug Royer 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: S: C: S: The profile of SASL in CAP doesn't include a way to include final with the , thus forcing and extra round trip: C: S: C: S: C: S: 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@imc.org Fri Jan 14 05:59:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14232 for ; Fri, 14 Jan 2000 05:59:04 -0500 (EST) 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 ; 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: Date: Fri, 14 Jan 2000 10:16:55 +0000 To: ietf-calendar@imc.org From: Paul Overell Subject: Re: iMIP, RFC2447 and [RFC-1847]-compliant encryption References: <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 Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In article <387E2DBB.6FE6D426@Software.com>, Doug Royer 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@imc.org Fri Jan 14 10:28:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18332 for ; Fri, 14 Jan 2000 10:28:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA29257 for ietf-calendar-bks; Fri, 14 Jan 2000 06:21:34 -0800 (PST) Received: from cybergateway.net ([206.104.28.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29253; Fri, 14 Jan 2000 06:21:32 -0800 (PST) From: becky2421@aol.com Received: from 206.104.28.14 [152.172.118.203] by cybergateway.net (SMTPD32-5.01) id A4879CD01FE; Fri, 14 Jan 2000 08:55:35 +0100 Received: from jason@gulfcoast.net by jason@gulfcoast.net (8.8.5/8.6.5) with SMTP id GAA07984 for < jason@gulfcoast.net>; Fri, 14 Jan 2000 07:38:29 -0600 (EST) Date: Fri, 14 Jan 00 07:38:29 EST To: jason@gulfcoast.net Subject: New USA and International Merchant Accounts Message-ID: <> Reply-To: jason@gulfcoast.net Comments: Authenticated sender is < jason@gulfcoast.net> Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD. Click below to Apply http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D ARE YOU REALLY AN E-COMMERCE MERCHANT? Increase your revenues by up to 1500% by accepting credit cards and electronic checks. Increase your customer base 200- 400% with instant access to the World. ARE YOU PAYING TOO MUCH? Discount rates start at 2.1% Transaction fees start at 25 cents. DO YOU WAIT TOO LONG FOR YOUR MONEY? Funds available in 24-48 hours anywhere in the world DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS 99% of all applications are approved. ARE YOU LIMITED BY WHAT YOU CAN ACCEPT? Mastercard, Visa, Discover, Amex and Checks (USA checks only) All cards from ALL COUNTRIES - Including Eastern Europe and Asia - - - - - - - - - - - Click HERE to APPLY. http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D - NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A MERCHANT ACCOUNT. - - - - - - - - - - - To be removed from our mailing list, call (888) 341-4786 Clearly spell your email address and you will be removed. 111 1 111 T From owner-ietf-calendar@imc.org Fri Jan 14 11:52:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19850 for ; Fri, 14 Jan 2000 11:52:40 -0500 (EST) 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 ; 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 ; 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 ; Fri, 14 Jan 2000 11:14:06 -0500 Message-ID: From: Antony Davies To: "'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: List-ID: List-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@imc.org Fri Jan 14 14:18:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21460 for ; Fri, 14 Jan 2000 14:18:19 -0500 (EST) 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 ; 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 ; 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 ; 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 ; 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 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: <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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Fri Jan 14 14:21:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21486 for ; Fri, 14 Jan 2000 14:21:36 -0500 (EST) 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 ; 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: 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: List-ID: List-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"
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_=-- ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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@imc.org Fri Jan 14 14:39:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21656 for ; Fri, 14 Jan 2000 14:39:18 -0500 (EST) 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 ; 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 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: quoted printable in DESCRIPTION References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7877181505DCEE838D8575A8" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTE0MTkwMTQ2WjAjBgkqhkiG9w0BCQQxFgQUfQze4+4h OoDlX6cX8+HRt3YBVEwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYB5O9ZEUxYA3zC2mAGg4aWAgHmT2dwC6V1Ga5FmqmTpFPoVO9Ag1El55ShO81AU o7qqf5axuvtMYIksqzRTYePrlrWQGElsAVMVPgf/I6deUHkJmHKZo/ydeLNc5LGJ1QHxQatD abVWUzz+35Ur1FFHzWdLBxtdJ8yrqBSEeYZS5Q== --------------ms7877181505DCEE838D8575A8-- From owner-ietf-calendar@imc.org Fri Jan 14 16:03:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22367 for ; Fri, 14 Jan 2000 16:03:15 -0500 (EST) 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 ; 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 ; 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 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: <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: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTE0MjAzNTI1WjAjBgkqhkiG9w0BCQQxFgQUx/FGKcNq YUib9i3KR6fipj8ikekwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYAHe/cJQOxcu0ZwpVGBCR2x0KRH4wFvxj12UUx/nX55EcoCxHHtejYCFAhXrju4 bNaYSDIyC/J81uiPyYNEcM0Rx1M09NumULhUFkEfc/oLo1MjPtuvNH7lG5etTbjZlVhuqDOs LGGwAr+XmF9Jc6JnBY420ffHMKNcGQWKfIZbkg== --------------msEE6A10B681B9CC4002C81FA7-- From owner-ietf-calendar@imc.org Fri Jan 14 20:54:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24511 for ; Fri, 14 Jan 2000 20:54:39 -0500 (EST) 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 ; Fri, 14 Jan 2000 17:32:54 -0800 (PST) From: pregen@egenconsulting.com To: Paul Overell 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: 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: List-ID: List-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 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 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"
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_=-- From owner-ietf-calendar@imc.org Sun Jan 16 03:26:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02148 for ; Sun, 16 Jan 2000 03:26:27 -0500 (EST) 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 ; 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 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: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled 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? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D 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@imc.org Sun Jan 16 17:40:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11603 for ; Sun, 16 Jan 2000 17:40:55 -0500 (EST) 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: List-ID: List-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@imc.org Mon Jan 17 12:03:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04103 for ; Mon, 17 Jan 2000 12:03:56 -0500 (EST) 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 ; 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 ; 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 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: <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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Tue Jan 18 04:47:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27288 for ; Tue, 18 Jan 2000 04:47:04 -0500 (EST) 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 ; 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" To: "Michael Krivoruchko" , Cc: Subject: SV: XML DTD update proposition Date: Tue, 18 Jan 2000 10:15:52 +0100 Message-ID: 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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@imc.org Tue Jan 18 15:29:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05441 for ; Tue, 18 Jan 2000 15:29:40 -0500 (EST) 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 ; 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 ; 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 ; 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" 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: List-ID: List-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: Map highlighting the location of Building E40 (aka 1 Amherst Street): Paul From owner-ietf-calendar@imc.org Tue Jan 18 23:31:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11469 for ; Tue, 18 Jan 2000 23:31:24 -0500 (EST) 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 ; 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 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: List-ID: List-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-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKVQYJKoZIhvcNAQcCoIIKRjCCCkICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggH7MIIB9wIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDExOTAzNTQxNVowIwYJKoZIhvcNAQkEMRYEFAc338ePNFVLmq507O9lDMBJ0sdD MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABEDP/W6KfT64 WhdZxhISBiG5PdiFAI+WOwXVEAMFI8M2cgN2yOBl80XPbzks4HJSIzWviXFhygcDGUnyV/3w ekzd --------------msB60E84D0C53241CB068D81C5-- From owner-ietf-calendar@imc.org Thu Jan 20 14:53:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13661 for ; Thu, 20 Jan 2000 14:53:42 -0500 (EST) 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 ; 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 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: List-ID: List-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 From owner-ietf-calendar@imc.org Fri Jan 21 18:51:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19070 for ; Fri, 21 Jan 2000 18:51:06 -0500 (EST) 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 ; 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 ; 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 ; 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 ; 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 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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? > 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@imc.org Sat Jan 22 15:11:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10742 for ; Sat, 22 Jan 2000 15:11:32 -0500 (EST) 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 ; 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 Cc: ietf-calendar@imc.org Subject: Re: quoted printable in DESCRIPTION X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Sun Jan 23 03:30:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02476 for ; Sun, 23 Jan 2000 03:30:09 -0500 (EST) 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 ; 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 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: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled 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? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D 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@imc.org Sun Jan 23 15:04:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11383 for ; Sun, 23 Jan 2000 15:04:59 -0500 (EST) 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 ; 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 ; 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 , Chris Newman 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Sun Jan 23 15:55:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11609 for ; Sun, 23 Jan 2000 15:55:02 -0500 (EST) 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 ; 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 Subject: Re: CAP Transfer Protocol "debug text" In-reply-to: <388B5973.67345ADA@netscape.com> To: Steve Mansour , CalSched IETF 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Sunday, January 23, 2000 11:41 -0800 Steve Mansour 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@imc.org Sun Jan 23 16:01:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11644 for ; Sun, 23 Jan 2000 16:01:01 -0500 (EST) 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Sun Jan 23 17:13:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11979 for ; Sun, 23 Jan 2000 17:13:34 -0500 (EST) 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 ; 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 ; 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 ; 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 Subject: NOOP command - your feedback needed Content-Type: multipart/alternative; boundary="------------CD6B9C6C1E8E765D44E66CCC" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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 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-- From owner-ietf-calendar@imc.org Sun Jan 23 17:36:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12076 for ; Sun, 23 Jan 2000 17:36:38 -0500 (EST) 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Sun Jan 23 18:00:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12163 for ; Sun, 23 Jan 2000 18:00:07 -0500 (EST) 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: Content-Type: multipart/alternative; boundary="------------065083E0CE5495855B9D211D" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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  
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-- From owner-ietf-calendar@imc.org Sun Jan 23 18:13:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12253 for ; Sun, 23 Jan 2000 18:13:48 -0500 (EST) 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 ; 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 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 CC: CalSched IETF 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Sun Jan 23 18:16:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12267 for ; Sun, 23 Jan 2000 18:16:03 -0500 (EST) 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 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 , ietf-calendar@imc.org, owner-ietf-calendar@imc.org Subject: Re: NOOP command - your feedback needed References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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? 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@imc.org Sun Jan 23 18:33:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12447 for ; Sun, 23 Jan 2000 18:33:35 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Sun Jan 23 22:05:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14489 for ; Sun, 23 Jan 2000 22:05:24 -0500 (EST) 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Sun Jan 23 22:20:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14525 for ; Sun, 23 Jan 2000 22:20:30 -0500 (EST) 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 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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Mon Jan 24 15:04:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22308 for ; Mon, 24 Jan 2000 15:04:12 -0500 (EST) 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 ; 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Mon Jan 24 15:33:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23768 for ; Mon, 24 Jan 2000 15:33:49 -0500 (EST) 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 ; 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 ; 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: Content-Type: multipart/alternative; boundary="------------E5DC99F4FE03FBFB5C89033F" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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: [; debug text ; more text] . [] . 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 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-- From owner-ietf-calendar@imc.org Mon Jan 24 16:34:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25555 for ; Mon, 24 Jan 2000 16:34:39 -0500 (EST) 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 ; 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 Reply-To: CalSched IETF 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 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: List-ID: List-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-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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@imc.org Tue Jan 25 19:02:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10406 for ; Tue, 25 Jan 2000 19:02:40 -0500 (EST) 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 ; 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 ; 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 ; Tue, 25 Jan 2000 18:23:22 -0500 (EST) Mime-Version: 1.0 X-Sender: bobmah@po12.mit.edu Message-Id: Date: Tue, 25 Jan 2000 18:22:52 -0500 To: ietf-calendar@imc.org From: Bob Mahoney 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: List-ID: List-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@imc.org Tue Jan 25 23:21:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15896 for ; Tue, 25 Jan 2000 23:21:16 -0500 (EST) 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 ; 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 ; 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 CC: ietf-calendar@imc.org Subject: Re: W-19 CAP Group Definitions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 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@imc.org Wed Jan 26 01:05:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17232 for ; Wed, 26 Jan 2000 01:05:31 -0500 (EST) 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 ; 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 ; 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 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: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4F97B25992596A6653B13EC7" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI2MDUyMDAwWjAjBgkqhkiG9w0BCQQxFgQUg+87Yqe2 zYXYpLxXMz5SfjBwMCwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYBdpkYqQQCif+bkSKeqdCpJG8UsDLwvLMh5ocJqusSucDvBPact9wJSJvqev/cH aQJBLI6ZiYjVKWDCmmFqU6k0vXrWhMy1lQ5uFfb+7n/dK7QFPe1v3WtEhlNyVxb+v5U1wD1F yH5TFwqb/aDnZjHeNNf+uIAtUWO8rLLJi/yL8Q== --------------ms4F97B25992596A6653B13EC7-- From owner-ietf-calendar@imc.org Wed Jan 26 11:16:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06136 for ; Wed, 26 Jan 2000 11:16:34 -0500 (EST) 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 ; Wed, 26 Jan 2000 07:40:10 -0800 (PST) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: Bob Mahoney 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: 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: List-ID: List-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"
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_=-- ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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@imc.org Wed Jan 26 12:10:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06879 for ; Wed, 26 Jan 2000 12:10:16 -0500 (EST) 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 ; 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 ; 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 ; Wed, 26 Jan 2000 11:39:25 -0500 (EST) Mime-Version: 1.0 X-Sender: bobmah@po12.mit.edu Message-Id: In-Reply-To: References: Date: Wed, 26 Jan 2000 11:39:02 -0500 To: ietf-calendar@imc.org From: Bob Mahoney 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: List-ID: List-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@imc.org Wed Jan 26 13:07:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08146 for ; Wed, 26 Jan 2000 13:07:19 -0500 (EST) 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 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Wed Jan 26 13:12:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08240 for ; Wed, 26 Jan 2000 13:12:10 -0500 (EST) 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 ; 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 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 CC: ietf-calendar@imc.org Subject: Re: W-19 CAP Group Definitions References: Content-Type: multipart/mixed; boundary="------------35B72F04EF5009DB7BD5B8CB" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------35B72F04EF5009DB7BD5B8CB-- From owner-ietf-calendar@imc.org Wed Jan 26 14:12:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09682 for ; Wed, 26 Jan 2000 14:12:57 -0500 (EST) 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 ; 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: In-Reply-To: <388F33E2.99FF0F43@home.royer.com> References: <388F33E2.99FF0F43@home.royer.com> Date: Wed, 26 Jan 2000 13:22:02 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Re: W-19 CAP Group Definitions Cc: Bob Mahoney , ietf-calendar@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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@imc.org Wed Jan 26 14:55:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10495 for ; Wed, 26 Jan 2000 14:55:54 -0500 (EST) 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 ; 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 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 CC: ietf-calendar@imc.org Subject: Re: W-19 CAP Group Definitions References: <388F33E2.99FF0F43@home.royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms47F9AEE196BDB21C66903652" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI2MTkzMjUzWjAjBgkqhkiG9w0BCQQxFgQU1a9FDyj9 JtkwIYpsq7qaH/9RD0swUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYBsd2O7Uoyky4IMagYSzIOWYi7TsWR7Sb7xs/61JQnhgkQWR5a5TxfqUvqExBci E7KBOl8lumlIShCDOKYXaqX7Gc8QU6Q8UREdtw4jn9JEFyU9eXX7z52QznWe06sEo+BADb6+ CmNXtU9M1UPjuhqTgtKCcGDUKrQxijz4pHchIg== --------------ms47F9AEE196BDB21C66903652-- From owner-ietf-calendar@imc.org Wed Jan 26 15:03:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10705 for ; Wed, 26 Jan 2000 15:03:17 -0500 (EST) 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 ; 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: In-Reply-To: <388F4BE0.30FBEA0B@home.royer.com> References: <388F33E2.99FF0F43@home.royer.com> <388F4BE0.30FBEA0B@home.royer.com> Date: Wed, 26 Jan 2000 14:40:50 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Re: W-19 CAP Group Definitions Cc: Bob Mahoney , ietf-calendar@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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@imc.org Wed Jan 26 15:17:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10866 for ; Wed, 26 Jan 2000 15:17:15 -0500 (EST) 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 ; 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: In-Reply-To: References: Date: Wed, 26 Jan 2000 14:45:09 -0500 To: From: Bob Mahoney 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: List-ID: List-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@imc.org Wed Jan 26 16:17:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11582 for ; Wed, 26 Jan 2000 16:17:34 -0500 (EST) 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 ; 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 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 , ietf-calendar@imc.org Subject: Re: W-19 CAP Group Definitions References: <388F33E2.99FF0F43@home.royer.com> <388F4BE0.30FBEA0B@home.royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB2150ACBD492FFD6D9F66B75" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-. 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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI2MjA0MDQ5WjAjBgkqhkiG9w0BCQQxFgQUOA/ffiZy Y38Y+wxeUfn3/8W3Og0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYAQXS4/p+xMyaJvgFpCrObFrQ4l/7ErZLYmEEH/XnIU7q8z1DhtbWHsHFAZSIjO SPJRKr4aIOnMMySS34Rr5k2DTRow19w9m/Nen7p8pZpuruVow+dpaGZ6Tcowv7xsC2CpIOcV b1aAj4rSRNMuGozzy4VFryBYIpZkQiWPor9v7w== --------------msB2150ACBD492FFD6D9F66B75-- From owner-ietf-calendar@imc.org Wed Jan 26 16:27:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11719 for ; Wed, 26 Jan 2000 16:27:31 -0500 (EST) 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 ; 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 ; 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 ; Wed, 26 Jan 2000 15:48:51 -0500 (EST) Mime-Version: 1.0 X-Sender: bobmah@po12.mit.edu Message-Id: Date: Wed, 26 Jan 2000 15:48:26 -0500 To: ietf-calendar@imc.org From: Bob Mahoney 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: List-ID: List-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) 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@imc.org Wed Jan 26 16:32:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11820 for ; Wed, 26 Jan 2000 16:32:25 -0500 (EST) 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 ; 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 ; 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 ; 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" 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: List-ID: List-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@imc.org Wed Jan 26 16:44:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12141 for ; Wed, 26 Jan 2000 16:44:17 -0500 (EST) 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 ; 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: In-Reply-To: <388F5BCF.CBB94BA2@home.royer.com> References: <388F33E2.99FF0F43@home.royer.com> <388F4BE0.30FBEA0B@home.royer.com> <388F5BCF.CBB94BA2@home.royer.com> Date: Wed, 26 Jan 2000 15:56:37 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Re: W-19 CAP Group Definitions Cc: Bob Mahoney , ietf-calendar@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-. > >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@imc.org Wed Jan 26 17:36:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12790 for ; Wed, 26 Jan 2000 17:36:57 -0500 (EST) 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 ; 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 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 , ietf-calendar@imc.org Subject: Re: W-19 CAP Group Definitions References: <388F33E2.99FF0F43@home.royer.com> <388F4BE0.30FBEA0B@home.royer.com> <388F5BCF.CBB94BA2@home.royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD3A30C1A961B81E85D65E2F9" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI2MjIxMjQ4WjAjBgkqhkiG9w0BCQQxFgQURe7rvXJY /1KK77tPVWyztrqO7JMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYBJS8bjo+lQChvxe8HzVxx90dC4PW1S/lVQEmGoYSIkqcPDGe2PFdIMjPIapocE 3qYwH9CJ7ijN3s1lGqlGi2Cu9Hs6uel6Dz/Vrf6QWPXoCtiyKBJDEOJ6Ib6UgTyMdXDXsT0K dDzrPrF3qIKcbwDlgyyOwwxqnxgPiNg/93c3Kg== --------------msD3A30C1A961B81E85D65E2F9-- From owner-ietf-calendar@imc.org Thu Jan 27 11:42:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09396 for ; Thu, 27 Jan 2000 11:42:45 -0500 (EST) 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 ; 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 ; 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 ; 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" 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: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit 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@imc.org Thu Jan 27 11:47:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09471 for ; Thu, 27 Jan 2000 11:47:08 -0500 (EST) 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 ; Thu, 27 Jan 2000 08:18:52 -0800 (PST) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: Bob Mahoney 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: 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: List-ID: List-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"
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_=-- ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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@imc.org Thu Jan 27 12:33:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10352 for ; Thu, 27 Jan 2000 12:33:54 -0500 (EST) 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 ; 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: In-Reply-To: References: Date: Thu, 27 Jan 2000 11:55:54 -0500 To: From: Bob Mahoney Subject: Re: W-19 CAP Group Definitions Cc: Bob Mahoney , 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: List-ID: List-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@imc.org Thu Jan 27 13:38:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11653 for ; Thu, 27 Jan 2000 13:38:09 -0500 (EST) 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 ; 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 ; 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 ; 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" 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: List-ID: List-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@imc.org Thu Jan 27 13:42:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11744 for ; Thu, 27 Jan 2000 13:42:34 -0500 (EST) 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 ; 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 ; 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 ; 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" 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: List-ID: List-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@imc.org Thu Jan 27 13:49:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11893 for ; Thu, 27 Jan 2000 13:49:49 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-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; DENY:UPN=IDoNotLikeYou@example.com; DENY:UPN...; ... END:VCAR and might be different than: BEGIN:VCAR DENY:UPN=IDoNotLikeYou@example.com; DENY:UPN...;rule-set-Alpha> ... GRANT:UPN=all; 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; GRANT:UPN=IDoNotLikeYou@example.com; GRANT:UPN...; ... END:VCAR -Doug --------------82BB45D396EC2AAC5EDC5F4D Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------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 Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI3MTgxMzMzWjAjBgkqhkiG9w0BCQQxFgQUF4gn/veC D2GBcOyMXvD3HTFOdTcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYC7/XSqPLQOZlCkafUS9b5V9hpbmWkl4d58mULCvmBCP3zHAa6P43dlaArltMIs DIuCrQOWc8C1oqmVlMMVq3NUUzkGePIGjDWFfkfUhBv4ZsEXl1dZmGsKEoVKUInWCRQzXmGE dvLeIRpxezwq8ZT8ArRHVCo8RgQj0/5HeHFQrw== --------------ms924A9EAB3D5FD16C929E664E-- From owner-ietf-calendar@imc.org Thu Jan 27 13:53:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11939 for ; Thu, 27 Jan 2000 13:53:47 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------D3E90BF4B7B3255E9473A061-- From owner-ietf-calendar@imc.org Thu Jan 27 14:23:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12554 for ; Thu, 27 Jan 2000 14:23:06 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-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=;POLICY=READBUSYTIMEINFO END:VCAR (1) Specify the rights for reading VFREEBUSY components? As in: BEGIN:VCAR CARID:READBUSYTIMEINFO GRANT:UPN=;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=;OBJECT=DTSTART,DTEND,DURATION;ACTION=READ END:VCAR (3) Or do you mean both? As in: BEGIN:VCAR CARID:READBUSYTIMEINFO  GRANT:UPN=: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=;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=;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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------BA8E2EF3C4CD16F4B373BB18-- From owner-ietf-calendar@imc.org Thu Jan 27 14:26:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12606 for ; Thu, 27 Jan 2000 14:26:16 -0500 (EST) 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 ; 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 ; 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" 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: List-ID: List-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@imc.org Thu Jan 27 14:36:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13038 for ; Thu, 27 Jan 2000 14:36:53 -0500 (EST) 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Thu Jan 27 14:37:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13049 for ; Thu, 27 Jan 2000 14:37:06 -0500 (EST) 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" 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Thu Jan 27 14:37:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13062 for ; Thu, 27 Jan 2000 14:37:44 -0500 (EST) 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" 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: 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: List-ID: List-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"
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_=-- From owner-ietf-calendar@imc.org Thu Jan 27 14:48:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13270 for ; Thu, 27 Jan 2000 14:48:30 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------A7DC998C1AE7F3DC253911C2-- From owner-ietf-calendar@imc.org Thu Jan 27 15:32:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14177 for ; Thu, 27 Jan 2000 15:32:55 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------C949CEA0C7036599635D70AB-- From owner-ietf-calendar@imc.org Thu Jan 27 15:34:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14226 for ; Thu, 27 Jan 2000 15:34:39 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------0AC8EB67BC3D080B5545FD80-- From owner-ietf-calendar@imc.org Thu Jan 27 15:54:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14634 for ; Thu, 27 Jan 2000 15:54:23 -0500 (EST) 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 ; 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" Subject: Re: forced VCAR (was: revised security section) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-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@imc.org Thu Jan 27 15:56:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14663 for ; Thu, 27 Jan 2000 15:56:17 -0500 (EST) 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 ; 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 ; 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" 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: List-ID: List-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@imc.org Thu Jan 27 16:02:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14795 for ; Thu, 27 Jan 2000 16:02:19 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------F5AF1E7BEE9C261609670E00-- From owner-ietf-calendar@imc.org Thu Jan 27 16:04:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14845 for ; Thu, 27 Jan 2000 16:04:10 -0500 (EST) 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 ; 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 ; 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 ; 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" 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: List-ID: List-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@imc.org Thu Jan 27 16:08:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14885 for ; Thu, 27 Jan 2000 16:08:44 -0500 (EST) 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 ; 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 ; 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 ; 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" 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: List-ID: List-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@imc.org Thu Jan 27 16:57:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15547 for ; Thu, 27 Jan 2000 16:57:10 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-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-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------EF88001D5B158BC38007683A-- From owner-ietf-calendar@imc.org Thu Jan 27 21:20:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17867 for ; Thu, 27 Jan 2000 21:20:12 -0500 (EST) 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 ; 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 ; 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 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: List-ID: List-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 rights for creating new event invitations, to-do assignments and journal entries. As we are going to have to define what this means, then we can simply define in in terms of a VCAR and eliminate this as a POLICY. It could be (assuming I understand what the intent was): BEGIN:VCAR CARID:REQUESTONLY GRANT:UPN=<...>;OBJECT=ALL;ACTION=CREATE; END:VCAR (3) 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. As we are going to have to define what this means, then we can simply define in in terms of a VCAR and eliminate this as a POLICY. Perhaps: BEGIN:VCAR CARID:ACTONBEHALFOF GRANT:UPN=<...> ;OBJECT=ORGANIZER;VALUE= ;OBJECT=SENT-BY;VALUE=SELF ;OBJECT=CLASS;VALUE=PUBLIC,PRIVATE ;ACTION=ALL END:VCAR ++In addition, 'self' probably would have to have CREATE, MODIFY, DELETE, permission in the target calendar. (4) UPDATEPARTSTATUS - Specifies rights for modifying ones own participation status. Perhaps: BEGIN:VCAR CARID:UPDATESTATUS GRANT:UPN=<...> ;OBJECT=PARTSTAT;VALUE=ALL ;OBJECT=ATTENDEE;VALUE=SELF ;ACTION=MODIFY END:VCAR (5) OWNER - Specifies the same rights given to the owner of the calendar store or calendar. Make them an OWNER by adding their OWNER property to the calendar properly list. And then: BEGIN:VCAR CARID:OWNER GRANT:UPN=OWNER;OBJECT=ALL;VALUE=ALL;ACTION=ALL END:VCAR (6) CAPABILITY reply. In the current CAP draft in the ABNF it has CAR0, CAR1, CAR2, and CAR3. This needs to be changed to CAR-MIN, and CAR-FULL-1 Define CAR-MIN as the above definitions (Or what ever tweaks the WG makes to the above definitions). If CAR-MIN is returned by CAPABILITY, then ONLY the ones defined above are supported. They can be hard coded into a CS (plus storage for which UPNs they apply to), or parsed. Ether way I think this would solve both problems (thin CS's and a complete IF supported VCAR). If CAR-FULL-1 is returned by CAPABILITY, then all of the VCAR support MUST be supported. Only one of CAR-MIN or CAR-FULL-1 can be returned by CAPABILITY. --------------37C9DFF6386FCE28DBB395CB Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------37C9DFF6386FCE28DBB395CB-- --------------msBB6F460385A37E01AC0BB6BB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTI4MDE1NDU2WjAjBgkqhkiG9w0BCQQxFgQUFV0dmcZP 8YwIC0JqN9I1ahgCzokwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYAUU5Le89AR0cDgFouFbDx/7qIcYNUJ+fABuD+BzR083VuMIeRg697Wk/kIBoXI VgKdG6Y0jslOffWYoTaIvtDHMjLyWtt2J/by91ELL+1eIxHs74+ymMIJCmNQwaU2eHJ49G3U 0W7uGC2xC/9IMDZk1YzKXuff+In8UbLIqd4qfA== --------------msBB6F460385A37E01AC0BB6BB-- From owner-ietf-calendar@imc.org Thu Jan 27 23:16:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20446 for ; Thu, 27 Jan 2000 23:16:06 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA13249 for ietf-calendar-bks; Thu, 27 Jan 2000 19:35:01 -0800 (PST) Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13245 for ; Thu, 27 Jan 2000 19:35:00 -0800 (PST) Received: from carey ([24.28.82.14]) by mail.austin.rr.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 27 Jan 2000 21:37:21 -0600 Reply-To: From: "Carey Jung" To: Subject: Reference icalendar server implementations Date: Thu, 27 Jan 2000 21:38:52 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01BF690E.E766DD00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_005B_01BF690E.E766DD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, Please forgive a somewhat off-topic note from a lurker, but could somebody please fill me in on the current state of Internet-based calendar server implementations? Are there reference implementations out there, perhaps even open-source? I ask, because I know that MS Outlook has support for icalendar servers, but I've not found any such server products or implementations myself. thanks in advance, Carey Jung ---------------------------------------------------------------------------- ---- Carey Jung IT Freedom carey@itfreedom.com 512.502.1171, fax 349.2165 ------=_NextPart_000_005B_01BF690E.E766DD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi=20 all,
 
Please = forgive a=20 somewhat off-topic note from a lurker, but could somebody please fill me = in on=20 the current state of Internet-based calendar server = implementations?  Are=20 there reference implementations out there, perhaps even = open-source?  I=20 ask, because I know that MS Outlook has support for icalendar servers, = but I've=20 not found any such server products or implementations=20 myself.
 
thanks = in=20 advance,
Carey=20 Jung
 
Carey=20 Jung
IT Freedom
carey@itfreedom.com
512.502.1171, fax = 349.2165
 
------=_NextPart_000_005B_01BF690E.E766DD00-- From owner-ietf-calendar@imc.org Fri Jan 28 01:48:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24643 for ; Fri, 28 Jan 2000 01:48:55 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA23043 for ietf-calendar-bks; Thu, 27 Jan 2000 22:21:45 -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 WAA23037 for ; Thu, 27 Jan 2000 22:21:43 -0800 (PST) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id BAA01924; Fri, 28 Jan 2000 01:23:37 -0500 (EST) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9490406121.001094; Fri, 28 Jan 00 01:23:32 -0500 Received: by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id BAA01088; Fri, 28 Jan 2000 01:23:32 -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.9490406061.000971; Fri, 28 Jan 00 01:23:26 -0500 Received: from msdw.com (hqdsl26.morgan.com [205.228.1.26]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id BAA17263; Fri, 28 Jan 2000 01:23:26 -0500 (EST) Message-ID: <389135DF.EA6240CC@msdw.com> Date: Fri, 28 Jan 2000 01:23:27 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: "Paul B. Hill" CC: ietf-calendar@imc.org Subject: Re: further suggestion for section 2.4.2.1 References: <4.2.0.58.20000127121344.01a48e90@po12.mit.edu> Content-Type: multipart/mixed; boundary="------------6DEC372A6327FB86DD572898" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6DEC372A6327FB86DD572898 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > 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. Minor nit. Remove "could" from the previous sentance. Or insert the rest of it eg: "could be a security issue and MUST" A more serious point is that I believe it's inappropriate to describe "@example.com" in the "anonymous" section. "@example.com" is not anonymous access. It's "any authenticated user in example.com". An anonymous UPN is "@". Unless you actually authenticate the user, it's not possible for the server to determine if the user really is from "@example.com". dmadeo --------------6DEC372A6327FB86DD572898 Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;fax:212-762-1009 tel;work:212-762-2348 x-mozilla-html:FALSE url:www.ms.com org:Morgan Stanley Dean Witter and Discover;Information Technology version:2.1 email;internet:dmadeo@ms.com adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA x-mozilla-cpt:;0 fn:David Madeo end:vcard --------------6DEC372A6327FB86DD572898-- From owner-ietf-calendar@imc.org Fri Jan 28 02:07:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02363 for ; Fri, 28 Jan 2000 02:07:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA24864 for ietf-calendar-bks; Thu, 27 Jan 2000 22:36:44 -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 WAA24858 for ; Thu, 27 Jan 2000 22:36:42 -0800 (PST) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/fw v1.30) id BAA20682 for ; Fri, 28 Jan 2000 01:38:36 -0500 (EST) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9490414901.019261; Fri, 28 Jan 00 01:38:10 -0500 Received: by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id BAA19239 for ; Fri, 28 Jan 2000 01:38:10 -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.9490414801.018324; Fri, 28 Jan 00 01:38:00 -0500 Received: from msdw.com (hqdsl26.morgan.com [205.228.1.26]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id BAA19055 for ; Fri, 28 Jan 2000 01:38:00 -0500 (EST) Message-ID: <38913948.B9E39FF5@msdw.com> Date: Fri, 28 Jan 2000 01:38:00 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Thanks for hosting us. Content-Type: multipart/mixed; boundary="------------150C423A20BAFD6165C19787" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------150C423A20BAFD6165C19787 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think it's appropriate to thank Paul and Bob from MIT for hosting this climatically challenged session. As predicted, it was cold, but I don't think anyone expected the amount of snow that Frank was buried under down in NC. In any case, it was productive for those who attended (Paul, Bob, Rich Shusterman, Mike Ciavarini and I) as evidenced by the recent traffic on the list. Please help to continue this burst of activity by actively asking questions, suggesting solutions, and most importantly, submitting proposed text. As someone reminded us during our visit, the final product is the document, not the conversations leading to it. Thanks, dmadeo --------------150C423A20BAFD6165C19787 Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;fax:212-762-1009 tel;work:212-762-2348 x-mozilla-html:FALSE url:www.ms.com org:Morgan Stanley Dean Witter and Discover;Information Technology version:2.1 email;internet:dmadeo@ms.com adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA x-mozilla-cpt:;0 fn:David Madeo end:vcard --------------150C423A20BAFD6165C19787-- From owner-ietf-calendar@imc.org Fri Jan 28 02:17:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03241 for ; Fri, 28 Jan 2000 02:17:43 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA26364 for ietf-calendar-bks; Thu, 27 Jan 2000 22:53:12 -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 WAA26357 for ; Thu, 27 Jan 2000 22:53:10 -0800 (PST) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id BAA25012 for ; Fri, 28 Jan 2000 01:55:04 -0500 (EST) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9490424871.024372; Fri, 28 Jan 00 01:54:47 -0500 Received: by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id BAA24362 for ; Fri, 28 Jan 2000 01:54:47 -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.9490424791.023876; Fri, 28 Jan 00 01:54:39 -0500 Received: from msdw.com (hqdsl26.morgan.com [205.228.1.26]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id BAA20803 for ; Fri, 28 Jan 2000 01:54:38 -0500 (EST) Message-ID: <38913D2E.B17C2C04@msdw.com> Date: Fri, 28 Jan 2000 01:54:38 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: ACTONBEHALFOF (was: revised security section) References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu> <3890A496.89ACBD02@home.royer.com> Content-Type: multipart/mixed; boundary="------------47A0B48129BF7BF7FDC4C5C8" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------47A0B48129BF7BF7FDC4C5C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > > - 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? The general problem we're trying to solve here is how do I let my secretary or P/A modify my calendar. One way is to grant permissions such as above. Another is to authenticate via SASL as yourself, but then ask for the UPN of your principal (eg: the boss). If the SASL server is configured properly, you may be allowed use that UPN even though it's not your "own". Each side has it's merits. In the first case, we have to go through and figure out what is meant, however we can be precise. In the second case, as far as the CS is concerned, the boss just logged in and can do whatever they'd like, subject to the BOSS's VCAR's. There's no way to tell which were created by the secretary and which by the owner. For the first case, where we need to make some choices, my experience is that most principals who have secretaries handling their schedules trust them completely at least as far as their calendar is concerned. If they don't, there's no way the principals let them manage their calendar. I'd vote for "can do anything except alter your CAP calendar properties. I'm not too concerned if "CONFIDENTAL" events were outside the purview of the PA or not. dmadeo --------------47A0B48129BF7BF7FDC4C5C8 Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;fax:212-762-1009 tel;work:212-762-2348 x-mozilla-html:FALSE url:www.ms.com org:Morgan Stanley Dean Witter and Discover;Information Technology version:2.1 email;internet:dmadeo@ms.com adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA x-mozilla-cpt:;0 fn:David Madeo end:vcard --------------47A0B48129BF7BF7FDC4C5C8-- From owner-ietf-calendar@imc.org Fri Jan 28 02:33:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04045 for ; Fri, 28 Jan 2000 02:33:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA28294 for ietf-calendar-bks; Thu, 27 Jan 2000 23:08:03 -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 XAA28287 for ; Thu, 27 Jan 2000 23:08:01 -0800 (PST) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/fw v1.30) id CAA24026; Fri, 28 Jan 2000 02:09:54 -0500 (EST) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9490433801.023659; Fri, 28 Jan 00 02:09:40 -0500 Received: by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id CAA23651; Fri, 28 Jan 2000 02:09: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.9490433661.023205; Fri, 28 Jan 00 02:09:26 -0500 Received: from msdw.com (hqdsl26.morgan.com [205.228.1.26]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id CAA22756; Fri, 28 Jan 2000 02:09:26 -0500 (EST) Message-ID: <389140A5.DD45BAEC@msdw.com> Date: Fri, 28 Jan 2000 02:09:25 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: "Paul B. Hill" CC: Frank_Dawson@lotus.com, ietf-calendar@imc.org Subject: Re: forced VCAR (was: revised security section) References: <4.2.0.58.20000127153336.01ab19d0@po12.mit.edu> Content-Type: multipart/mixed; boundary="------------6F351C42A7486A781F94E265" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6F351C42A7486A781F94E265 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Paul B. Hill" wrote: > 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. Richard accused me of asking for the world yesterday, but I'd like to clarify what I was thinking when I proposed this. Assuming Doug can go through and get rid of policies and replace them with "VCAR scenarios often encountered in the real world", I'd like to see the "forced VCAR" be a mandatory addition to every calendars set of VCAR's. Users should be able to (subject to implementation configuration) create additional VCARs that complement but do not remove or override the forced VCAR's. This does not raise the inheritance issue Rich was concerned. The VCAR is stored with the calendar just like everything else. The server just knows that that particular VCAR can't be changed by the end user. --------------6F351C42A7486A781F94E265 Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;fax:212-762-1009 tel;work:212-762-2348 x-mozilla-html:FALSE url:www.ms.com org:Morgan Stanley Dean Witter and Discover;Information Technology version:2.1 email;internet:dmadeo@ms.com adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA x-mozilla-cpt:;0 fn:David Madeo end:vcard --------------6F351C42A7486A781F94E265-- From owner-ietf-calendar@imc.org Fri Jan 28 04:37:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04833 for ; Fri, 28 Jan 2000 04:37:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA09922 for ietf-calendar-bks; Fri, 28 Jan 2000 01:20:09 -0800 (PST) Received: from mumrik.nada.kth.se (mumrik.nada.kth.se [130.237.226.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA09916 for ; Fri, 28 Jan 2000 01:20:07 -0800 (PST) Received: from localhost (d92-pla@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with ESMTP id KAA03997 for ; Fri, 28 Jan 2000 10:21:56 +0100 (MET) Date: Fri, 28 Jan 2000 10:21:56 +0100 (MET) From: =?ISO-8859-1?Q?P=E4r_Lanner=F6?= To: ietf-calendar@imc.org Subject: Re: Reference icalendar server implementations In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8BIT On Thu, 27 Jan 2000, Carey Jung wrote: > Please forgive a somewhat off-topic note from a lurker, but could somebody > please fill me in on the current state of Internet-based calendar server > implementations? Are there reference implementations out there, perhaps > even open-source? I ask, because I know that MS Outlook has support for > icalendar servers, but I've not found any such server products or > implementations myself. There are at least two open source implementations that I know of: * WhenWare Tempus server available at http://www.whenware.com/html/downloads.html * Libical iCalendar library available at http://www.softwarestudio.org/libical/ Are there other similar projects out there? /Pär -Pär-Lannerö---------------------------------------------------------- mailto:par.lannero@metamatrix.se jobb:+46(0)8337785 http://www.metamatrix.se/ hem:+46(0)853039951 icq:306436 gsm:+46(0)708/826888 ---------------------------------------------------------------------- - implementing SKiCal compliant software From owner-ietf-calendar@imc.org Fri Jan 28 11:30:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17824 for ; Fri, 28 Jan 2000 11:29:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA06996 for ietf-calendar-bks; Fri, 28 Jan 2000 08:04:45 -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 IAA06992 for ; Fri, 28 Jan 2000 08:04: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 IAA21061 for ; Fri, 28 Jan 2000 08:06:39 -0800 (PST) Message-ID: <3891BE8E.D365DC28@home.royer.com> Date: Fri, 28 Jan 2000 08:06:38 -0800 From: Doug Royer 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: further suggestion for section 2.4.2.1 References: <4.2.0.58.20000127121344.01a48e90@po12.mit.edu> <389135DF.EA6240CC@msdw.com> Content-Type: multipart/mixed; boundary="------------F76D3D9EEB4E1BE8655269DB" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F76D3D9EEB4E1BE8655269DB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Madeo wrote: > "@example.com" is not anonymous access. It's "any authenticated user in > example.com". An anonymous UPN is "@". Unless you actually authenticate the > user, it's not possible for the server to determine if the user really is from > "@example.com". I did not get that from the email. I understood it to mean any user that happens to come from example.com. PLEASE clarify! It is possible to determine which host (or IP address) a connection is from as soon as the connection is made - prior to any data transfers. So I think the text needs to be clarified; does it mean that any user from example.com is allowed as anonymous. Or does it mean any already known user (non-anonymous) is allowed as long as they can authenticate? -Doug --------------F76D3D9EEB4E1BE8655269DB Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------F76D3D9EEB4E1BE8655269DB-- From owner-ietf-calendar@imc.org Fri Jan 28 11:31:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17922 for ; Fri, 28 Jan 2000 11:31:24 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA07152 for ietf-calendar-bks; Fri, 28 Jan 2000 08:09: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 IAA07148 for ; Fri, 28 Jan 2000 08:09:11 -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 IAA21071 for ; Fri, 28 Jan 2000 08:11:07 -0800 (PST) Message-ID: <3891BF9A.B12247AB@home.royer.com> Date: Fri, 28 Jan 2000 08:11:06 -0800 From: Doug Royer 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: ACTONBEHALFOF (was: revised security section) References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu> <3890A496.89ACBD02@home.royer.com> <38913D2E.B17C2C04@msdw.com> Content-Type: multipart/mixed; boundary="------------47BE10E93C64E6C310749FC5" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------47BE10E93C64E6C310749FC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Madeo wrote: > > Doug Royer wrote: > > > > - 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? > > The general problem we're trying to solve here is how do I let my secretary or P/A > modify my calendar. One way is to grant permissions such as above. Another is to > authenticate via SASL as yourself, but then ask for the UPN of your principal (eg: > the boss). If the SASL server is configured properly, you may be allowed use that > UPN even though it's not your "own". Thanks. Lets hope the group can come to the same agreement. > Each side has it's merits. In the first case, we have to go through and figure out > what is meant, however we can be precise. In the second case, as far as the CS is > concerned, the boss just logged in and can do whatever they'd like, subject to the > BOSS's VCAR's. There's no way to tell which were created by the secretary and which > by the owner. The SENT-BY paramater in the ORGANIZER property would be set to the person that created the component, if not the ORGANIZER. And I guess that means we must allow for a UPN in the SENT-BY paramater. Which meanst that section 4.2.18 must be updated in iCalendar. --------------47BE10E93C64E6C310749FC5 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------47BE10E93C64E6C310749FC5-- From owner-ietf-calendar@imc.org Fri Jan 28 11:54:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18834 for ; Fri, 28 Jan 2000 11:54:47 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA07867 for ietf-calendar-bks; Fri, 28 Jan 2000 08:33: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 IAA07863 for ; Fri, 28 Jan 2000 08:33: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 IAA21088 for ; Fri, 28 Jan 2000 08:35:33 -0800 (PST) Message-ID: <3891C554.55634BD5@home.royer.com> Date: Fri, 28 Jan 2000 08:35:32 -0800 From: Doug Royer 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.20000127153336.01ab19d0@po12.mit.edu> <389140A5.DD45BAEC@msdw.com> Content-Type: multipart/mixed; boundary="------------6E3C3D2C8A604A28786A4DE8" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6E3C3D2C8A604A28786A4DE8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > This does not raise the inheritance issue Rich was concerned. The VCAR is > stored with the calendar just like everything else. The server just knows that > that particular VCAR can't be changed by the end user. How about a new optional property 'ACCESS': x.y.z ACCESS Property Name: ACCESS Purpose: Specifies if the component it is contained within is modifiable by any CUA. Format Definition: The property is defined by the following notation: accessparam = "ACCESS" ":" ( "READ-ONLY" / "READ-WRITE" ) Description: This property can be specified within a component. The parameter specifies if the property can be modified by a CUA. This property does not effect any non CUA vendor specific administrative tool from modifying the values in the component. If not specified in the component the component is READ-WRITE assuming the authenticated UPN has component MODIFY or DELETE access. Example. A rule to give full access to all localdomain users: BEGIN:VCAR CARID:access-1-ex ACCESS:READ-ONLY GRANT:UPN=@localdomain.com;ACTION=ALL;OBJECT=ALL END:VCAR (The example assumes that @domain means any authenticated user at domain. And not any local domain user as anonymous). -Doug --------------6E3C3D2C8A604A28786A4DE8 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------6E3C3D2C8A604A28786A4DE8-- From owner-ietf-calendar@imc.org Fri Jan 28 12:09:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19540 for ; Fri, 28 Jan 2000 12:09:48 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA08255 for ietf-calendar-bks; Fri, 28 Jan 2000 08:48:33 -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 IAA08251 for ; Fri, 28 Jan 2000 08:48:31 -0800 (PST) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/fw v1.30) id LAA16516 for ; Fri, 28 Jan 2000 11:50:26 -0500 (EST) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9490781721.011166; Fri, 28 Jan 00 11:49:32 -0500 Received: by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id LAA11145 for ; Fri, 28 Jan 2000 11:49:32 -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.9490781531.008969; Fri, 28 Jan 00 11:49:13 -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 LAA25414 for ; Fri, 28 Jan 2000 11:49:13 -0500 (EST) Message-ID: <3891C889.6DBFD3BB@msdw.com> Date: Fri, 28 Jan 2000 11:49:13 -0500 From: David Madeo 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: further suggestion for section 2.4.2.1 References: <4.2.0.58.20000127121344.01a48e90@po12.mit.edu> <389135DF.EA6240CC@msdw.com> <3891BE8E.D365DC28@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > David Madeo wrote: > > > "@example.com" is not anonymous access. It's "any authenticated user in > > example.com". An anonymous UPN is "@". Unless you actually authenticate the > > user, it's not possible for the server to determine if the user really is from > > "@example.com". > > I did not get that from the email. I understood it to mean any user > that happens to come from example.com. PLEASE clarify! My understanding was that we depend on the UPN provided by the authentication method negotiated via SASL. The UPN is supposed to be an rfc822 compliant name (eg: dmadeo@example.com). A VCAR which has "@example.com" means allow any authenticated user who's UPN matches the regexp /^(.*)\@example.com$/ An anonymous login who's UPN is "@" doesn't match that. I can potentially authenticate as dmadeo@example.com, regardless of my ip address. The server will need to check each UPN against the VCARs for a calendar. UPN -> "dmadeo@example.com" VCAR dmadeo@example.com -> matches VCAR foobar@example.com -> doesn't match VCAR @example.com -> matches VCAR @ -> matches UPN -> "@" VCAR dmadeo@example.com -> doesn't match VCAR foobar@example.com -> doesn't match VCAR @example.com -> doesn't match VCAR @ -> matches Do you want to force the server to keep two upn's for each user, one based on the authentication and one based on the domain name of the ip address connecting to the server? I suspect that's a can of worms you really don't want to open. If you authenticate as anonymous, your UPN should be "@", not "@example.com". Paul's text about the "trace" text associated with anonymous login applies here. dmadeo > It is possible to determine which host (or IP address) a connection > is from as soon as the connection is made - prior to any data transfers. > > So I think the text needs to be clarified; does it mean that any user > from example.com is allowed as anonymous. Or does it mean any already known > user (non-anonymous) is allowed as long as they can authenticate? From owner-ietf-calendar@imc.org Fri Jan 28 12:15:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19748 for ; Fri, 28 Jan 2000 12:15:24 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA08304 for ietf-calendar-bks; Fri, 28 Jan 2000 08:51:39 -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 IAA08300 for ; Fri, 28 Jan 2000 08:51:37 -0800 (PST) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id LAA23737 for ; Fri, 28 Jan 2000 11:53:33 -0500 (EST) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9490784041.023043; Fri, 28 Jan 00 11:53:24 -0500 Received: by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id LAA23042 for ; Fri, 28 Jan 2000 11:53:24 -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.9490783891.021768; Fri, 28 Jan 00 11:53:09 -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 LAA26885 for ; Fri, 28 Jan 2000 11:53:09 -0500 (EST) Message-ID: <3891C974.EFE25ED5@msdw.com> Date: Fri, 28 Jan 2000 11:53:08 -0500 From: David Madeo 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: ACTONBEHALFOF (was: revised security section) References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu> <3890A496.89ACBD02@home.royer.com> <38913D2E.B17C2C04@msdw.com> <3891BF9A.B12247AB@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > David Madeo wrote: > > > > Doug Royer wrote: > > > > > > - 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? > > > > The general problem we're trying to solve here is how do I let my secretary or P/A > > modify my calendar. One way is to grant permissions such as above. Another is to > > authenticate via SASL as yourself, but then ask for the UPN of your principal (eg: > > the boss). If the SASL server is configured properly, you may be allowed use that > > UPN even though it's not your "own". > > Thanks. Lets hope the group can come to the same agreement. I suspect both methods will be used to provide "secretary" access. > > Each side has it's merits. In the first case, we have to go through and figure out > > what is meant, however we can be precise. In the second case, as far as the CS is > > concerned, the boss just logged in and can do whatever they'd like, subject to the > > BOSS's VCAR's. There's no way to tell which were created by the secretary and which > > by the owner. > > The SENT-BY paramater in the ORGANIZER property would be set to the person > that created the component, if not the ORGANIZER. > > And I guess that means we must allow for a UPN in the SENT-BY paramater. > Which meanst that section 4.2.18 must be updated in iCalendar. Remember that in the second method where SASL is used, the server "sees" the principals UPN, not the secretary's. There's no way the server can distinguish between them. What you refer to will be the case if we use VCAR's to grant this access. dmadeo From owner-ietf-calendar@imc.org Fri Jan 28 12:44:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21090 for ; Fri, 28 Jan 2000 12:44:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA08775 for ietf-calendar-bks; Fri, 28 Jan 2000 09:24:57 -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 JAA08770 for ; Fri, 28 Jan 2000 09:24:56 -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 JAA21143 for ; Fri, 28 Jan 2000 09:26:51 -0800 (PST) Message-ID: <3891D15B.187414A8@home.royer.com> Date: Fri, 28 Jan 2000 09:26:51 -0800 From: Doug Royer 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: ACTONBEHALFOF (was: revised security section) References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu> <3890A496.89ACBD02@home.royer.com> <38913D2E.B17C2C04@msdw.com> <3891BF9A.B12247AB@home.royer.com> <3891C974.EFE25ED5@msdw.com> Content-Type: multipart/mixed; boundary="------------E43E4AE951B9BC4B0E4C18D2" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E43E4AE951B9BC4B0E4C18D2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > And I guess that means we must allow for a UPN in the SENT-BY paramater. > > Which meanst that section 4.2.18 must be updated in iCalendar. > > Remember that in the second method where SASL is used, the server "sees" > the principals UPN, not the secretary's. There's no way the server can > distinguish between them. What you refer to will be the case if we use > VCAR's to grant this access. I thought that the secretary would authenticate with their own UPN, then do a IDENTIFY command. At that point they authenticated as themselves, then changed (at run time and without logging out) their identity. The CS should know this. Any new component sent would have ORGANIZER set to what IDENTIFY did, and SENT-BY set to their own UPN? I am still catching up to the authentication text. Or do I have two separate points mixed up? -Doug --------------E43E4AE951B9BC4B0E4C18D2 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------E43E4AE951B9BC4B0E4C18D2-- From owner-ietf-calendar@imc.org Fri Jan 28 13:25:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22562 for ; Fri, 28 Jan 2000 13:25:26 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA09373 for ietf-calendar-bks; Fri, 28 Jan 2000 09:54:49 -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 JAA09369 for ; Fri, 28 Jan 2000 09:54:47 -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 JAA21155 for ; Fri, 28 Jan 2000 09:56:43 -0800 (PST) Message-ID: <3891D85B.24DA74A3@home.royer.com> Date: Fri, 28 Jan 2000 09:56:43 -0800 From: Doug Royer 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: further suggestion for section 2.4.2.1 References: <4.2.0.58.20000127121344.01a48e90@po12.mit.edu> <389135DF.EA6240CC@msdw.com> <3891BE8E.D365DC28@home.royer.com> <3891C889.6DBFD3BB@msdw.com> Content-Type: multipart/mixed; boundary="------------2E5D8E5F797524BFB8CB284A" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2E5D8E5F797524BFB8CB284A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > I did not get that from the email. I understood it to mean any user > > that happens to come from example.com. PLEASE clarify! > > My understanding was that we depend on the UPN provided by the > authentication method negotiated via SASL. The UPN is supposed to be an > rfc822 compliant name (eg: dmadeo@example.com). A VCAR which has > "@example.com" means allow any authenticated user who's UPN matches the > regexp /^(.*)\@example.com$/ An anonymous login who's UPN is "@" > doesn't match that. I can potentially authenticate as > dmadeo@example.com, regardless of my ip address. > > The server will need to check each UPN against the VCARs for a calendar. > > UPN -> "dmadeo@example.com" > VCAR dmadeo@example.com -> matches > VCAR foobar@example.com -> doesn't match > VCAR @example.com -> matches > VCAR @ -> matches An anonymous user should not match? Or did I miss that? The CS will get '@' as the UPN during authenticate for an anonymous user? Or will it get 'dmadeo@example.com' look for that first; if not found look for '@example.com', and authenticate 'dmadeo'; then if no match and if a '@' VCAR exist, treat 'dmadeo@example.com' as anonymous? I did not understand that when I read the text. 'I' think the text needs to clearly explain this misunderstanding. I don't care which way it goes, I just would not know which way to code a CS. Or maybe I am just nuts and everyone else understood? :-) > UPN -> "@" > VCAR dmadeo@example.com -> doesn't match > VCAR foobar@example.com -> doesn't match > VCAR @example.com -> doesn't match > VCAR @ -> matches > > Do you want to force the server to keep two upn's for each user, one > based on the authentication and one based on the domain name of the ip > address connecting to the server? From IP address you can get host.domainname . From host.domain I can check for a VCAR with '@example.com'. Again I am not proposing anything - I am asking for clarification. I do not know what the text as proposed means as I think I could write two implementations each that seemed to be compliant to the text, both or one of which would be incompatible with others. > I suspect that's a can of worms you > really don't want to open. If you authenticate as anonymous, your UPN > should be "@", not "@example.com". Paul's text about the "trace" text > associated with anonymous login applies here. I read the "trace" text to mean that a CUA SHOULD not by default send the users email address as their UPN. I think that is great! But I do not see in that text where it states that a VCAR with "@example.com" means any user that the CS already knows about (email address or not), or does it mean that any user from that domain is allowed anonymous access? So is: @example.com an anonymous user? So if I see this in a VCAR then any user given access without any other VCAR has the same access as an anonymous user? Or does it mean: @example.com would be allowed access by the CS? And their may be in a VCAR. Because any user from example.com is NOT anonymous? And at the same time @example.com would be rejected and NOT be treated as anonymous? Again - I am not proposing anything. I still do not understand. > dmadeo > > > It is possible to determine which host (or IP address) a connection > > is from as soon as the connection is made - prior to any data transfers. > > > > So I think the text needs to be clarified; does it mean that any user > > from example.com is allowed as anonymous. Or does it mean any already known > > user (non-anonymous) is allowed as long as they can authenticate? --------------2E5D8E5F797524BFB8CB284A Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------2E5D8E5F797524BFB8CB284A-- From owner-ietf-calendar@imc.org Fri Jan 28 13:28:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22616 for ; Fri, 28 Jan 2000 13:27:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09428 for ietf-calendar-bks; Fri, 28 Jan 2000 09:58:57 -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 JAA09424 for ; Fri, 28 Jan 2000 09:58:56 -0800 (PST) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/fw v1.30) id NAA18570 for ; Fri, 28 Jan 2000 13:00:52 -0500 (EST) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9490824321.017751; Fri, 28 Jan 00 13:00:32 -0500 Received: by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id NAA17734 for ; Fri, 28 Jan 2000 13:00:32 -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.9490824271.017186; Fri, 28 Jan 00 13:00:27 -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 NAA18943 for ; Fri, 28 Jan 2000 13:00:26 -0500 (EST) Message-ID: <3891D93A.265B864C@msdw.com> Date: Fri, 28 Jan 2000 13:00:26 -0500 From: David Madeo 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: ACTONBEHALFOF (was: revised security section) References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu> <3890A496.89ACBD02@home.royer.com> <38913D2E.B17C2C04@msdw.com> <3891BF9A.B12247AB@home.royer.com> <3891C974.EFE25ED5@msdw.com> <3891D15B.187414A8@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > > > And I guess that means we must allow for a UPN in the SENT-BY paramater. > > > Which meanst that section 4.2.18 must be updated in iCalendar. > > > > Remember that in the second method where SASL is used, the server "sees" > > the principals UPN, not the secretary's. There's no way the server can > > distinguish between them. What you refer to will be the case if we use > > VCAR's to grant this access. > > I thought that the secretary would authenticate with their own UPN, > then do a IDENTIFY command. At that point they authenticated as themselves, > then changed (at run time and without logging out) their identity. > > The CS should know this. Any new component sent would have ORGANIZER > set to what IDENTIFY did, and SENT-BY set to their own UPN? IDENTIFY is out as far as I know. Paul can explain more, but SASL has a mechanism where you authenticate as yourself, but ask to be identified as a different name. Whatever authentication method you choose through SASL has to support this of course, and it's responsible for ensuring you're allowed to do this. Presumably there will be a local config file to allow this. So, from the servers point of view, a user with a UPN just shows up and it takes it at face value. That's why I think both methods will be used. Personally I'd rather have the VCAR's since I'd like to use the Sent-By and Organizer properties in the way you describe. Perhaps if enough people feel strongly about this, we can put text in to say that the UPN trickery can not be used for designate access. dmadeo > I am still catching up to the authentication text. Or do I have > two separate points mixed up? From owner-ietf-calendar@imc.org Fri Jan 28 14:39:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24902 for ; Fri, 28 Jan 2000 14:39:26 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA10988 for ietf-calendar-bks; Fri, 28 Jan 2000 11:14: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 LAA10983 for ; Fri, 28 Jan 2000 11:14: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 LAA21213 for ; Fri, 28 Jan 2000 11:16:03 -0800 (PST) Message-ID: <3891EAF2.860B45F0@home.royer.com> Date: Fri, 28 Jan 2000 11:16:02 -0800 From: Doug Royer 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 CC: ietf-calendar@imc.org Subject: Re: ACTONBEHALFOF (was: revised security section) References: <4.2.0.58.20000127105755.06ec4130@po12.mit.edu> <3890A496.89ACBD02@home.royer.com> <38913D2E.B17C2C04@msdw.com> <3891BF9A.B12247AB@home.royer.com> <3891C974.EFE25ED5@msdw.com> <3891D15B.187414A8@home.royer.com> <3891D93A.265B864C@msdw.com> Content-Type: multipart/mixed; boundary="------------341D4FD284ACB308E93C74ED" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------341D4FD284ACB308E93C74ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > IDENTIFY is out as far as I know. Paul can explain more, but SASL has a > mechanism where you authenticate as yourself, but ask to be identified > as a different name. Whatever authentication method you choose through > SASL has to support this of course, and it's responsible for ensuring > you're allowed to do this. Presumably there will be a local config file > to allow this. Okay - then the SASL mechanism implementation needs to keep track of this so that it can be tracked and used in SENT-BY (per iTIP). In the past (in the WG), we could not find ANY SASL implementation that allowed this to work - so we invented IDENTIFY - If I remember the history correctly. The generic SASL framework allowed for it, but none of the needed mechanisms supported it. (Again as I recall). However when it comes to security, I will bow to Paul. If he says it will work, I am sure it can. We will need to tell people how in CAP as most of us are not security experts. As in: If you want to be able to do something on behalf of someone else you have these choices: (1) Authenticate as them using any agreed on mechanism as returned from CAPABILITY. or (2) Authenticate as yourself, use SASL to And at least SASL mechanism MUST be implemented by the CUA and CS wishing to use this method to act on behalf of someone as the fallback for interoperability. or ... > So, from the servers point of view, a user with a UPN just shows up and > it takes it at face value. > > That's why I think both methods will be used. Personally I'd rather > have the VCAR's since I'd like to use the Sent-By and Organizer > properties in the way you describe. Perhaps if enough people feel > strongly about this, we can put text in to say that the UPN trickery can > not be used for designate access. Per iTIP, that is what SENT-BY is. And as CAP allow scheduling per iTIP, I think we MUST support that meaning. Let's not invent another way and lets support SENT-BY. --------------341D4FD284ACB308E93C74ED Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------341D4FD284ACB308E93C74ED-- From owner-ietf-calendar@imc.org Fri Jan 28 15:17:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25918 for ; Fri, 28 Jan 2000 15:17:14 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA11400 for ietf-calendar-bks; Fri, 28 Jan 2000 11:43:37 -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 LAA11396 for ; Fri, 28 Jan 2000 11:43:35 -0800 (PST) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id OAA02020 for ; Fri, 28 Jan 2000 14:45:32 -0500 (EST) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9490887221.001034; Fri, 28 Jan 00 14:45:22 -0500 Received: by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id OAA01025 for ; Fri, 28 Jan 2000 14:45:22 -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.9490887201.000757; Fri, 28 Jan 00 14:45:20 -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 OAA18853 for ; Fri, 28 Jan 2000 14:45:19 -0500 (EST) Message-ID: <3891F1CF.602EA398@msdw.com> Date: Fri, 28 Jan 2000 14:45:19 -0500 From: David Madeo 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: further suggestion for section 2.4.2.1 References: <4.2.0.58.20000127121344.01a48e90@po12.mit.edu> <389135DF.EA6240CC@msdw.com> <3891BE8E.D365DC28@home.royer.com> <3891C889.6DBFD3BB@msdw.com> <3891D85B.24DA74A3@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is my last post on the subject for a few days, so let's hope it's a good one :) Comments throughout. Doug Royer wrote: > > > > I did not get that from the email. I understood it to mean any user > > > that happens to come from example.com. PLEASE clarify! > > > > My understanding was that we depend on the UPN provided by the > > authentication method negotiated via SASL. The UPN is supposed to be an > > rfc822 compliant name (eg: dmadeo@example.com). A VCAR which has > > "@example.com" means allow any authenticated user who's UPN matches the > > regexp /^(.*)\@example.com$/ An anonymous login who's UPN is "@" > > doesn't match that. I can potentially authenticate as > > dmadeo@example.com, regardless of my ip address. > > > > The server will need to check each UPN against the VCARs for a calendar. > > > > UPN -> "dmadeo@example.com" > > VCAR dmadeo@example.com -> matches > > VCAR foobar@example.com -> doesn't match > > VCAR @example.com -> matches > > VCAR @ -> matches > > An anonymous user should not match? Or did I miss that? > The CS will get '@' as the UPN during authenticate for an anonymous user? Yes. The server has no idea who the user is if it's anonymous. > Or will it get 'dmadeo@example.com' look for that first; if not found > look for '@example.com', and authenticate 'dmadeo'; then if no match > and if a '@' VCAR exist, treat 'dmadeo@example.com' as anonymous? The server should not need to know how to do this. It should take whatever UPN that SASL and the authentication method gives it. The server will often compare this UPN against a VCAR to see if the UPN is authorized. That's what I in the matching example above. The VCAR has "@example.com" and the server is comparing the UPN "dmadeo@example.com" against it. It matches. Originally I thought that there should be no way for a user to authenticate as "@example.com". However, I can see a case where a SASL mechanism is configured such that any local user who authenticates but wants to be "@example.com" can do so. This allows two levels on anonymity: global and domain specific. GRRR. Paul, we'll need to refine the UPN definition to include two additional cases which aren't RFC822 compliant. "@" and "@example.com". We should expressly forbid "user@" here too. > I did not understand that when I read the text. 'I' think > the text needs to clearly explain this misunderstanding. I don't > care which way it goes, I just would not know which way to code a CS. > Or maybe I am just nuts and everyone else understood? :-) In some areas, the security text assumes you know nothing. In others, it assumes you've already picked your SASL libraries and know what you're doing. > > UPN -> "@" > > VCAR dmadeo@example.com -> doesn't match > > VCAR foobar@example.com -> doesn't match > > VCAR @example.com -> doesn't match > > VCAR @ -> matches > > > > Do you want to force the server to keep two upn's for each user, one > > based on the authentication and one based on the domain name of the ip > > address connecting to the server? > > From IP address you can get host.domainname . > From host.domain I can check for a VCAR with '@example.com'. Clearly, you can figure out which domainname is associated with an ip address. However, the Calendar server shouldn't even try to extrapolate this. Trust the authentication, nothing else. > Again I am not proposing anything - I am asking for clarification. I do > not know what the text as proposed means as I think I could write two > implementations each that seemed to be compliant to the text, both or one of > which would be incompatible with others. > > > I suspect that's a can of worms you > > really don't want to open. If you authenticate as anonymous, your UPN > > should be "@", not "@example.com". Paul's text about the "trace" text > > associated with anonymous login applies here. > > I read the "trace" text to mean that a CUA SHOULD not by default send > the users email address as their UPN. I think that is great! Yes. > But I do not see in that text where it states that a VCAR with "@example.com" > means any user that the CS already knows about (email address or not), > or does it mean that any user from that domain is allowed anonymous access? I meant that if you're logging in as anonymous, the server shouldn't be storing anything that identifies you, including your domain. > So is: > > @example.com an anonymous user? So if I see this in a VCAR > then any user given access without any other VCAR > has the same access as an anonymous user? Depending on the context, this is either the UPN of a domain specific anonymous user OR a UPN in a VCAR which will match any authenticated user (even an anonymous one). If I see this in a VCAR, I think that this rule applies to any user who authenticated and their UPN either is or ends in "@example.com". > Or does it mean: > > @example.com would be allowed access by the CS? > And their may be in a VCAR. > Because any user from example.com is NOT anonymous? > > And at the same time @example.com > would be rejected and NOT be treated as anonymous? > Hope this helps everyone clarify the issues. Thanks, dmadeo From owner-ietf-calendar@imc.org Fri Jan 28 17:10:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28187 for ; Fri, 28 Jan 2000 17:10:30 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA12641 for ietf-calendar-bks; Fri, 28 Jan 2000 13:25:27 -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 NAA12637 for ; Fri, 28 Jan 2000 13:25:25 -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 NAA21361 for ; Fri, 28 Jan 2000 13:25:26 -0800 (PST) Message-ID: <38920946.38B1C646@home.royer.com> Date: Fri, 28 Jan 2000 13:25:26 -0800 From: Doug Royer 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: further suggestion for section 2.4.2.1 References: <4.2.0.58.20000127121344.01a48e90@po12.mit.edu> <389135DF.EA6240CC@msdw.com> <3891BE8E.D365DC28@home.royer.com> <3891C889.6DBFD3BB@msdw.com> <3891D85B.24DA74A3@home.royer.com> <3891F1CF.602EA398@msdw.com> Content-Type: multipart/mixed; boundary="------------E8903912214D81B62765E612" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E8903912214D81B62765E612 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Madeo wrote: > > This is my last post on the subject for a few days, so let's hope it's a > good one :) > > Comments throughout. > > Doug Royer wrote: > > > > > > I did not get that from the email. I understood it to mean any user > > > > that happens to come from example.com. PLEASE clarify! > > > > > > My understanding was that we depend on the UPN provided by the > > > authentication method negotiated via SASL. The UPN is supposed to be an > > > rfc822 compliant name (eg: dmadeo@example.com). A VCAR which has > > > "@example.com" means allow any authenticated user who's UPN matches the > > > regexp /^(.*)\@example.com$/ An anonymous login who's UPN is "@" > > > doesn't match that. I can potentially authenticate as > > > dmadeo@example.com, regardless of my ip address. > > > > > > The server will need to check each UPN against the VCARs for a calendar. > > > > > > UPN -> "dmadeo@example.com" > > > VCAR dmadeo@example.com -> matches > > > VCAR foobar@example.com -> doesn't match > > > VCAR @example.com -> matches > > > VCAR @ -> matches > > > > An anonymous user should not match? Or did I miss that? > > The CS will get '@' as the UPN during authenticate for an anonymous user? > > Yes. ... Yes to both questions, or the last one? > ... The server has no idea who the user is if it's anonymous. True - but that was not my question. > > Or will it get 'dmadeo@example.com' look for that first; if not found > > look for '@example.com', and authenticate 'dmadeo'; then if no match > > and if a '@' VCAR exist, treat 'dmadeo@example.com' as anonymous? > > The server should not need to know how to do this. It should take > whatever UPN that SASL and the authentication method gives it. Not entirely true. We have to specify what we want. If we are saying that '@' means anonymous, then that is a new thing that I have not seen in any SASL mechanism. Same with '@domain'. In both cases no SASL implementation that I have seen will allow '@' to mean global-anonymous or '@domain' to mean domain specific anonymous. Someone still needs to write an implementation of the SASL mechanism for their CS implementation. There are ways to authenticate using SASL as anonymous. None that I have seen specify returning '@' or '@domain' to the underlying layers, or as the authentication id. SASL indirectly does allow us to specify those things. It is just not clear to me that we have done that in the text. > The server will often compare this UPN against a VCAR to see if the UPN is > authorized. That's what I in the matching example above. The VCAR has > "@example.com" and the server is comparing the UPN "dmadeo@example.com" > against it. It matches. That part of the picture I understand. The question is: Are your now 'dmadeo' or 'anonymous'? If the answer is that you are 'anonymous' how do we specify *any* valid user at domain? (ANY@domain ?). If the answer is that you are 'dmadeo' how do we specify any user at domain - as anonymous? (anonymous@domain ?) > Originally I thought that there should be no way for a user to > authenticate as "@example.com". However, I can see a case where a SASL > mechanism is configured such that any local user who authenticates but > wants to be "@example.com" can do so. This allows two levels on > anonymity: global and domain specific. What if we want a VCAR to allow for ANY-KNOWN -AND- authenticated user at a named domain. Such as: BEGIN:VCAR CARID:allow all users from our clients GRANT:UPN=ANY@paid-in-full.com;.... END:VCAR -OR- Do I have to enumerate all of usersin a VCAR? Yuck! > GRRR. Paul, we'll need to refine the UPN definition to include two > additional cases which aren't RFC822 compliant. "@" and > "@example.com". We should expressly forbid "user@" here too. > > > I did not understand that when I read the text. 'I' think > > the text needs to clearly explain this misunderstanding. I don't > > care which way it goes, I just would not know which way to code a CS. > > Or maybe I am just nuts and everyone else understood? :-) > > In some areas, the security text assumes you know nothing. In others, > it assumes you've already picked your SASL libraries and know what > you're doing. Only if we in advance specify the minimum SASL mechanism that can interoperate. Then WE must specify in advance what it means to a CS if it gets '@' or '@name'. > > > UPN -> "@" > > > VCAR dmadeo@example.com -> doesn't match > > > VCAR foobar@example.com -> doesn't match > > > VCAR @example.com -> doesn't match > > > VCAR @ -> matches > > > > > > Do you want to force the server to keep two upn's for each user, one > > > based on the authentication and one based on the domain name of the ip > > > address connecting to the server? > > > > From IP address you can get host.domainname . > > From host.domain I can check for a VCAR with '@example.com'. > > Clearly, you can figure out which domainname is associated with an ip > address. However, the Calendar server shouldn't even try to extrapolate > this. Trust the authentication, nothing else. Spammers and hackers would love that. I can see that we would NOT require it. However any large site would need to keep track of the connections for security auditing when someone hacks. As I see it, anonymous connections to a CS are need only because each public calendar will not be able to authenticate ALL possible CUs. As in, if I don't know you, then login as anonymous and I will give you access to read all public events that have a VCAR for anonymous access. There may also be a need at some sites to provide a way for a CS to ensure anonymity. And we can define that way in advance, and we can mandate that a CS understands this request (even if it says NO). We can not mandate that a CS does not track connections or users. > > But I do not see in that text where it states that a VCAR with "@example.com" > > means any user that the CS already knows about (email address or not), > > or does it mean that any user from that domain is allowed anonymous access? > > I meant that if you're logging in as anonymous, the server shouldn't be > storing anything that identifies you, including your domain. I disagree. A public baseball field may have a calendar. Because the CS-admin does not want to have to provide an authentication id to all possible residents. They may allow anonymous access. In this case they do want and need (so they can email you back) you real-id. So as I read text, this should not be automatic. But the CU may say yes. > > So is: > > > > @example.com an anonymous user? So if I see this in a VCAR > > then any user given access without any other VCAR > > has the same access as an anonymous user? > > Depending on the context, this is either the UPN of a domain specific > anonymous user OR a UPN in a VCAR which will match any authenticated > user (even an anonymous one). When would you see '@example.com' NOT in a VCAR? > If I see this in a VCAR, I think that > this rule applies to any user who authenticated and their UPN either is > or ends in "@example.com". Okay - now how would in a VCAR I say any anonymous user in that domain, but only anonymous users? Because all known users in that domain would have their own VCAR. > > Or does it mean: > > > > @example.com would be allowed access by the CS? > > And their may be in a VCAR. > > Because any user from example.com is NOT anonymous? > > > > And at the same time @example.com > > would be rejected and NOT be treated as anonymous? > > > > Hope this helps everyone clarify the issues. Closer, but I am still not convinced that all points on the matrix have been covered. I would like to see something like (Or perhaps all of this is covered and I am still not getting it): (a) @domain - Means any KNOWN user @domain (b) anonymous@domain - ONLY anonymous users @domain and excludes known users. (c) user-name@domain - ONLY the named 'user-name' @domain (d) @ - Means anonymous user from ANY domain. And excludes known users. I think this would simplify VCARs. I see the proposed text and this discussion as saying that: (I) anonymous can be (a) or (d). (II) Known users can be (a) or (c). No way to say anonymous only VCAR access. No way to say only non-anonymous known users. VCAR with (a) is ambiguous when the CS would be trying to enforce a VCAR, it could have a problem with two conflicting VCARS. One for anonymous and another for when they are known. BEGIN:VCAR CARID:access for anonymous users. GRANT:UPN=@example.com; .... DENY: ... CREATE,WRITE,... END:VCAR BEGIN:VCAR CARID:access for tweaker GRANT:UPN=tweaker@example.com; ... CREATE,WRITE... END:VCAR So when they authenticate as tweaker@example.com, in your example they match the 1st rule. As there is no unambiguous way to specify only-if-anonymous. Where as see this as unambiguous: BEGIN:VCAR CARID:access for anonymous users. GRANT:UPN=anonymous@example.com; .... DENY: ... CREATE,WRITE,... END:VCAR BEGIN:VCAR CARID:access for tweaker GRANT:UPN=tweaker@example.com; ... CREATE,WRITE... END:VCAR Or do I still have it wrong? :-) -Doug --------------E8903912214D81B62765E612 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------E8903912214D81B62765E612-- From owner-ietf-calendar@imc.org Fri Jan 28 18:12:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29380 for ; Fri, 28 Jan 2000 18:12:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13648 for ietf-calendar-bks; Fri, 28 Jan 2000 14:47:40 -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 OAA13643 for ; Fri, 28 Jan 2000 14:47:35 -0800 (PST) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA20043; Fri, 28 Jan 00 17:50:40 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 RAA00364; Fri, 28 Jan 2000 17:49: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 RAA00712; Fri, 28 Jan 2000 17:49:30 -0500 (EST) Message-Id: <4.2.0.58.20000128171434.01ab9ee8@po12.mit.edu> X-Sender: pbh@po12.mit.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 28 Jan 2000 17:24:50 -0500 To: David.Madeo@msdw.com From: "Paul B. Hill" Subject: Re: forced VCAR (was: revised security section) Cc: ietf-calendar@imc.org In-Reply-To: <389140A5.DD45BAEC@msdw.com> References: <4.2.0.58.20000127153336.01ab19d0@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: List-ID: List-Unsubscribe: At 02:09 AM 1/28/2000 -0500, David Madeo wrote: >I'd like to see the >"forced VCAR" be a mandatory addition to every calendars set of VCAR's. Hi, I'm trying to figure out what Dave means by mandatory. During the conversation in Cambridge I thought that Dave was hoping for a MAY implement but felt that MUST was not necessary, and was unlikely to be accepted. Dave, are you talking about the how a server might implement this feature, or the language that has to go into the draft? No that I think about it even more, is this subject appropriate for the draft at all? It would never appear as a part of the protocol on the wire, right? The only thing that would need to be defined for the protocol is what would be conveyed to the CUA if it tried to write a VCAR that the CS would not honor. Paul From owner-ietf-calendar@imc.org Sun Jan 30 03:28:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02064 for ; Sun, 30 Jan 2000 03:28:04 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA04999 for ietf-calendar-bks; Sat, 29 Jan 2000 23:58:14 -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 XAA04994 for ; Sat, 29 Jan 2000 23:58:12 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA14400 for ietf-calendar@imc.org; Sun, 30 Jan 2000 00:00:03 -0800 (PST) Date: Sun, 30 Jan 2000 00:00:03 -0800 (PST) From: Doug Royer Message-Id: <200001300800.AAA14400@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: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled 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? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D 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@imc.org Mon Jan 31 08:57:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03484 for ; Mon, 31 Jan 2000 08:57:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10926 for ietf-calendar-bks; Mon, 31 Jan 2000 05:25:43 -0800 (PST) Received: from webserver.gloclub2.net ([206.104.28.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10920; Mon, 31 Jan 2000 05:25:41 -0800 (PST) Received: from 206.104.28.4 [171.211.231.234] by webserver.gloclub2.net (SMTPD32-5.01) id A9C267E01C6; Sun, 30 Jan 2000 23:12:34 CST Received: from qr89503@hotmail.com by qr89503@hotmail.com (8.8.5/8.6.5) with SMTP id GAA04152 for ; Sun, 30 Jan 2000 21:54:09 -0600 (EST) Date: Sun, 30 Jan 00 21:54:09 EST From: qr89503@hotmail.com To: qr89503@hotmail.com Subject: New USA and INTERNATIONAL Merchant Accounts Message-ID: <> Reply-To: qr89503@hotmail.com Comments: Authenticated sender is Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD. Click below to Apply http://angelfire.com@3462929566/%74%68%65%73%65%72%76%69%63%65%34%38/%64%65%66%61%75%6C%74.%68%74m#@3626198025/%74%68%65%73%65%72%76%69c%65%348/de%66a%75l%74.%68%74%6D ARE YOU REALLY AN E-COMMERCE MERCHANT? Increase your revenues by up to 1500% by accepting credit cards and electronic checks. Increase your customer base 200- 400% with instant access to the World. ARE YOU PAYING TOO MUCH? Discount rates start at 2.1% Transaction fees start at 25 cents. DO YOU WAIT TOO LONG FOR YOUR MONEY? Funds available in 24-48 hours anywhere in the world DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS 99% of all applications are approved. ARE YOU LIMITED BY WHAT YOU CAN ACCEPT? Mastercard, Visa, Discover, Amex and Checks (USA checks only) All cards from ALL COUNTRIES - Including Eastern Europe and Asia - - - - - - - - - - - Click HERE to APPLY. http://angelfire.com@3462929566/%74%68%65%73%65%72%76%69%63%65%34%38/%64%65%66%61%75%6C%74.%68%74m#@3626198025/%74%68%65%73%65%72%76%69c%65%348/de%66a%75l%74.%68%74%6D NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A MERCHANT ACCOUNT. - - - - - - - - - - - To be removed from our mailing list, call (888) 341-4786 Clearly spell your email address and you will be removed. *** From owner-ietf-calendar@imc.org Mon Jan 31 10:11:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06181 for ; Mon, 31 Jan 2000 10:11:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA12555 for ietf-calendar-bks; Mon, 31 Jan 2000 06:49:01 -0800 (PST) Received: from webserver.gloclub2.net ([206.104.28.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12550; Mon, 31 Jan 2000 06:49:00 -0800 (PST) Date: Mon, 31 Jan 2000 06:49:00 -0800 (PST) From: qr89503@hotmail.com Message-Id: <200001311449.GAA12550@ns.secondary.com> Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: