From owner-ietf-calendar Sun Jan 2 00:00:36 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA06584 for ietf-calendar-bks; Sun, 2 Jan 2000 00:00:36 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06580 for ; 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 Mon Jan 3 06:46:34 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA16960 for ietf-calendar-bks; Mon, 3 Jan 2000 06:46:34 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16956 for ; 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 Mon Jan 3 08:36:56 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA18491 for ietf-calendar-bks; Mon, 3 Jan 2000 08:36:56 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18486 for ; 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggHZMIIBg6ADAgECAiBgUF6eflpWh6h9PfgYD7sAlMCM8enGl8RXOcIo9uhg ezANBgkqhkiG9w0BAQQFADBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzEN MAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTAeFw05OTEx MTcxOTEzMjdaFw0wMTExMTYxOTEyNTNaMEgxDTALBgNVBAoTBElyaXMxEzARBgNV BAMTCkJydWNlIEthaG4xIjAgBgkqhkiG9w0BCQEWE0JydWNlX0thaG5AaXJpcy5j b20wWzANBgkqhkiG9w0BAQEFAANKADBHAkEA495S/vcTouExtWuNrF33Q28Lcjjk 4lj2W6ERZ3MhEBR5vHL3wTaXoRWVhPeoDaUcCc54oig8YQlC/hwSp3YF4QICQlGj PDA6MBEGA1UdDgQKBAhG2i3x0db2dzAPBgNVHQ8BAf8EBQMDB7AAMBQGC2CGSAGG +A4CAgMCBAUDAweAADANBgkqhkiG9w0BAQQFAANBAJnY7BPUuh9G4grcCnmNPlMH JsE0/KULlvaqMab5uWQd0nFkZg64TIWwlYMLrwKqzenyrEkVF4QO6yjiShaej/Aw ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVT MQ0wCwYDVQQIEwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIElu dGVybmV0IENBMB4XDTk4MTEwMjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkG A1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMT EElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAw+BjK0cg xCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5yBLD j5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwz cO3Ltq2HlXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/wi ngAAMYAwggF5AgEBMGowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0ECIGBQXp5+WlaH qH09+BgPuwCUwIzx6caXxFc5wij26GB7MAkGBSsOAwIaBQCggaswGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMTAzMTYzNjAyWjAj BgkqhkiG9w0BCQQxFgQUH4U83D+MjRdjFc2UoDRgmEP7PO4wTAYJKoZIhvcNAQkP MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQEmbuob7Q8C4dPj71t3H BeMEAKvRFMEhrwUZ5KZlVmCJt/LzeqPJzNaqdAlWayrAzb9yStnEo26I8JxI44fd a4kAAAAAAAAAAA== ---------z01886_boundary_sign-- From owner-ietf-calendar Tue Jan 4 04:05:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA06387 for ietf-calendar-bks; Tue, 4 Jan 2000 04:05:42 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06383 for ; 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 Tue Jan 4 06:07:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07727 for ietf-calendar-bks; Tue, 4 Jan 2000 06:07:56 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07723 for ; 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: 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 Tue Jan 4 08:14:14 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA09651 for ietf-calendar-bks; Tue, 4 Jan 2000 08:14:14 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09646 for ; 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIAwggHZMIIBg6ADAgECAiBgUF6eflpWh6h9PfgYD7sAlMCM8enGl8RXOcIo9uhg ezANBgkqhkiG9w0BAQQFADBGMQswCQYDVQQGEwJVUzENMAsGA1UECBMETUFTUzEN MAsGA1UEChMESXJpczEZMBcGA1UEAxMQSXJpcyBJbnRlcm5ldCBDQTAeFw05OTEx MTcxOTEzMjdaFw0wMTExMTYxOTEyNTNaMEgxDTALBgNVBAoTBElyaXMxEzARBgNV BAMTCkJydWNlIEthaG4xIjAgBgkqhkiG9w0BCQEWE0JydWNlX0thaG5AaXJpcy5j b20wWzANBgkqhkiG9w0BAQEFAANKADBHAkEA495S/vcTouExtWuNrF33Q28Lcjjk 4lj2W6ERZ3MhEBR5vHL3wTaXoRWVhPeoDaUcCc54oig8YQlC/hwSp3YF4QICQlGj PDA6MBEGA1UdDgQKBAhG2i3x0db2dzAPBgNVHQ8BAf8EBQMDB7AAMBQGC2CGSAGG +A4CAgMCBAUDAweAADANBgkqhkiG9w0BAQQFAANBAJnY7BPUuh9G4grcCnmNPlMH JsE0/KULlvaqMab5uWQd0nFkZg64TIWwlYMLrwKqzenyrEkVF4QO6yjiShaej/Aw ggF+MIIBKKADAgECAgQ2PhKnMA0GCSqGSIb3DQEBBAUAMEYxCzAJBgNVBAYTAlVT MQ0wCwYDVQQIEwRNQVNTMQ0wCwYDVQQKEwRJcmlzMRkwFwYDVQQDExBJcmlzIElu dGVybmV0IENBMB4XDTk4MTEwMjA4MTQwMFoXDTA4MTAzMDA4MTQwMFowRjELMAkG A1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTALBgNVBAoTBElyaXMxGTAXBgNVBAMT EElyaXMgSW50ZXJuZXQgQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAw+BjK0cg xCxC13brFzl7eB4j2cat+s6ZSd2flxlTuJGg1dtyQHwKYRsDODiEpqUC5oI5yBLD j5LDYXUEwBm4YQIDAQABMA0GCSqGSIb3DQEBBAUAA0EASQ/WFnGO4okdcxMtJrwz cO3Ltq2HlXm3akcNDZ0cltVk60oXJyKq+LVXR/Twj+ZI/Zsr5qfhb5JALi7C+/wi ngAAMYAwggF5AgEBMGowRjELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE1BU1MxDTAL BgNVBAoTBElyaXMxGTAXBgNVBAMTEElyaXMgSW50ZXJuZXQgQ0ECIGBQXp5+WlaH qH09+BgPuwCUwIzx6caXxFc5wij26GB7MAkGBSsOAwIaBQCggaswGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMTA0MTYxMzM0WjAj BgkqhkiG9w0BCQQxFgQULX8En5xPBkXBcORKk/hLFnkcg2kwTAYJKoZIhvcNAQkP MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQCMvNs5MlzG0ff6/89SC DEISejEyDNyxua95BJtWBkOAyhxX8BKtqdt5oeh9yBjro7hhdh7P/+JaQbm+xBT4 Xz8AAAAAAAAAAA== ---------z01886_boundary_sign-- From owner-ietf-calendar Tue Jan 4 18:24:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA21276 for ietf-calendar-bks; Tue, 4 Jan 2000 18:24:54 -0800 (PST) Received: from titan.exoffice.com (IDENT:root@host98.ridgeventures.com [207.33.160.98] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21267 for ; 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: > > 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 Wed Jan 5 05:33:29 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA29098 for ietf-calendar-bks; Wed, 5 Jan 2000 05:33:29 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29092; Wed, 5 Jan 2000 05:33:28 -0800 (PST) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA13194; Wed, 5 Jan 2000 08:47:45 -0500 (EST) Received: from barium.Lotus.com (BARIUM.lotus.com [9.95.4.108]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA12167; Wed, 5 Jan 2000 08:30:24 -0500 (EST) To: lesage@exoffice.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@imc.org Subject: Re: XML DTD update proposition X-Mailer: Lotus Notes Build V5010624 June 24, 1999 Message-ID: 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 Wed Jan 5 07:44:41 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA01121 for ietf-calendar-bks; Wed, 5 Jan 2000 07:44:41 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01117 for ; 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: 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 Wed Jan 5 09:08:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02460 for ietf-calendar-bks; Wed, 5 Jan 2000 09:08:44 -0800 (PST) Received: from mail1.myriad.com ([63.75.14.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA02456 for ; 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: Frank_Dawson@lotus.com wrote: > We are also not assuming the XML iCalendar object would be parsed by a validating parser. I believe you can always feed an XML document that is highly specified by some (external) DTD into a non-validating parser regardless of how specified it is. -Paul -- Myriad Genetics: http://www.myriad.com/ Java FAQ: http://www.afu.com/javafaq.html (Section 9, Computer Dating) From owner-ietf-calendar Wed Jan 5 18:15:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11614 for ietf-calendar-bks; Wed, 5 Jan 2000 18:15:41 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11608 for ; 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 Wed Jan 5 18:20:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11993 for ietf-calendar-bks; Wed, 5 Jan 2000 18:20:12 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11987 for ; 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 Wed Jan 5 22:02:00 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA23964 for ietf-calendar-bks; Wed, 5 Jan 2000 22:02:00 -0800 (PST) Received: from titan.exoffice.com (IDENT:root@host98.ridgeventures.com [207.33.160.98] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA23960 for ; 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: Hi all ! I wrotte an xml schema which is as close as possible from the xml structure defined by the ICalendar DTD draft. (except for the rrules & exrules... ) This is just a first version an it needs to be improved. All comments are welcome ! http://shuffle.exolab.org/schema.xml (with netscape, use View Page Source) Philippe Lesage Exoffice Technologies. From owner-ietf-calendar Thu Jan 6 09:05:13 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11444 for ietf-calendar-bks; Thu, 6 Jan 2000 09:05:13 -0800 (PST) Received: from titan.exoffice.com (host98.ridgeventures.com [207.33.160.98] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11440 for ; 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: 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 Thu Jan 6 08:44:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11095 for ietf-calendar-bks; Thu, 6 Jan 2000 08:44:30 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11091 for ; 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: Frank: > You are missing the point. > Yes, I definitely do! > Creating a more structured on the wire format, that takes more bandwidth (both on the > wire and to parse), when the originator and recipient already understand the IETF > standard iCalendar semantics makes not sense. > I can not see a reason to use XML if those documents are readable only for tools which know about iCalendar data types. The iCalendar tool can always read RFC2445-document so it needs not "optional"(draft-many-ical-xmldoc-01.txt p 2.3.2) XML. > Unless you are interested in defining a new XML application for calendaring. > > Which we are not. We already have a single standard for representing calendar > information and scheduling semantics. Let's leverage it. > It sounds like you are ready to discuss cosmetic details of the document cover, but you would not discuss the concept of the document. I am not interested in "a new XML application for calendaring". Only things I am talking about are more detailed XML representation of the data types defined in RFC2445 and XML grammar which more adequate to grammar defined in the same RFC2445. Michael -- --------------------------------------------------------------- Michael Krivoruchko CDE Group, Sun Microsystems Bool House, East Point Business Park, Dublin 3, Ireland Ph: +353 1 819 9272 E-mail: misha@ireland.sun.com --------------------------------------------------------------- From owner-ietf-calendar Thu Jan 6 10:38:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12630 for ietf-calendar-bks; Thu, 6 Jan 2000 10:38:32 -0800 (PST) Received: from mail1.myriad.com ([63.75.14.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA12626 for ; 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: Frank_Dawson@lotus.com wrote: > Creating a more structured on the wire format, that takes more bandwidth (both > on the wire and to parse), when the originator and recipient already understand > the IETF standard iCalendar semantics makes not sense. Yes, a more wordy, more structured format has the disadvantage that it does take more space to store and transmit. I would think that the time and space it takes to parse would be comparable. The advantage is that these apparently excessive markings helps apps that never have heard of iCalendar to deal with calendar information. > Unless you are interested in defining a new XML application for calendaring. While iCalendar is more optimized for communication between general purpose calendar user agents and between calendar systems, the advantage of defining a translation to an alternate, but more general (yet verbose) XML compliant format, is that this alternate format can be used where applicable to solve _additional_ problems outside of 'normal' calendaring. It is the potential to work with the data elsewhere that drives a desire for an XML form of iCalendar. XML applications parsing libraries, books etc. already exist and are being written as we speak, all they need is a DTD to drive them. These include XML aware browsers, XML viewers, multiple general purpose parsing libraries (each with a different power), XML utilities, and maybe even XML editors. The simplest gain might come from the use of the power and features of the existing general purpose applications that could be leverage by having a well-defined and detailed as possible XML mapping. A second and potentially larger gain might come from the the creation of additional tools, utilities, calendar agents, by anyone who understands and uses the more general purpose XML/DTD formats, because this larger community could create other uses for calendar data. An incidental, but more immediate gain, for the iCalendar standard and its users is that the technical problem of converting between two well defined detailed forms helps to identify any ambiguity which exists in the interpretation of either form. -Paul ---- Myriad Genetics: http://www.myriad.com/ Java FAQ: http://www.afu.com/javafaq.html (Section 9, Computer Dating) From owner-ietf-calendar Fri Jan 7 08:46:38 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA09917 for ietf-calendar-bks; Fri, 7 Jan 2000 08:46:38 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09913 for ; 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 Fri Jan 7 13:44:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13156 for ietf-calendar-bks; Fri, 7 Jan 2000 13:44:21 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13152 for ; 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: 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 Sat Jan 8 23:59:57 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA03043 for ietf-calendar-bks; Sat, 8 Jan 2000 23:59:57 -0800 (PST) Received: from royer.com (royer.com [207.177.146.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03039 for ; 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 Sun Jan 9 23:34:50 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA00502 for ietf-calendar-bks; Sun, 9 Jan 2000 23:34:50 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00498 for ; 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-Transfer-Encoding: 7bit Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------389BB734DED745F683BAB7C9-- --------------msF914FF377866CEBD644A89C6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMTEwMDczNTAzWjAjBgkqhkiG9w0BCQQxFgQUiy0lJUek Uly3ucQIyR+OpHBEUMUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYC4VQv2c/EmEVRynPODok/nvDQsBmPZY4ON+RLQ/jCWqBc7fUSpQyTEP0mGJPqI L4ax+mvEy9vc3hSsuZRal6zCstXr3Ty2gM31exQWG2fV69CynuTSrgT2YngVQuoK3FvyuzRy b4fRQ4t14ynLiW1vpoGW3CPUI2oZundxgY3d3A== --------------msF914FF377866CEBD644A89C6-- From owner-ietf-calendar Mon Jan 10 01:37:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA01831 for ietf-calendar-bks; Mon, 10 Jan 2000 01:37:48 -0800 (PST) Received: from titan.exoffice.com (IDENT:root@host98.ridgeventures.com [207.33.160.98] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01824 for ; 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: >> >> > >> > 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 Mon Jan 10 06:26:36 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA07750 for ietf-calendar-bks; Mon, 10 Jan 2000 06:26:36 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07746 for ; 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 Tue Jan 11 07:48:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA01929 for ietf-calendar-bks; Tue, 11 Jan 2000 07:48:03 -0800 (PST) Received: from klaymen.rim.net (mail.rim.net [206.51.26.155]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01925 for ; 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 Tue Jan 11 09:24:58 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03356 for ietf-calendar-bks; Tue, 11 Jan 2000 09:24:58 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03352 for ; 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 Tue Jan 11 12:19:51 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05793 for ietf-calendar-bks; Tue, 11 Jan 2000 12:19:51 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05789 for ; 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 Tue Jan 11 17:07:36 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA09909 for ietf-calendar-bks; Tue, 11 Jan 2000 17:07:36 -0800 (PST) Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09905 for ; 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-Transfer-Encoding: 7bit Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------2DCF1DEF86BF593BFA130EEF-- --------------ms97A31D930FCD5A1F7EC7CCC4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjAxMDY1NlowIwYJKoZIhvcNAQkEMRYEFNEE 3NEEOHu5JtUW/FH71l+ZpV8SMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAd675VnGixpbSGM7iuNy1Rm/YOh3tVQTE+AGPtPdg2zxxsHBixy3WkAe9 9oIOCeDQLNwG/6DR7LHjpihi6uKHmeXXBlPweE2P4oLSearQAQGk5d04uo3ao2MtALA/Bthr RNfNUs0xjr+99mqVT+6n6MmskuL3MWcVYK24cMsYISA= --------------ms97A31D930FCD5A1F7EC7CCC4-- From owner-ietf-calendar Tue Jan 11 16:55:11 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA09677 for ietf-calendar-bks; Tue, 11 Jan 2000 16:55:11 -0800 (PST) Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09673 for ; 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-Transfer-Encoding: 7bit Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------5231E40C72AF3EE718BF8506-- --------------msEA48C6DBAB54887547F5B1CF Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjAwNTQzMFowIwYJKoZIhvcNAQkEMRYEFHOV IggqORDC/+99BpIRrifBXFzgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGATTd2FgLaP8anjkAh81Y1h4Rsx52oZVs5v+hnzoKb1gS1hOPcgrnrt/TU T3gmJW5uHot4UdzIzs1wergUOX61/rp+pWREmcMlXE7J7Yf8LDRG5AyWrQaoviD37TEDSY7h nTNNGkmV9sTcQp8t3maABRUWJMUSnzk35hXt+s/8aLU= --------------msEA48C6DBAB54887547F5B1CF-- From owner-ietf-calendar Tue Jan 11 17:14:17 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA09993 for ietf-calendar-bks; Tue, 11 Jan 2000 17:14:17 -0800 (PST) Received: from mta2biz.bizmailsrvcs.net (mta2.bizmailsrvcs.net [206.46.164.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09989 for ; 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-Transfer-Encoding: 7bit Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.Royer.vcf" begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard --------------79333BB6841B3CD25F04FAEF-- --------------ms35360E07EA2B2696B970F636 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKqAYJKoZIhvcNAQcCoIIKmTCCCpUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDQwggT+MIIEZ6ADAgECAhBl7gyT3UZovE64xpywm+8XMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAxNDAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBANGG+dlmhZdBRRjddV3pldzlJmbWDAnn5lJkEbEMGIgrpxSZItutVbcCUgZBxvAh PBgYH+dUD8Ie2U7LzGK2RBdDwmrlXIv5Pgoth+RGamAUAezC6H4IrY4GKyrvW0rx0zkzL8cI IUW/AbM4NYQ5tZTnAMm1aIPSy94WDDBkdNWxAgMBAAGjggGPMIIBizAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2ZDQ2NTJi ZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5NzAx NzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NmJmNWQ3MTE0OTljYTNiZTQ3ZjVmM2Vh NDU2NDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEu Y3JsMA0GCSqGSIb3DQEBBAUAA4GBADZReXSdPqp40mRQsZGmFbKYLB2BkIicaNb7bM04QFm2 4ThN5byjHnJNCk0PNwmo08xgFAx5J3PKSlniX5GP0QFxV0eUUv9SrVL8sS8pw1vKO3bUGT9o /X0FA662nqkpfrU6FzHDPW9yf0YCcT+Z7rF/S//WjrUix2BElqRKGaihMIIDLjCCApegAwIB AgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAx IENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp25 8Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSI T4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEG CWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUH AgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADAL BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd 08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9 yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggI8 MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQZe4Mk91GaLxOuMacsJvvFzAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDExMjAxMTMzN1owIwYJKoZIhvcNAQkEMRYEFJyD bzEk9xdR+87FoY6X+t++7Z3mMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIGAlZD0bR4rv2BJnjXD+GIvA+sIFfzmeqYKOGY61XVvt/KL5t6PcorjgtNx uKZbRb/ZkRGorg+VaYo8pBpOcGan1i7JFx0sgC1g05sdyNItfW65XP7l1bVRIK7u3BjQ2o3T WVqI+u5RE+1U4LWfIQxImqRpPKEhlitT7bNjcrtg7Qg= --------------ms35360E07EA2B2696B970F636-- From owner-ietf-calendar Wed Jan 12 06:57:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16311 for ietf-calendar-bks; Wed, 12 Jan 2000 06:57:52 -0800 (PST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16307 for ; 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: Subject: Date: Wed, 12 Jan 2000 09:59:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01BF5CE3.B8C51AC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: