From owner-ietf-calendar@imc.org Tue Feb 1 10:56:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22968 for ; Tue, 1 Feb 2000 10:56:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA02363 for ietf-calendar-bks; Tue, 1 Feb 2000 07:30:37 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02357 for ; Tue, 1 Feb 2000 07:30:35 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA31236 for ; Tue, 1 Feb 2000 10:34:46 -0500 Message-ID: <3896FD16.5B05553D@ecal.com> Date: Tue, 01 Feb 2000 10:34:46 -0500 From: John Stracke X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: forced VCAR (was: revised security section) References: <4.2.0.58.20000127153336.01ab19d0@po12.mit.edu> <4.2.0.58.20000128171434.01ab9ee8@po12.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Paul B. Hill" wrote: > No that I think about it even more, is this subject appropriate for the > draft at all? It would never appear as a part of the protocol on the wire, > right? It might, if the protocol provides a way for an admin to set it. (Of course, then you have to have access control on who gets to be an admin...) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |A mime is a wonderful thing to waste. | |francis@ecal.com| | \==============================================================/ From owner-ietf-calendar@imc.org Tue Feb 1 13:51:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28691 for ; Tue, 1 Feb 2000 13:51:46 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA09041 for ietf-calendar-bks; Tue, 1 Feb 2000 10:16:47 -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 KAA09037 for ; Tue, 1 Feb 2000 10:16:45 -0800 (PST) Received: from Software.com ([207.175.94.72]) by mta2biz.bizmailsrvcs.net with ESMTP id <20000201181830.CIRX7149699.mta2biz.bizmailsrvcs.net@Software.com>; Tue, 1 Feb 2000 12:18:30 -0600 Message-ID: <389722BE.68024C5F@Software.com> Date: Tue, 01 Feb 2000 10:15:26 -0800 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: forced VCAR (was: revised security section) References: <4.2.0.58.20000127153336.01ab19d0@po12.mit.edu> <4.2.0.58.20000128171434.01ab9ee8@po12.mit.edu> <3896FD16.5B05553D@ecal.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC9D2B406051FA498B8473C53" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msC9D2B406051FA498B8473C53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > "Paul B. Hill" wrote: > > > No that I think about it even more, is this subject appropriate for the > > draft at all? It would never appear as a part of the protocol on the wire, > > right? > > It might, if the protocol provides a way for an admin to set it. > (Of course, then you have to have access control on who gets to > be an admin...) It also might be useful if you want to see what VCARs existed (assuming you had access). So you could write an GUI that displayed the data. It might be useful to know that you could NEVER change this one. It could still be a standard VCAR that is read-only. I can see a virtical appliacion or site specific need to never allow anyone to modify some accesses. A very thin virtical application server may wish to never allow any changes to any VCARs. They just might hardcode them in ROM. It could be usfull for a client to know that before trying to change them. I could go ether way (having a way to do this or not) Recient XML-iCal email has convinced me that we need to visably open up our discussions to allow standards and interoperable extensions. I think that we may have been too focused on CAP. The iCalendar extension could in time greatly outnumber the RFC-2445 and CAP values. Time for a ical-extensions mailing list? -Doug --------------msC9D2B406051FA498B8473C53 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKKgYJKoZIhvcNAQcCoIIKGzCCChcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggHQMIIBzAIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDIwMTE4MTUzMFowIwYJKoZIhvcNAQkEMRYEFItnGnHnHM5BK8oyq4Dzp6RNbWvV MCcGCSqGSIb3DQEJDzEaMBgwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEQOQ7Gt6t3g1gVJGSI/9mDqz2PkbRTINtVTAPeS/agCwMOmx0NhpP3mWfjLwG+BYeXptF oTtN5jzV7rKV6SRKLvk= --------------msC9D2B406051FA498B8473C53-- From owner-ietf-calendar@imc.org Tue Feb 1 18:58:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10073 for ; Tue, 1 Feb 2000 18:58:10 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA25884 for ietf-calendar-bks; Tue, 1 Feb 2000 15:16:25 -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 PAA25878 for ; Tue, 1 Feb 2000 15:16:23 -0800 (PST) Received: from Software.com ([207.175.94.72]) by mta2biz.bizmailsrvcs.net with ESMTP id <20000201231810.CMPZ7149699.mta2biz.bizmailsrvcs.net@Software.com>; Tue, 1 Feb 2000 17:18:10 -0600 Message-ID: <389768FD.47000C98@Software.com> Date: Tue, 01 Feb 2000 15:15:09 -0800 From: Doug Royer Reply-To: Doug.Royer@software.com Organization: Software.com X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: IANA and timezones. Content-Type: multipart/mixed; boundary="------------F3147C65E98125E279999238" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F3147C65E98125E279999238 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As I stated in DC, I have resumed the timezone database work. I have ftp'd the latest timezone information and I can now convert the Olson database into VTIMEZONE information. Soon I am going to need some help checking the accuracy of the conversion. If you would like to help, please email me, I have setup a local alias we can use for checking the output and debugging the code, prior to releasing all of this to the WG. It is running on the following UNIX platforms: SunOS, HP-UX, IRIX, AIX, OSF1 If someone with experience with any other OS would like to make sure the code compiles on their platform - email me and maybe we can get it working on more OS's. I'll have the original database, and a conversion tool that (including source code) that is derived from the tools provided with the Olson database. The source code and input files will be available for FTP download. The output is rfc2445.txt compliant VTIMEZONE data. I have heard that IANA has volunteered to host the VTIMEZONE database. And they have assumed the responsibility of determining how to update the information and how to determine the responsible source for the information. Attached is an HTML document included with the source: --------------F3147C65E98125E279999238 Content-Type: text/html; charset=us-ascii; name="tz-link.htm" Content-Disposition: inline; filename="tz-link.htm" Content-Transfer-Encoding: 7bit Sources for Time Zone and Daylight Saving Time Data

Sources for Time Zone and Daylight Saving Time Data

@(#)tz-link.htm 7.20

Paul Eggert writes:

The public-domain tz database contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to UTC offsets and daylight-saving rules. This database (often called zoneinfo) is used by several implementations, including BSD, DJGPP, GNU/Linux, HP-UX, IRIX, Solaris, and UnixWare. In the tz database's FTP distribution, the code is in the file tzcodeC.tar.gz, where C is the code's version; similarly, the data are in tzdataD.tar.gz, where D is the data's version.

The GNU C Library has an independent, thread-safe implementation of a time zone file reader that is compatible with zoneinfo. This library is freely available under the GNU Library General Public License, and is widely used in GNU/Linux systems.

The Web has several other sources for time zone and daylight saving time data. Here are some recent links that may be of interest.

-- eggert@twinsun.com (2000-01-10)

Arthur David Olson writes:

A good source of information about ISO 8601 seems to be International Standard Date and Time Notation maintained by Markus Kuhn.

-- arthur_david_olson@nih.gov (1996-01-04)

--------------F3147C65E98125E279999238-- From owner-ietf-calendar@imc.org Wed Feb 2 11:52:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14875 for ; Wed, 2 Feb 2000 11:52:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16605 for ietf-calendar-bks; Wed, 2 Feb 2000 08:20:13 -0800 (PST) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16599 for ; Wed, 2 Feb 2000 08:20:09 -0800 (PST) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA26923; Wed, 2 Feb 00 11:21:55 EST Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id LAA13071; Wed, 2 Feb 2000 11:22:27 -0500 (EST) Received: from miles-davis (dialtus1-107.rtd.com [216.19.0.107]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id LAA16779; Wed, 2 Feb 2000 11:22:25 -0500 (EST) Message-Id: <4.2.0.58.20000202111223.023384a8@po12.mit.edu> X-Sender: pbh@po12.mit.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 02 Feb 2000 11:18:15 -0500 To: John Stracke , ietf-calendar@imc.org From: "Paul B. Hill" Subject: Re: forced VCAR (was: revised security section) In-Reply-To: <3896FD16.5B05553D@ecal.com> References: <4.2.0.58.20000127153336.01ab19d0@po12.mit.edu> <4.2.0.58.20000128171434.01ab9ee8@po12.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, When the scope of CAP was being worked on there seemed to be general consensus that CAP would not be a protocol that supported CS administration. Obviously there has to be some CS administration support. To date the method used to decide what goes in and what gets punted has been the question, "Will customers expect that typical individual users need to perform this task?" IMHO setting an enforceable CS policy fails the test that we have been using, therefore CAP should not address this topic. Paul > > No that I think about it even more, is this subject appropriate for the > > draft at all? It would never appear as a part of the protocol on the wire, > > right? > >It might, if the protocol provides a way for an admin to set it. (Of course, >then you have to have access control on who gets to be an admin...) From owner-ietf-calendar@imc.org Wed Feb 2 13:20:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17359 for ; Wed, 2 Feb 2000 13:19:57 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA19979 for ietf-calendar-bks; Wed, 2 Feb 2000 09:53:28 -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 JAA19975 for ; Wed, 2 Feb 2000 09:53:26 -0800 (PST) Received: from Software.com ([207.175.94.72]) by mta2biz.bizmailsrvcs.net with ESMTP id <20000202175517.CUNP7149699.mta2biz.bizmailsrvcs.net@Software.com> for ; Wed, 2 Feb 2000 11:55:17 -0600 Message-ID: <38986EC5.8D356AED@Software.com> Date: Wed, 02 Feb 2000 09:52:05 -0800 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: forced VCAR (was: revised security section) References: <4.2.0.58.20000127153336.01ab19d0@po12.mit.edu> <4.2.0.58.20000128171434.01ab9ee8@po12.mit.edu> <4.2.0.58.20000202111223.023384a8@po12.mit.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC011839B4D17B7B2A767A828" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msC011839B4D17B7B2A767A828 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Paul B. Hill" wrote: > > Hi, > > When the scope of CAP was being worked on there seemed to be general > consensus that CAP would not be a protocol that supported CS administration. Good point. > Obviously there has to be some CS administration support. To date the > method used to decide what goes in and what gets punted has been the > question, "Will customers expect that typical individual users need to > perform this task?" No I don't think so. > IMHO setting an enforceable CS policy fails the test that we have been > using, therefore CAP should not address this topic. -Doug --------------msC011839B4D17B7B2A767A828 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKKgYJKoZIhvcNAQcCoIIKGzCCChcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggHQMIIBzAIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDIwMjE3NTIwN1owIwYJKoZIhvcNAQkEMRYEFIO8gdr9mPDv4wEqT4DXYQHa+ly+ MCcGCSqGSIb3DQEJDzEaMBgwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEQN2cnL0IabIQTPjFhxw5SlVX8MI7GewX9bNAjbU036Grd91WZOIJMlMgLUMdlcY0ndxo rktC/1GEwNPL6+9wag4= --------------msC011839B4D17B7B2A767A828-- From owner-ietf-calendar@imc.org Wed Feb 2 20:50:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24760 for ; Wed, 2 Feb 2000 20:49:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA28254 for ietf-calendar-bks; Wed, 2 Feb 2000 17:18:05 -0800 (PST) Received: from mcncmdm1exims2.marriott.com (host037.marriott.com [162.130.1.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA28249 for ; Wed, 2 Feb 2000 17:18:04 -0800 (PST) Received: from PickupDirectory by mcncmdm1exims2.marriott.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1F6H5THN; Wed, 2 Feb 2000 18:35:02 -0500 Received: FROM ns.secondary.com BY mcncmdm1exims2.marriott.com ; Wed Feb 02 12:06:35 2000 -0500 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16605 for ietf-calendar-bks; Wed, 2 Feb 2000 08:20:13 -0800 (PST) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16599 for ; Wed, 2 Feb 2000 08:20:09 -0800 (PST) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA26923; Wed, 2 Feb 00 11:21:55 EST Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id LAA13071; Wed, 2 Feb 2000 11:22:27 -0500 (EST) Received: from miles-davis (dialtus1-107.rtd.com [216.19.0.107]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id LAA16779; Wed, 2 Feb 2000 11:22:25 -0500 (EST) Message-Id: <4.2.0.58.20000202111223.023384a8@po12.mit.edu> X-Sender: pbh@po12.mit.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 02 Feb 2000 11:18:15 -0500 To: John Stracke , ietf-calendar@imc.org From: "Paul B. Hill" Subject: Re: forced VCAR (was: revised security section) In-Reply-To: <3896FD16.5B05553D@ecal.com> References: <4.2.0.58.20000127153336.01ab19d0@po12.mit.edu> <4.2.0.58.20000128171434.01ab9ee8@po12.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, When the scope of CAP was being worked on there seemed to be general consensus that CAP would not be a protocol that supported CS administration. Obviously there has to be some CS administration support. To date the method used to decide what goes in and what gets punted has been the question, "Will customers expect that typical individual users need to perform this task?" IMHO setting an enforceable CS policy fails the test that we have been using, therefore CAP should not address this topic. Paul > > No that I think about it even more, is this subject appropriate for the > > draft at all? It would never appear as a part of the protocol on the wire, > > right? > >It might, if the protocol provides a way for an admin to set it. (Of course, >then you have to have access control on who gets to be an admin...) From owner-ietf-calendar@imc.org Wed Feb 2 22:49:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27803 for ; Wed, 2 Feb 2000 22:49:43 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA06310 for ietf-calendar-bks; Wed, 2 Feb 2000 19:12:26 -0800 (PST) Received: from mcncmdm1exims2.marriott.com (host037.marriott.com [162.130.1.37]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA06302 for ; Wed, 2 Feb 2000 19:12:23 -0800 (PST) Received: from PickupDirectory by mcncmdm1exims2.marriott.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1F903K5B; Wed, 2 Feb 2000 20:19:59 -0500 Received: FROM ns.secondary.com BY mcncmdm1exims2.marriott.com ; Tue Feb 01 14:09:47 2000 -0500 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA09041 for ietf-calendar-bks; Tue, 1 Feb 2000 10:16:47 -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 KAA09037 for ; Tue, 1 Feb 2000 10:16:45 -0800 (PST) Received: from Software.com ([207.175.94.72]) by mta2biz.bizmailsrvcs.net with ESMTP id <20000201181830.CIRX7149699.mta2biz.bizmailsrvcs.net@Software.com>; Tue, 1 Feb 2000 12:18:30 -0600 Message-ID: <389722BE.68024C5F@Software.com> Date: Tue, 01 Feb 2000 10:15:26 -0800 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: Software.com X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: forced VCAR (was: revised security section) References: <4.2.0.58.20000127153336.01ab19d0@po12.mit.edu> <4.2.0.58.20000128171434.01ab9ee8@po12.mit.edu> <3896FD16.5B05553D@ecal.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC9D2B406051FA498B8473C53" List-Archive: List-ID: List-Unsubscribe: Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msC9D2B406051FA498B8473C53 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > "Paul B. Hill" wrote: > > > No that I think about it even more, is this subject appropriate for the > > draft at all? It would never appear as a part of the protocol on the wire, > > right? > > It might, if the protocol provides a way for an admin to set it. > (Of course, then you have to have access control on who gets to > be an admin...) It also might be useful if you want to see what VCARs existed (assuming you had access). So you could write an GUI that displayed the data. It might be useful to know that you could NEVER change this one. It could still be a standard VCAR that is read-only. I can see a virtical appliacion or site specific need to never allow anyone to modify some accesses. A very thin virtical application server may wish to never allow any changes to any VCARs. They just might hardcode them in ROM. It could be usfull for a client to know that before trying to change them. I could go ether way (having a way to do this or not) Recient XML-iCal email has convinced me that we need to visably open up our discussions to allow standards and interoperable extensions. I think that we may have been too focused on CAP. The iCalendar extension could in time greatly outnumber the RFC-2445 and CAP values. Time for a ical-extensions mailing list? -Doug --------------msC9D2B406051FA498B8473C53 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKKgYJKoZIhvcNAQcCoIIKGzCCChcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CCIwggTsMIIEVaADAgECAhA2tOutfntkPZeWwhSMC60VMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDExNzAwMDAw MFoXDTAwMTAxMzIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEmMCQGCSqG SIb3DQEJARYXZG91Zy5yb3llckBzb2Z0d2FyZS5jb20wXDANBgkqhkiG9w0BAQEFAANLADBI AkEA8b+/7AusCQc89McoXWlPBDcEaOyt/e2NdL+lPypsoauWxoLohWrk708y93xfziOVZ/Jh 3yF9Dq43K9rW9m8SewIDAQABo4IBwTCCAb0wCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5Mjk4 NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIxNDFi ZWFkYjJiZDJlODkyMWZhODZiZjFkMTExNDk5ZmEzYmE0N2ZkZjNlYTQ1MDYwMAYKYIZIAYb4 RQEGBwQiFiA2NWVlMGM5M2RkNDY2OGJjNGViOGM2OWNiMDliZWYxNzAzBgNVHR8ELDAqMCig JqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUA A4GBAIfiBv6wsXfERKczHkNCZ3zPRgSs/eOEutA2lnTtejz+sHTm3XWcEEx0zcEkYafFIOCK GFgFsy6cR4czApnWlILPzDAyT+FcDsAqTtSGDL8jTVMo/7MW6CHReAc0oSzGtapMxWcLgaMh /D0lM5vSddVM7EgNhGLWQPoAvxKe4PExMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/u DXUwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQL Ez13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFC LkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vi c2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBH BgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZI hvcNAQECBQADgYEAiLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmF pJXxF31ntH8tLN2aQp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8 kFxVo2UgAP0YIOVfgqaxqJLFWGrBjQM868PNBaKQrm4xggHQMIIBzAIBATCB4TCBzDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx RjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBS ZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNrTrrX57ZD2XlsIUjAut FTAJBgUrDgMCGgUAoIGGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAwMDIwMTE4MTUzMFowIwYJKoZIhvcNAQkEMRYEFItnGnHnHM5BK8oyq4Dzp6RNbWvV MCcGCSqGSIb3DQEJDzEaMBgwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEQOQ7Gt6t3g1gVJGSI/9mDqz2PkbRTINtVTAPeS/agCwMOmx0NhpP3mWfjLwG+BYeXptF oTtN5jzV7rKV6SRKLvk= --------------msC9D2B406051FA498B8473C53-- From owner-ietf-calendar@imc.org Thu Feb 3 06:52:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13425 for ; Thu, 3 Feb 2000 06:52:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA23478 for ietf-calendar-bks; Thu, 3 Feb 2000 03:33:35 -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 DAA23474 for ; Thu, 3 Feb 2000 03:33:33 -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 GAA14463 for ; Thu, 3 Feb 2000 06:50:59 -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 GAA25977 for ; Thu, 3 Feb 2000 06:35:27 -0500 (EST) To: ietf-calendar@imc.org Subject: Re: forced VCAR (was: revised security section) X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Thu, 3 Feb 2000 06:37:28 -0500 X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 02/03/2000 06:37:32 AM, Serialize complete at 02/03/2000 06:37:32 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 003FED118525687A_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 003FED118525687A_= Content-Type: text/plain; charset="us-ascii" Paul wrote, in part: > IMHO setting an enforceable CS policy fails the test that we have been > using, therefore CAP should not address this topic. I am probably not certain what you completely mean by "enforcable", but Lotus definitely believes that CS VCAR access policy needs to be an initial CAP target for VCAR specification in Version 1. For example, "GRANT View Public Entries" or "GRANT View Busy Time Information" or "GRANT Create and Update Public Entries" or "DENY Create, Update and Delete Entries". -- Frank --=_alternative 003FED118525687A_= Content-Type: text/html; charset="us-ascii"
Paul wrote, in part:

> IMHO setting an enforceable CS policy fails the test that we have been
> using, therefore CAP should not address this topic.
I am probably not certain what you completely mean by "enforcable", but Lotus definitely believes that CS VCAR access policy needs to be an initial CAP target for VCAR specification in Version 1.

For example, "GRANT View Public Entries" or "GRANT View Busy Time Information" or "GRANT Create and Update Public Entries" or "DENY Create, Update and Delete Entries".

-- Frank

--=_alternative 003FED118525687A_=-- From owner-ietf-calendar@imc.org Thu Feb 3 12:04:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23055 for ; Thu, 3 Feb 2000 12:04:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA00792 for ietf-calendar-bks; Thu, 3 Feb 2000 08:23:21 -0800 (PST) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA00787 for ; Thu, 3 Feb 2000 08:23:18 -0800 (PST) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA25846; Thu, 3 Feb 00 11:25:04 EST Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id LAA00264; Thu, 3 Feb 2000 11:25:37 -0500 (EST) Received: from miles-davis (dialtus1-170.rtd.com [216.19.0.170]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id LAA18408; Thu, 3 Feb 2000 11:25:34 -0500 (EST) Message-Id: <4.2.0.58.20000203110409.01dbbf10@po12.mit.edu> X-Sender: pbh@po12.mit.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 03 Feb 2000 11:22:55 -0500 To: Frank_Dawson@lotus.com, ietf-calendar@imc.org From: "Paul B. Hill" Subject: Re: forced VCAR (was: revised security section) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Frank, I can't figure out if we agree or disagree yet. I suspect that we actually agree, please read on. >> IMHO setting an enforceable CS policy fails the test that we have been >> using, therefore CAP should not address this topic. >I am probably not certain what you completely mean by "enforcable", but Lotus definitely >believes that CS VCAR access policy needs to be an initial CAP target for VCAR specification >in Version 1. OK, "enforceable" was a poor term to use. Maybe "imposed", "decreed", "established by edict" are better terms to describe the concept. The idea, as I understood it, was that a CS MAY choose to implement and allow persistent immutable VCARs, that are configured by the CS Administrator, which apply to all calendars on the server. For example a company may decide that it wants all calendars on its server(s) to have the Policy READBUSYTIMEINFO. >For example, "GRANT View Public Entries" or "GRANT View Busy Time Information" or "GRANT >Create and Update Public Entries" or "DENY Create, Update and Delete Entries". But aren't you talking about the end user performing these operations on calendars that they control? I'm talking about the case where a CS implementation allows the CS admin to impose "GRANT READBUSYTIMEINFO" to all calendars. If a user subsequently attempts to modify this to "DENY READBUSYTIMEINFO" on a specific calendar an error will be returned to the user. First, I do not think that all CSes must be required to implement the ability to create global immutable VCARs. I think this is a feature that each CS vendor should be free to implement or not. Second, I do not think that the CAP protocol needs to define how the CS admin would communicate with the CS to enact or create a global immutable VCAR by decree. Paul From owner-ietf-calendar@imc.org Thu Feb 3 12:33:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24210 for ; Thu, 3 Feb 2000 12:33:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01847 for ietf-calendar-bks; Thu, 3 Feb 2000 09:10:03 -0800 (PST) Received: from pivsbh1.ms.com (pivsbh1.ms.com [199.89.64.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01843 for ; Thu, 3 Feb 2000 09:10:02 -0800 (PST) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id MAA27022; Thu, 3 Feb 2000 12:12:23 -0500 (EST) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9495979301.026392; Thu, 3 Feb 00 12:12:10 -0500 Received: by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id MAA26385; Thu, 3 Feb 2000 12:12:10 -0500 (EST) X-Authentication-Warning: pivsbh1.ms.com: Processed from queue /var/spool/mqueue-vs X-Authentication-Warning: pivsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf X-Interface: IDMZ Received: from sasmh4.ms.com(144.14.193.5) by pivsbh1 via smap (4.1) id sma.9495979271.026243; Thu, 3 Feb 00 12:12:07 -0500 Received: from msdw.com (hqdsl26.morgan.com [205.228.1.26]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id MAA27194; Thu, 3 Feb 2000 12:12:07 -0500 (EST) Message-ID: <3899B6E8.7D2CFB9F@msdw.com> Date: Thu, 03 Feb 2000 12:12:08 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: "Paul B. Hill" CC: Frank_Dawson@lotus.com, ietf-calendar@imc.org Subject: Re: forced VCAR (was: revised security section) References: <4.2.0.58.20000203110409.01dbbf10@po12.mit.edu> Content-Type: multipart/mixed; boundary="------------9D61D8DE0216C9743244A2F5" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------9D61D8DE0216C9743244A2F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I'm talking about the case where a CS implementation allows the CS admin to > impose "GRANT READBUSYTIMEINFO" to all calendars. If a user subsequently > attempts to modify this to "DENY READBUSYTIMEINFO" on a specific calendar > an error will be returned to the user. This error should be clear that it's because the server is forcing this, not just a permission denied. > First, I do not think that all CSes must be required to implement the > ability to create global immutable VCARs. I think this is a feature that > each CS vendor should be free to implement or not. Agreed, though a "PLEASE" would be nice. > Second, I do not think that the CAP protocol needs to define how the CS admin > would communicate with the CS to enact or create a global immutable VCAR by > decree. Agreed. There's no need for CAP to define this, it's probably defined in a text file on the server. I liked Doug's point that it would be good for the CUA to know that it won't be able to modify this particular VCAR though. Unless anyone else has something to say, I think we're done with the issue and just need to write some text. Thanks, dmadeo --------------9D61D8DE0216C9743244A2F5 Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;fax:212-762-1009 tel;work:212-762-2348 x-mozilla-html:FALSE url:www.ms.com org:Morgan Stanley Dean Witter and Discover;Information Technology version:2.1 email;internet:dmadeo@ms.com adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA x-mozilla-cpt:;0 fn:David Madeo end:vcard --------------9D61D8DE0216C9743244A2F5-- From owner-ietf-calendar@imc.org Thu Feb 3 13:52:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26656 for ; Thu, 3 Feb 2000 13:52:31 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA03764 for ietf-calendar-bks; Thu, 3 Feb 2000 10:31:34 -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 KAA03760 for ; Thu, 3 Feb 2000 10:31:32 -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 KAA11617 for ; Thu, 3 Feb 2000 10:33:47 -0800 (PST) Message-ID: <3899CA0A.68B76E7A@home.royer.com> Date: Thu, 03 Feb 2000 10:33:46 -0800 From: Doug Royer Reply-To: ietf-calendar@imc.org X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: forced VCAR (was: revised security section) References: <4.2.0.58.20000203110409.01dbbf10@po12.mit.edu> <3899B6E8.7D2CFB9F@msdw.com> Content-Type: multipart/mixed; boundary="------------C3A6C975E05A310AE30A9E9E" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C3A6C975E05A310AE30A9E9E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Madeo wrote: > > > I'm talking about the case where a CS implementation allows the CS admin to > > impose "GRANT READBUSYTIMEINFO" to all calendars. If a user subsequently > > attempts to modify this to "DENY READBUSYTIMEINFO" on a specific calendar > > an error will be returned to the user. > > This error should be clear that it's because the server is forcing this, not > just a permission denied. After thinking about this more ... If a CS implementation wishes to force a VCAR, it simply tells everyone by exporting (when asked) a valid VCAR that disallows changes. --> There is no need for the READ-ONLY text that I sent out earlier. To a CU - what's the difference? They will have a VCAR that dis-allows them to modify their VCAR as in this example VCAR that disallows itslef to be changed and defines that VFREEBUSY is readable: BEGIN:VCAR CARID:Forced VFREEBUSY access to READ DENY:UPN=all;OBJECT=VCAR ;OBJECT=CARID;VALUE="Forced VFREEBUSY access to READ" ;ACCESS=DELETE,MODIFY GRANT:UPN=all;OBJECT=VFREEBUSY;ACCESS=READ END:VCAR It grants read accesss to VFREEBUSY, and denies any user from changing it So if this VCAR exists, what is the difference to a CU or CUA if it is FORCED or NOT? --------------C3A6C975E05A310AE30A9E9E Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------C3A6C975E05A310AE30A9E9E-- From owner-ietf-calendar@imc.org Thu Feb 3 14:40:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28095 for ; Thu, 3 Feb 2000 14:40:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA04914 for ietf-calendar-bks; Thu, 3 Feb 2000 11:21:44 -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 LAA04910 for ; Thu, 3 Feb 2000 11:21:42 -0800 (PST) Received: from home.royer.com (home.royer.com [63.195.80.50]) by royer.com (8.9.1/8.9.1) with SMTP id LAA05398 for ; Thu, 3 Feb 2000 11:24:08 -0800 (PST) Message-Id: <200002031924.LAA05398@royer.com> Date: Thu, 3 Feb 2000 11:24:08 -0800 (PST) From: Doug Royer Reply-To: Doug Royer Subject: CAP draft notes To: ietf-calendar@imc.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Flight_of_Swallows_590_000 X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Flight_of_Swallows_590_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mMtRfVLNi15txWQJbtg46g== Two things we need to fix in the CAP draft. 1) We have 2 ways to do wildcard '*' and 'all'. As in UPN=all and OBJECT=* I would suggest we use * everywhere to mean all. Any objections? 2) 'rightsparam' is never defined, but used to define 'GRANT' and 'DENY' ABNF. I'll fix this to point to the correct ABNF already in CAP. --Flight_of_Swallows_590_000 Content-Type: TEXT/plain; name="doug.vcf"; charset=us-ascii Content-Description: doug.vcf Content-MD5: TwWgNWdEaUAozY3crQV6PQ== 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 --Flight_of_Swallows_590_000-- From owner-ietf-calendar@imc.org Thu Feb 3 19:02:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02387 for ; Thu, 3 Feb 2000 19:02:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA08328 for ietf-calendar-bks; Thu, 3 Feb 2000 15:44:19 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08323 for ; Thu, 3 Feb 2000 15:44:17 -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 PAA12782; Thu, 3 Feb 2000 15:46:39 -0800 (PST) Message-ID: <389A135E.5CF166CF@home.royer.com> Date: Thu, 03 Feb 2000 15:46:38 -0800 From: Doug Royer Reply-To: timezones.external-owner@software.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org, tz@elsie.nci.nih.gov Subject: [Fwd: New Mail List - timezones.external@software.com] Content-Type: multipart/mixed; boundary="------------878F08381ECFB69A59562714" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------878F08381ECFB69A59562714 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The timezones.external@software.com list is for public discussion of timezone information. IANA as part of the IETF is looking into administrating the names of world wide time zones. This list will be an alias of IETF and non-IETF participants interested in porting the 'zic' software and its data format. There are three goals of this list. 1) Port the government database and 'zic' (Zone Information Compiler) to other OS's and have it also provide the data in VTIMEZONE format. Most UNIX's use the government database format and the zic compiler (man zic). 2) Convert the government database into VTIMEZONE records for IANA to administer. 3) Give away the results to the public domain. And if someone want to volunteer - make a converter to go from VTIMEZONE format to zic input format to keep the databases in sync. This list will go away after the above 3 these goals have been met. RFC-2445 defines VTIMEZONE. The government database source, zic source, and other related source is available from: ftp://elsie.nci.nih.gov/pub ----------------------------------------------------------------- To subscribe, send mail to timezones.external-request@software.com with 'subscribe' in the body of the message. ----------------------------------------------------------------- --------------878F08381ECFB69A59562714 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------878F08381ECFB69A59562714-- From owner-ietf-calendar@imc.org Thu Feb 3 21:55:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05000 for ; Thu, 3 Feb 2000 21:55:55 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA13360 for ietf-calendar-bks; Thu, 3 Feb 2000 18:32:25 -0800 (PST) Received: from alcor.twinsun.com (alcor.twinsun.com [198.147.65.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA13353 for ; Thu, 3 Feb 2000 18:32:24 -0800 (PST) Received: from shade.twinsun.com ([192.54.239.27]) by alcor.twinsun.com (8.9.3/8.9.3) with ESMTP id SAA29545; Thu, 3 Feb 2000 18:33:37 -0800 (PST) Received: (eggert@localhost) by shade.twinsun.com (8.9.3+Sun/8.9.3) id SAA06484; Thu, 3 Feb 2000 18:31:30 -0800 (PST) Date: Thu, 3 Feb 2000 18:31:30 -0800 (PST) From: Paul Eggert Message-Id: <200002040231.SAA06484@shade.twinsun.com> To: Doug Royer CC: Time Zone mailing list , another Time Zone mailing list , IETF Calendaring and Scheduling Working Group , Antoine.Leca@renault.fr Subject: Re: New Mail List - timezones.external@software.com Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Doug Royer [SMTP:doug@home.royer.com] Sent: Thursday, February 03, 2000 6:47 PM The timezones.external@software.com list is for public discussion of timezone information. How does that mailing list's charter differ from that of tz@elsie.nci.nih.gov, which is a list for public discussion of time zone information that has been in use since 1986? I visited www.software.com, but found no discussion of the new list. How does one join, or view its message archive? IANA as part of the IETF is looking into administrating the names of world wide time zones. How and why will this administration differ from the process already in place for the existing time zone database? 1) Port the government database and 'zic' (Zone Information Compiler) to other OS's and have it also provide the data in VTIMEZONE format. Most UNIX's use the government database format and the zic compiler (man zic). On 1998-07-16 Antoine Leca wrote that he was implementing (1); you might ask him how far he got. 2) Convert the government database into VTIMEZONE records for IANA to administer. Isn't conversion automatic? If so, why would two databases need to be administered separately? One database should be generated automatically from the other. And if someone want to volunteer - make a converter to go from VTIMEZONE format to zic input format to keep the databases in sync. Why would this be necessary, if conversion is automatic? FYI, here is a brief summary of existing sources for time zone data: http://www.twinsun.com/tz/tz-link.htm And here is a copy of the tz mailing list archive: ftp://elsie.nci.nih.gov/pub/tzarchive.gz From owner-ietf-calendar@imc.org Thu Feb 3 23:06:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06889 for ; Thu, 3 Feb 2000 23:06:59 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA17475 for ietf-calendar-bks; Thu, 3 Feb 2000 19:49:15 -0800 (PST) Received: from sam.comms.unsw.EDU.AU (sam.comms.unsw.EDU.AU [149.171.96.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA17468 for ; Thu, 3 Feb 2000 19:49:11 -0800 (PST) Received: from onyx.agsm.edu.au (onyx.agsm.EDU.AU [149.171.216.2]) by sam.comms.unsw.EDU.AU (8.8.8/8.8.8 Kenso-Central-NO-SPAM) with ESMTP id OAA17724; Fri, 4 Feb 2000 14:51:06 +1100 (EST) Received: by onyx.agsm.edu.au (agsm-generic-gf.981008) Fri, 4 Feb 2000 14:46:12 +1000 Message-Id: In-Reply-To: <200002040231.SAA06484@shade.twinsun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Feb 2000 14:50:54 +1100 To: Paul Eggert , Doug Royer From: Alex LIVINGSTON Subject: Re: New Mail List - timezones.external@software.com Cc: Time Zone mailing list , another Time Zone mailing list , IETF Calendaring and Scheduling Working Group , Antoine.Leca@renault.fr Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 18:31 -0800 2000-02-03, Paul Eggert wrote: > From: Doug Royer [SMTP:doug@home.royer.com] > Sent: Thursday, February 03, 2000 6:47 PM [snip] > IANA as part of the IETF is looking into administrating the names > of world wide time zones. What are IANA and the IETF? [snip] > 1) Port the government database and 'zic' (Zone Information > Compiler) to other OSes and have it also provide the > data in VTIMEZONE format. Most UNIXes use the government > database format and the zic compiler (man zic). Which other OSes? What is the VTIMEZONE format? >On 1998-07-16 Antoine Leca wrote that he was >implementing (1); you might ask him how far he got. To which OSes was Antoine porting them and was he also providing the data in VTIMEZONE format? Alex _______________ Alex LIVINGSTON IT, Australian Graduate School of Management (AGSM), Sydney Fax: +61 2 9931-9349 / Phone: +61 2 9931-9264 / Time: UTC + 10 or 11 h. It's the 2000th year, 200th decade, 20th century, and 2nd millennium - the last year of the last decade of the last century of the millennium. (But it's no longer 1999, the 1990s, the 1900s, or the 1000s.) Years since epoch (1-1-1 at 00:00:00) at midday today (Feb. 4): 1999.09238382 Provisional iweaq date: 2000-1g3 (Year-QuarterWeekDay) - day before mid-quarter day, close to northern "rise of spring" (southern "rise of fall"?) From owner-ietf-calendar@imc.org Thu Feb 3 23:53:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07543 for ; Thu, 3 Feb 2000 23:53:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19987 for ietf-calendar-bks; Thu, 3 Feb 2000 20:33:49 -0800 (PST) Received: from inside.intranetics.com (inside.intranetics.com [207.180.88.204]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19981 for ; Thu, 3 Feb 2000 20:33:48 -0800 (PST) Received: from dmerritt_me (214.intranetics.harvard.net [207.180.88.214]) by inside.intranetics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1F1S17D4; Thu, 3 Feb 2000 23:35:38 -0500 Message-Id: <4.2.2.20000203233255.0368a100@inside.intranetics.com> X-Sender: intranetics\dmerritt@inside.intranetics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 03 Feb 2000 23:34:07 -0500 To: Paul Eggert From: "G. Del Merritt" Subject: Re: New Mail List - timezones.external@software.com Cc: Doug Royer , Time Zone mailing list , another Time Zone mailing list , IETF Calendaring and Scheduling Working Group , Antoine.Leca@renault.fr In-Reply-To: <200002040231.SAA06484@shade.twinsun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:31 PM 2/3/00 -0800, Paul Eggert wrote: >I visited www.software.com, but found no discussion of the new list. >How does one join, or view its message archive? Send a message to timezones.external-request@software.com and include the word "subscribe" in the message body. Sorry if I've spoiled a right of passage. The "-request" suffix is pretty standard fare. -- G. Del Merritt dmerritt@intranets.com http://www.intranets.com - Get Everyone on the Same Page(sm) From owner-ietf-calendar@imc.org Fri Feb 4 05:49:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21589 for ; Fri, 4 Feb 2000 05:49:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA29351 for ietf-calendar-bks; Fri, 4 Feb 2000 02:25:07 -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 CAA29346 for ; Fri, 4 Feb 2000 02:25:03 -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 FAA25834; Fri, 4 Feb 2000 05:42:34 -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 FAA12948; Fri, 4 Feb 2000 05:27:01 -0500 (EST) To: "Paul B. Hill" Cc: ietf-calendar@imc.org Subject: Re: forced VCAR (was: revised security section) X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Fri, 4 Feb 2000 05:28:13 -0500 X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 02/04/2000 05:28:14 AM, Serialize complete at 02/04/2000 05:28:15 AM, Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2a |November 23, 1999) at 02/04/2000 05:28:15 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0039A8848525687B_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0039A8848525687B_= Content-Type: text/plain; charset="us-ascii" Yes, we are in agreement. - C&S VCAR Policy specification by the CU is in the CAP. - CAP could specify that an out-of-band method (i.e., not specified by the current CAP draft) could be used to set the VCAR such that a CU can't subsequently change it. - CAP can also specify that a CS can set a calendar-wide VCAR that CUs can't modify. The requirements for such features seem clear. Thank you for taking the time to answer. -- Frank --=_alternative 0039A8848525687B_= Content-Type: text/html; charset="us-ascii"
Yes, we are in agreement.

- C&S VCAR Policy specification by the CU is in the CAP.

- CAP could specify that an out-of-band method (i.e., not specified by the current CAP draft) could be used to set the VCAR such that a CU can't subsequently change it.

- CAP can also specify that a CS can set a calendar-wide VCAR that CUs can't modify.

The requirements for such features seem clear. Thank you for taking the time to answer.

-- Frank --=_alternative 0039A8848525687B_=-- From owner-ietf-calendar@imc.org Fri Feb 4 10:07:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29451 for ; Fri, 4 Feb 2000 10:07:56 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA06484 for ietf-calendar-bks; Fri, 4 Feb 2000 06:45:01 -0800 (PST) Received: from wisbech.cl.cam.ac.uk (exim@mta1.cl.cam.ac.uk [128.232.0.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06477 for ; Fri, 4 Feb 2000 06:44:59 -0800 (PST) Received: from trillium.cl.cam.ac.uk ([128.232.8.5] helo=cl.cam.ac.uk ident=mgk25) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 12Gk16-0005md-00; Fri, 04 Feb 2000 14:47:24 +0000 X-Mailer: exmh version 2.0.2+CL 2/24/98 To: tz@elsie.nci.nih.gov, ietf-calendar@imc.org Cc: Doug Royer Subject: Re: New Mail List - timezones.external@software.com In-reply-to: Your message of "Thu, 03 Feb 2000 18:49:51 EST." <43E124CC389ED111B18D00805FEA1E63067E134E@nihexchange2.nih.gov> X-URL: http://www.cl.cam.ac.uk/~mgk25/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Feb 2000 14:47:22 +0000 From: Markus Kuhn Message-Id: Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Doug Royer : > There are three goals of this list. > > 1) Port the government database and 'zic' (Zone Information Compiler) > to other OS's and have it also provide the data in VTIMEZONE > format. Most UNIX's use the government database format and the zic > compiler (man zic). > > 2) Convert the government database into VTIMEZONE records for IANA > to administer. > > 3) Give away the results to the public domain. There might be a few misunderstandings involved here. First, there is no "government timezone database". What you see on ftp://elsie.nci.nih.gov/pub/ is the collaboration of a number of volunteers (Arthur Olson, Paul Eggert, et al.), the result of which is commonly referred to as the public domain "Olson database". The only relation to the US government is that the group has been using an ftp server of the National Cancer Institute, which happens to be located in the .gov domain. There exists already a well-established mailing list for discussions on time zones and the maintenance of the Olson database, namely tz@elsie.nci.nih.gov Contact tz-request@elsie.nci.nih.go to join the club. Since there is a lot of accumulated expertise on this mailing list, handing over the administration of the database to IANA seems to be a rather dubious buerocratic effort. Who at IANA would take over authority over the database and is really comparably qualified to the current contributors of the Olson database who have done a splendid job for the last 15 years? Please understand that IANA is a registration service, while what the group around Olson is doing is more a detective service that observes and documents the highly complicated world of national and regional decisions about time-zone changes in the world. If government X is going to change its local time zone, it is more likely that the database maintainer will hear about this from various informers or media reports around the world, as well as resources such as IATA or CIA. It is much less likely that the respective countries will report timezone changes directly to IANA officially. A detective service can provide a more accurate representation of the real world than a registration service. Just dropping the maintenance of the time zone database into the responsibility of IANA might give them a task they underestimate at the moment. If you don't like the current zic format, feel free to add a zic-> VTIMEZONE format converter to the Olson package. Looks mostly like a bijective transform to me, except that the zic input files contain a lot of valuable comments that identify official reference documents. Only if the output of that converter on the regular updates of the Olson package turns out to be unsatisfactory, I would start worrying about setting up a parallel bureaucracy and an independent database. I see really no need for yet another mailing list. > RFC-2445 defines VTIMEZONE. BEGIN:VTIMEZONE TZID:US--Fictitious-Eastern LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT BEGIN:DAYLIGHT DTSTART:19990424T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT END:VTIMEZONE If people really think that this looks that much nicer or easier to parse for machines and humans ... Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: From owner-ietf-calendar@imc.org Fri Feb 4 11:59:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02658 for ; Fri, 4 Feb 2000 11:59:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA10454 for ietf-calendar-bks; Fri, 4 Feb 2000 08:26:44 -0800 (PST) Received: from pivsbh1.ms.com (pivsbh1.ms.com [199.89.64.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10450 for ; Fri, 4 Feb 2000 08:26:42 -0800 (PST) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id LAA10076; Fri, 4 Feb 2000 11:28:48 -0500 (EST) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9496817111.009370; Fri, 4 Feb 00 11:28:31 -0500 Received: by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id LAA09355; Fri, 4 Feb 2000 11:28:31 -0500 (EST) X-Authentication-Warning: pivsbh1.ms.com: Processed from queue /var/spool/mqueue-vs X-Authentication-Warning: pivsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf X-Interface: IDMZ Received: from sasmh4.ms.com(144.14.193.5) by pivsbh1 via smap (4.1) id sma.9496817101.009144; Fri, 4 Feb 00 11:28:30 -0500 Received: from msdw.com (hqdsl26.morgan.com [205.228.1.26]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id LAA24747; Fri, 4 Feb 2000 11:28:29 -0500 (EST) Message-ID: <389AFE2E.1C5D640@msdw.com> Date: Fri, 04 Feb 2000 11:28:31 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: Markus Kuhn CC: tz@elsie.nci.nih.gov, ietf-calendar@imc.org, Doug Royer Subject: Re: New Mail List - timezones.external@software.com References: Content-Type: multipart/mixed; boundary="------------8DF15997B3B300F43F61FF8E" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8DF15997B3B300F43F61FF8E Content-Type: multipart/alternative; boundary="------------1FDA448E634724D05DE63560" --------------1FDA448E634724D05DE63560 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Since I'm on both ietf-calendar (http://www.imc.org/ietf-calendar/) and a lurker on the tz mailing list (ftp://elsie.nci.nih.gov/pub/), perhaps I can offer a bit of clarification here. As everyone on both lists realizes, timezones is one of the major "gotchas" of scheduling. The tz list is indeed focused on the detective work of determining the changes in timezones, both historical and current. The ietf-calendar list is focused on developing the standard representation of calendar data and the protocols to allow calendar applications to share calendar data easily. In order to ensure that two calendar implementations can interoperate, both need to look at the same database of timezones. Since we're drafting the CAP (Calendar Access Protocol) now, we need to point Calendar implementors at a timezone standard, which of course doesn't exist. The TZ database appears to be the closest thing available, an excellent example of volunteers doing a much needed job. The problem is how to reference it in an RFC? I won't speak for Doug, but I believe he intended to leverage the tz mailing list and the packaged updates, but use the IANA as the "official" repository for standards to reference. The current tzdata ftp site, a US government organization which has nothing to do with timezones, doesn't allow web pages. Why not find a permanent home for this with the IANA (www.iana.org) which has "Dedicated to preserving the central coordinating functions of the global Internet for the public good" as its motto. dmadeo Markus Kuhn wrote: > There might be a few misunderstandings involved here. First, there is no > "government timezone database". What you see on ftp://elsie.nci.nih.gov/pub/ > is the collaboration of a number of volunteers (Arthur Olson, Paul > Eggert, et al.), the result of which is commonly referred to as the > public domain "Olson database". The only relation to the US government > is that the group has been using an ftp server of the National Cancer > Institute, which happens to be located in the .gov domain. > Since there is a lot of accumulated expertise on this mailing list, > handing over the administration of the database to IANA seems to be a > rather dubious buerocratic effort. Who at IANA would take over authority > over the database and is really comparably qualified to the current > contributors of the Olson database who have done a splendid job for > the last 15 years? > > Just dropping the maintenance of the time zone database into the > responsibility of IANA might give them a task they underestimate at the > moment. > > If you don't like the current zic format, feel free to add a zic-> > VTIMEZONE format converter to the Olson package. Looks mostly like a > bijective transform to me, except that the zic input files contain a lot > of valuable comments that identify official reference documents. > > Only if the output of that converter on the regular updates of the Olson > package turns out to be unsatisfactory, I would start worrying about > setting up a parallel bureaucracy and an independent database. I see > really no need for yet another mailing list. > > > RFC-2445 defines VTIMEZONE. > > BEGIN:VTIMEZONE > TZID:US--Fictitious-Eastern > LAST-MODIFIED:19870101T000000Z > BEGIN:STANDARD > DTSTART:19671029T020000 > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 > TZOFFSETFROM:-0400 > TZOFFSETTO:-0500 > TZNAME:EST > END:STANDARD > BEGIN:DAYLIGHT > DTSTART:19870405T020000 > RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z > TZOFFSETFROM:-0500 > TZOFFSETTO:-0400 > TZNAME:EDT > END:DAYLIGHT > BEGIN:DAYLIGHT > DTSTART:19990424T020000 > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 > TZOFFSETFROM:-0500 > TZOFFSETTO:-0400 > TZNAME:EDT > END:DAYLIGHT > END:VTIMEZONE > > If people really think that this looks that much nicer or easier to > parse for machines and humans ... > > Markus > > -- > Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK > Email: mkuhn at acm.org, WWW: --------------1FDA448E634724D05DE63560 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Since I'm on both ietf-calendar (http://www.imc.org/ietf-calendar/) and a lurker on the tz mailing list (ftp://elsie.nci.nih.gov/pub/), perhaps I can offer a bit of clarification here.  As everyone on both lists realizes, timezones is one of the major "gotchas" of scheduling.

The tz list is indeed focused on the detective work of determining the changes in timezones, both historical and current.  The ietf-calendar list is focused on developing the standard representation of calendar data  and the protocols to allow calendar applications to share calendar data easily.

In order to ensure that two calendar implementations can interoperate, both need to look at the same database of timezones.   Since we're drafting the CAP (Calendar Access Protocol) now, we need to point Calendar implementors at a timezone standard, which of course doesn't exist.

The TZ database appears to be the closest thing available, an excellent example of volunteers doing a much needed job.   The problem is how to reference it in an RFC?

I won't speak for Doug, but I believe he intended to leverage the tz mailing list and the packaged updates, but use the IANA as the "official" repository for standards to reference.   The current tzdata ftp site, a US government organization which has nothing to do with timezones, doesn't allow web pages.   Why not find a permanent home for this with the IANA (www.iana.org) which has "Dedicated to preserving the central coordinating functions of the global Internet for the public good" as its motto.

dmadeo
 

Markus Kuhn wrote:

There might be a few misunderstandings involved here. First, there is no
"government timezone database". What you see on ftp://elsie.nci.nih.gov/pub/
is the collaboration of a number of volunteers (Arthur Olson, Paul
Eggert, et al.), the result of which is commonly referred to as the
public domain "Olson database". The only relation to the US government
is that the group has been using an ftp server of the National Cancer
Institute, which happens to be located in the .gov domain.
Since there is a lot of accumulated expertise on this mailing list,
handing over the administration of the database to IANA seems to be a
rather dubious buerocratic effort. Who at IANA would take over authority
over the database and is really comparably qualified to the current
contributors of the Olson database who have done a splendid job for
the last 15 years?

Just dropping the maintenance of the time zone database into the
responsibility of IANA might give them a task they underestimate at the
moment.

If you don't like the current zic format, feel free to add a zic->
VTIMEZONE format converter to the Olson package. Looks mostly like a
bijective transform to me, except that the zic input files contain a lot
of valuable comments that identify official reference documents.

Only if the output of that converter on the regular updates of the Olson
package turns out to be unsatisfactory, I would start worrying about
setting up a parallel bureaucracy and an independent database. I see
really no need for yet another mailing list.

> RFC-2445 defines VTIMEZONE.

     BEGIN:VTIMEZONE
     TZID:US--Fictitious-Eastern
     LAST-MODIFIED:19870101T000000Z
     BEGIN:STANDARD
     DTSTART:19671029T020000
     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
     TZOFFSETFROM:-0400
     TZOFFSETTO:-0500
     TZNAME:EST
     END:STANDARD
     BEGIN:DAYLIGHT
     DTSTART:19870405T020000
     RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
     TZOFFSETFROM:-0500
     TZOFFSETTO:-0400
     TZNAME:EDT
     END:DAYLIGHT
     BEGIN:DAYLIGHT
     DTSTART:19990424T020000
     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4
     TZOFFSETFROM:-0500
     TZOFFSETTO:-0400
     TZNAME:EDT
     END:DAYLIGHT
     END:VTIMEZONE

If people really think that this looks that much nicer or easier to
parse for machines and humans ...

Markus

--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

--------------1FDA448E634724D05DE63560-- --------------8DF15997B3B300F43F61FF8E Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;fax:212-762-1009 tel;work:212-762-2348 x-mozilla-html:FALSE url:www.ms.com org:Morgan Stanley Dean Witter and Discover;Information Technology version:2.1 email;internet:dmadeo@ms.com adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA x-mozilla-cpt:;0 fn:David Madeo end:vcard --------------8DF15997B3B300F43F61FF8E-- From owner-ietf-calendar@imc.org Fri Feb 4 12:02:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02855 for ; Fri, 4 Feb 2000 12:02:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA10715 for ietf-calendar-bks; Fri, 4 Feb 2000 08:40:51 -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 IAA10709 for ; Fri, 4 Feb 2000 08:40:47 -0800 (PST) Received: from home.royer.com (home.royer.com [63.195.80.50]) by royer.com (8.9.1/8.9.1) with SMTP id IAA21541; Fri, 4 Feb 2000 08:41:51 -0800 (PST) Message-Id: <200002041641.IAA21541@royer.com> Date: Fri, 4 Feb 2000 08:41:51 -0800 (PST) From: Doug Royer Reply-To: Doug Royer Subject: Re: New Mail List - timezones.external@software.com To: Markus.Kuhn@cl.cam.ac.uk, David.Madeo@msdw.com Cc: tz@elsie.nci.nih.gov, ietf-calendar@imc.org, doug@home.royer.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5yyugjxCYUOpJVKnvAJvLA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Date: Fri, 04 Feb 2000 11:28:31 -0500 > From: David Madeo > I won't speak for Doug, but I believe he intended to leverage the tz > mailing list and the packaged updates, but use the IANA as the > "official" repository for standards to reference. .... Yes - and the new list only purpose is to make the tool that converts from the ZIC format to RFC-2445 format. Then the new list will go away. -Doug ------------------------------------------------------------------- Doug@Royer.COM http://royer.com/People/Doug Text Pager: pager@Royer.com 801 W. El Camino #131 Mountain View, CA 94040 Ham Radio: N6AAW, Aviation: PP-ASEL From owner-ietf-calendar@imc.org Fri Feb 4 12:08:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03133 for ; Fri, 4 Feb 2000 12:08:27 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA10899 for ietf-calendar-bks; Fri, 4 Feb 2000 08:49:39 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10894 for ; Fri, 4 Feb 2000 08:49:37 -0800 (PST) Received: from home.royer.com (home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id IAA14569; Fri, 4 Feb 2000 08:52:06 -0800 (PST) Message-ID: <389B03AB.4826ABFE@home.royer.com> Date: Fri, 04 Feb 2000 08:51:55 -0800 From: Doug Royer X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: POLICY definitions (Re: forced VCAR (was: revised security section)) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7E047AE9D5BA576E83698912" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms7E047AE9D5BA576E83698912 Content-Type: multipart/mixed; boundary="------------97B75365D2D38CC426735754" This is a multi-part message in MIME format. --------------97B75365D2D38CC426735754 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank_Dawson@lotus.com wrote: > > Yes, we are in agreement. > > - C&S VCAR Policy specification by the CU is in the CAP. As far as POLICY goes. They are -not- really in CAP yet. Frank - as you are the one that put 'POLICY' in CAP. Do you think the VCAR definitions sent out are correct? If not could you please explain what those POLICYs mean? If not - I would suggest we remove them from CAP as as they are currently undefined and it would be impossible to create an interoperable CUA or CS that knew what to do with them. We could put them back in once they have been defined. Any objections? -Doug --------------97B75365D2D38CC426735754 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------97B75365D2D38CC426735754-- --------------ms7E047AE9D5BA576E83698912 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMjA0MTY1MTU3WjAjBgkqhkiG9w0BCQQxFgQUIIkEzvua YlXFSfgz+pTO5vu970swUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYAAW6tdLeqBFTGLze9H54E2k3dFrLLEmlilhvaQ7TjxjhhrnUmjY0G+VtXg7H8z TLxySBMf5or2rTOahnY3zg4x8LDtQ5gGSjTDMbERmfeqK6tUxMHr6ZWuh+3E8pcCFSLJNsCQ UPit5i8W/NUzREpeMqp4yjSFwkZHvXN2jL1ZlQ== --------------ms7E047AE9D5BA576E83698912-- From owner-ietf-calendar@imc.org Fri Feb 4 12:09:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03161 for ; Fri, 4 Feb 2000 12:09:49 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA10922 for ietf-calendar-bks; Fri, 4 Feb 2000 08:51:07 -0800 (PST) Received: from ljudo.shortlist.se (IDENT:postfix@ljudo.shortlist.se [193.14.119.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10918 for ; Fri, 4 Feb 2000 08:51:06 -0800 (PST) Received: from joyce (unknown [193.14.119.6]) by ljudo.shortlist.se (Postfix) with SMTP id B74A5B34C5; Fri, 4 Feb 2000 17:54:50 +0100 (CET) From: "Greg FitzPatrick" To: "Markus Kuhn" , , Cc: "Doug Royer" Subject: New Mail List - timezones.external@software.com Date: Fri, 4 Feb 2000 17:53:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit There is obviously a lot to what you are saying Markus, but one point remains to be resolved. In the near future we are going to need legal frameworks for access to machine-readable online resources. Maybe that is part of the effort Doug is talking about And we are going to need mechanisms for creating and maintaining aggregations such as the Olson, but that have some official binding to an Authority. Because otherwise people wont know who to sue! BTW the IETF has a parent organization - ISOC, whose raison d´etre is to protect the IETF from the legal repercussions of their standards work. Though it may seem ludicrously utopian at this time to plan for a network of little bots zipping around from the Cook Islands to the Kingdom of Swat, slurping up time zone rulings from each individual authority's machine readable time zone database, that is exactly where we are heading, er, eventually :-) Compare that to this: In Sweden, 78 district courts publish bankruptcy proceedings in a machine-readable metadata format, any agent may crawl these sites or their aggregations at regional levels and undertake actions on behalf of their users based on their readings from these sites without any human interference or approval. One government chartered authorities site is charged with the official machine-readable publishing of an aggregation of all 78 district courts. Thousand of applications will undertake actions on their users behalf based on their readings of this information, again with no human intermediation. This is a non-utopian proposal which we are currently working on. Depending on the degree of sophistication of each authorities infostructure, bit for bit information will be transferred to machine collectable, machine readable authoritive publishing. Since there is already a sufficient level of sophistication in some areas of the world such as the Kingdom of Sweden to go forward with this work, I argue that we should do so and let The Kingdom of Swat catch up when they can, which will of course guarantee lots of exciting detective work for the next 50 years. Agree on a machine readable publishing format and I will pop over to the Department of Commerce and convince them to publish the official daylight savings times of Sweden just to be the first ever to do so:-) Greg /btw that last paragraph was a gross exaggeration of my power to get things done here:-) > Doug Royer : > > There are three goals of this list. > > > > 1) Port the government database and 'zic' (Zone Information > Compiler) > > to other OS's and have it also provide the data in VTIMEZONE > > format. Most UNIX's use the government database format > and the zic > > compiler (man zic). > > > > 2) Convert the government database into VTIMEZONE records for IANA > > to administer. > > > > 3) Give away the results to the public domain. > > There might be a few misunderstandings involved here. First, there is no > "government timezone database". What you see on > ftp://elsie.nci.nih.gov/pub/ > is the collaboration of a number of volunteers (Arthur Olson, Paul > Eggert, et al.), the result of which is commonly referred to as the > public domain "Olson database". The only relation to the US government > is that the group has been using an ftp server of the National Cancer > Institute, which happens to be located in the .gov domain. > > There exists already a well-established mailing list for discussions > on time zones and the maintenance of the Olson database, namely > > tz@elsie.nci.nih.gov > > Contact > > tz-request@elsie.nci.nih.go > > to join the club. > > Since there is a lot of accumulated expertise on this mailing list, > handing over the administration of the database to IANA seems to be a > rather dubious buerocratic effort. Who at IANA would take over authority > over the database and is really comparably qualified to the current > contributors of the Olson database who have done a splendid job for > the last 15 years? > > Please understand that IANA is a registration service, while what the > group around Olson is doing is more a detective service that observes > and documents the highly complicated world of national and regional > decisions about time-zone changes in the world. If government X is going > to change its local time zone, it is more likely that the database > maintainer will hear about this from various informers or media reports > around the world, as well as resources such as IATA or CIA. It is much > less likely that the respective countries will report timezone changes > directly to IANA officially. A detective service can provide a more > accurate representation of the real world than a registration service. > > Just dropping the maintenance of the time zone database into the > responsibility of IANA might give them a task they underestimate at the > moment. > > If you don't like the current zic format, feel free to add a zic-> > VTIMEZONE format converter to the Olson package. Looks mostly like a > bijective transform to me, except that the zic input files contain a lot > of valuable comments that identify official reference documents. > > Only if the output of that converter on the regular updates of the Olson > package turns out to be unsatisfactory, I would start worrying about > setting up a parallel bureaucracy and an independent database. I see > really no need for yet another mailing list. > > > RFC-2445 defines VTIMEZONE. > > BEGIN:VTIMEZONE > TZID:US--Fictitious-Eastern > LAST-MODIFIED:19870101T000000Z > BEGIN:STANDARD > DTSTART:19671029T020000 > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 > TZOFFSETFROM:-0400 > TZOFFSETTO:-0500 > TZNAME:EST > END:STANDARD > BEGIN:DAYLIGHT > DTSTART:19870405T020000 > RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z > TZOFFSETFROM:-0500 > TZOFFSETTO:-0400 > TZNAME:EDT > END:DAYLIGHT > BEGIN:DAYLIGHT > DTSTART:19990424T020000 > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 > TZOFFSETFROM:-0500 > TZOFFSETTO:-0400 > TZNAME:EDT > END:DAYLIGHT > END:VTIMEZONE > > If people really think that this looks that much nicer or easier to > parse for machines and humans ... > > Markus > > -- > Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK > Email: mkuhn at acm.org, WWW: > > From owner-ietf-calendar@imc.org Fri Feb 4 13:40:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06085 for ; Fri, 4 Feb 2000 13:40:31 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13914 for ietf-calendar-bks; Fri, 4 Feb 2000 10:19:56 -0800 (PST) Received: from wisbech.cl.cam.ac.uk (exim@mta1.cl.cam.ac.uk [128.232.0.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13910 for ; Fri, 4 Feb 2000 10:19:54 -0800 (PST) Received: from trillium.cl.cam.ac.uk ([128.232.8.5] helo=cl.cam.ac.uk ident=mgk25) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 12GnN8-0007sI-00; Fri, 04 Feb 2000 18:22:22 +0000 X-Mailer: exmh version 2.0.2+CL 2/24/98 To: "Greg FitzPatrick" cc: tz@elsie.nci.nih.gov, ietf-calendar@imc.org, "Doug Royer" Subject: Re: New Mail List - timezones.external@software.com In-reply-to: Your message of "Fri, 04 Feb 2000 17:53:27 +0100." X-URL: http://www.cl.cam.ac.uk/~mgk25/ Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 04 Feb 2000 18:22:20 +0000 From: Markus Kuhn Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA13911 Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit "Greg FitzPatrick" wrote on 2000-02-04 16:53 UTC: > Because otherwise people wont know who to sue! So what we have to do is to transform the Olson group into something that looks like a sue-able entity, but nevertheless isn't sue-able. There was actually some time ago already a discussion on the tz mailing list to set up something that could be called the International Time Zone Information Centre with a quotable web page, postal address, etc. It would essentially be the old Olson Group, but there would be something like an "Annual Time Zone Newsletter" that will be sent freely to places such as various government ministries, intelligence agencies, news agencies, airline and telecommunications associations (IATA, ITU, etc.), etc. The goal would be to create a point of contact where governments and observers of governments could centrally report time zone changes and also make sure that knowledge of the centre and its current data base content spreads to the right places. The basic idea seemed to have been quite agreeable, but in the end there simply wasn't anyone volunteering to handle the bureaucracy necessary to set up such a small institution. If two or three industrial sponsors would come forward to cover the in the end surely quite marginal running costs of such a small organization, I am sure it would be possible to set up a suitable quotable but not quite sueable body. Publishing a single-page ISO standard that designates the named organization to be the keeper of the ISO 16xyz time zone database would surely sprinkle sufficient official magic around the entire thing to keep even hard-line bureaucrats happy. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: From owner-ietf-calendar@imc.org Fri Feb 4 13:44:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06144 for ; Fri, 4 Feb 2000 13:44:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA14122 for ietf-calendar-bks; Fri, 4 Feb 2000 10:27:09 -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 KAA14118 for ; Fri, 4 Feb 2000 10:27:08 -0800 (PST) Received: from home.royer.com (home.royer.com [63.195.80.50]) by royer.com (8.9.1/8.9.1) with SMTP id KAA22910; Fri, 4 Feb 2000 10:29:07 -0800 (PST) Message-Id: <200002041829.KAA22910@royer.com> Date: Fri, 4 Feb 2000 10:29:06 -0800 (PST) From: Doug Royer Reply-To: Doug Royer Subject: Re: New Mail List - timezones.external@software.com To: gf@medianet.org, Markus.Kuhn@cl.cam.ac.uk Cc: tz@elsie.nci.nih.gov, ietf-calendar@imc.org, doug@home.royer.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6mkbiT0zpjbxTPb0k9z9Cg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Date: Fri, 04 Feb 2000 18:22:20 +0000 > From: Markus Kuhn > > .. > > The basic idea seemed to have been quite agreeable, but in the end there > simply wasn't anyone volunteering to handle the bureaucracy necessary to > set up such a small institution. If two or three industrial sponsors > would come forward to cover the in the end surely quite marginal running > costs of such a small organization, I am sure it would be possible to > set up a suitable quotable but not quite sueable body. > > Publishing a single-page ISO standard that designates the named > organization to be the keeper of the ISO 16xyz time zone database would > surely sprinkle sufficient official magic around the entire thing to > keep even hard-line bureaucrats happy. Any reason it can't be IANA? We need to have a VTIMEZONE converter. I do NOT think it is important if the source is ZIC format and converted to VTIMEZONE on demand. -Doug ------------------------------------------------------------------- Doug@Royer.COM http://royer.com/People/Doug Text Pager: pager@Royer.com 801 W. El Camino #131 Mountain View, CA 94040 Ham Radio: N6AAW, Aviation: PP-ASEL From owner-ietf-calendar@imc.org Fri Feb 4 14:37:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07355 for ; Fri, 4 Feb 2000 14:37:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15912 for ietf-calendar-bks; Fri, 4 Feb 2000 11:17:23 -0800 (PST) Received: from imo26.mx.aol.com (imo26.mx.aol.com [152.163.225.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15908 for ; Fri, 4 Feb 2000 11:17:22 -0800 (PST) From: CHancuff@aol.com Received: from CHancuff@aol.com by imo26.mx.aol.com (mail_out_v25.3.) id o.5a.efbe4a (4183); Fri, 4 Feb 2000 14:18:04 -0500 (EST) Message-ID: <5a.efbe4a.25cc7feb@aol.com> Date: Fri, 4 Feb 2000 14:18:03 EST Subject: Re: New Mail List - timezones.external@software.com To: Markus.Kuhn@cl.cam.ac.uk, tz@elsie.nci.nih.gov, ietf-calendar@imc.org CC: doug@home.royer.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 45 Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In a message dated 2/4/00 9:48:42 AM Eastern Standard Time, Markus.Kuhn@cl.cam.ac.uk writes: > It is much less likely that the respective countries will report > timezone changes directly to IANA officially. I may be the very least qualified on this mailing list to comment (since the only other time I've posted concerned my intense interest in discovering the time zone observed by an island which spends 6 months/year underwater) but ... I can see the advantage of having a web presence to which reports, rumors, and hearsay can also be reported, then brought to this list for scrutiny. Perhaps a form page, where such things can be entered. I'm trying to imagine the "signal to noise" ratio of a central reporting venue like this one, but I can't. It might be worth a try. Cliff Hancuff www.ClearDaySoftware.com From owner-ietf-calendar@imc.org Fri Feb 4 14:53:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07740 for ; Fri, 4 Feb 2000 14:53:30 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA16768 for ietf-calendar-bks; Fri, 4 Feb 2000 11:30:54 -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 LAA16762 for ; Fri, 4 Feb 2000 11:30:52 -0800 (PST) Received: from home.royer.com (home.royer.com [63.195.80.50]) by royer.com (8.9.1/8.9.1) with SMTP id LAA23775; Fri, 4 Feb 2000 11:32:58 -0800 (PST) Message-Id: <200002041932.LAA23775@royer.com> Date: Fri, 4 Feb 2000 11:32:58 -0800 (PST) From: Doug Royer Reply-To: Doug Royer Subject: Re: New Mail List - timezones.external@software.com To: Markus.Kuhn@cl.cam.ac.uk, tz@elsie.nci.nih.gov, ietf-calendar@imc.org, CHancuff@aol.com Cc: doug@home.royer.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XYiBSSVutTYShcYC0MGq7A== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is very important that when scheduling across timezones that users across those time zones use the same time zone definitions. FYI: The biggest OS and application vendors on Microsoft and UNIX have applications out -now- that understand VTIMEZONE. This includes Outlook, Lotus Notes, Netscape Calendar, Sun, and the list goes on. Oracle is active as are other database vendors. iCalendar and VTIMEZONE have been in the works for years. There are also many other vendors coming up now on the internet that are supporting this format. It would be a little less critical if the data was a month or two out of date. Each side if using VTIMEZONE, would know when it was going to happen. I could write a batch job that woke up once a week to see if the Olson database had changed, if it had, run the converter to VTIMEZONE and send IANA email. I think that IANA could also do this without my help. -Doug > From: CHancuff@aol.com > Date: Fri, 4 Feb 2000 14:18:03 EST > > In a message dated 2/4/00 9:48:42 AM Eastern Standard Time, > Markus.Kuhn@cl.cam.ac.uk writes: > > > It is much less likely that the respective countries will report > > timezone changes directly to IANA officially. > > I may be the very least qualified on this mailing list to comment > (since the only other time I've posted concerned my intense > interest in discovering the time zone observed by an island > which spends 6 months/year underwater) but ... > > I can see the advantage of having a web presence to which > reports, rumors, and hearsay can also be reported, then brought > to this list for scrutiny. Perhaps a form page, where such things > can be entered. > > I'm trying to imagine the "signal to noise" ratio of a central > reporting venue like this one, but I can't. It might be worth a try. > > Cliff Hancuff > www.ClearDaySoftware.com -Doug ------------------------------------------------------------------- Doug@Royer.COM http://royer.com/People/Doug Text Pager: pager@Royer.com 801 W. El Camino #131 Mountain View, CA 94040 Ham Radio: N6AAW, Aviation: PP-ASEL From owner-ietf-calendar@imc.org Fri Feb 4 17:32:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11989 for ; Fri, 4 Feb 2000 17:32:33 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA25977 for ietf-calendar-bks; Fri, 4 Feb 2000 14:06:54 -0800 (PST) Received: from hotmail.com (law2-f118.hotmail.com [216.32.181.118]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA25973 for ; Fri, 4 Feb 2000 14:06:53 -0800 (PST) Received: (qmail 39414 invoked by uid 0); 4 Feb 2000 22:08:56 -0000 Message-ID: <20000204220856.39413.qmail@hotmail.com> Received: from 212.151.250.115 by www.hotmail.com with HTTP; Fri, 04 Feb 2000 14:08:56 PST X-Originating-IP: [212.151.250.115] Reply-To: gf@medianet.org From: "Greg FizPatrick" To: rmcdow@enteles.com, gf@medianet.org Cc: tz@elsie.nci.nih.gov, ietf-calendar@imc.org Subject: Re: time zones Date: Fri, 04 Feb 2000 23:08:56 CET Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks Rives I am really happy that I made somebody laugh today. No, I don't know Joanna Petre, but it sounds as if she has an interesting, if difficult job. Thanks for some alternative examples to the Kingdom of Swat. I think you've got the picture, there is a big spread on the organizational capacity of our world's societies. There is probably some sort of logical correlation between what your reporting and the fact neither The Lebanon or Georgia (country) are exactly hot houses of information technology growth. I am going to try to be terse. People who collect and publicly share information of societal interest, spending their own, often unpaid time to do so, are to be admired and thanked by all. Any knowledge that can be codified, will be. All codified knowledge useful to transactional processes in commerce or science will be digitized. All digital information will be stored on computers. All computers will converse with other computers through networks, some public some private (if only virtually so). Any transactional process that can be safely negotiated with out human intermediation, will be. The above transitions and their effect will not occur evenly across the strata of our societies or spread linearly across the planet. On the contrary. The impending growth in, by humans, unintermediated machine negotiated transactional processes will nescesitate a new system of trusted parties, authoritive sources, and new liability structures. Some of this will be fun and a lot will not. Have a nice weekend. Greg From: Rives McDow To: Subject: time zones Date: Fri, 04 Feb 2000 11:27:44 -0800 Dear Greg, Are you familiar with who officially tracks the time changes for the United States? If not, I would recommend that you and Doug contact her before volunteering to host an authoritative list of time zone changes in the world. Your image of this happening automatically using little bots actually got me to laugh out loud at its absurdity (It is really true humor, as it has a bit of hoped for truth in it). There is much more to time zone data than can be put on a server in each country. If you have any doubts about this, call Joanna Petre, try to find out what Lebanon will do about daylight savings (or their local equivalent, which I would call political savings time rather than daylight savings time) in the year 2000, or try to find out if Georgia (country) will implement daylight savings in the year 2000. Then wait four months to see what happened in these last two countries, and check again in July. You will be surprised, and so will your little bots! At this stage of development of time zones in the world, Olsen's list works very well, as it leaves the authority where it in reality currently resides, in the hands of the locals. No government has as yet successfully implemented a country-wide method of time-keeping if that country has multiple time zones, with the possible exception of Brazil. I have also seen breakdowns there in authoritative directives, which is why I say possible exception, as they do a good job in spite of the locals. Sincerely, Rives McDow ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ietf-calendar@imc.org Fri Feb 4 21:56:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16648 for ; Fri, 4 Feb 2000 21:56:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA03953 for ietf-calendar-bks; Fri, 4 Feb 2000 18:39:20 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03945 for ; Fri, 4 Feb 2000 18:39:18 -0800 (PST) Received: from thinkpad600e (A200-41.PPP.FTWO.TX.VERIO.NET [206.50.209.41]) by mailhost.onramp.net (8.9.3/8.9.3) with SMTP id UAA16389; Fri, 4 Feb 2000 20:41:24 -0600 (CST) From: "Rik Drummond" To: "Virginia Smith" , , , , , Cc: "IETF-calendar" , "BethM" Subject: RE: ECI Advisory Board Meeting Date: Fri, 4 Feb 2000 20:41:38 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.1.20000201161833.009b6420@enterprise.disa.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit i will be there... rik -----Original Message----- From: Virginia Smith [mailto:vsmith@disa.org] Sent: Tuesday, February 01, 2000 3:22 PM To: drummond@onramp.net; garbert@dor.state.sc.us; dhons@ect-edi.com; dparaiso@worldnet.att.net; mreimann@uta.edu; w.michael.yearick@bankofamerica.com Subject: ECI Advisory Board Meeting Just a reminder that I have not received RSVP's from you regarding the Advisory Board Meeting to take place next week. Please let me know if you will/or will not be attending by filling out the attached RSVP sheet and returning it via fax to my attention at (703) 548-5738 by COB tommorrow. Many thanks! Ginger ____________________________________ Virginia A. Smith (Ginger) Administrative Assistant, Education Data Interchange Standards Association (DISA) 333 John Carlyle Street, Suite 600 Alexandria, VA 22314 Phone: (703) 548-7005 x186 Fax: (703) 548-5738 vsmith@disa.org http://disa.org From owner-ietf-calendar@imc.org Sat Feb 5 14:30:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06927 for ; Sat, 5 Feb 2000 14:30:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA07632 for ietf-calendar-bks; Sat, 5 Feb 2000 11:01:38 -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 LAA07628 for ; Sat, 5 Feb 2000 11:01:37 -0800 (PST) Received: from home.royer.com (home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA18052 for ; Sat, 5 Feb 2000 11:04:12 -0800 (PST) Message-ID: <389C742B.503C474D@home.royer.com> Date: Sat, 05 Feb 2000 11:04:11 -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: VTIMEZONE problems? Content-Type: multipart/mixed; boundary="------------464B6AE36571EB5D041F48B2" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------464B6AE36571EB5D041F48B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I created the timezone.external@software.com alias to help port the Olson-database to VTIMEZONE format. When the list announcement came out I CC'd the 'tz' alias. I have been getting private email from the 'tz' list describing problems with the VTIMEZONE component. So I have encouraged them to start posting to this list with the issues. So expect some controversial email soon on the topic if time zones!. We may have to have a VTIMEZONE Version-2 or something. Or perhaps some way to extend the existing VTIMEZONE to solve current time zone representation problems. I did not expect this issue to come up, I expected VTIMEZONE to be ready to use. -Doug --------------464B6AE36571EB5D041F48B2 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------464B6AE36571EB5D041F48B2-- From owner-ietf-calendar@imc.org Sat Feb 5 16:11:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07535 for ; Sat, 5 Feb 2000 16:11:21 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA09900 for ietf-calendar-bks; Sat, 5 Feb 2000 12:42:37 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09896 for ; Sat, 5 Feb 2000 12:42:36 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA25183 for ; Sat, 5 Feb 2000 12:41:19 -0800 (PST) Received: from netscape.com ([198.93.95.182]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FPH5MH00.42L; Sat, 5 Feb 2000 12:44:41 -0800 Message-ID: <389C8BD9.BFB8D0EF@netscape.com> Date: Sat, 05 Feb 2000 12:45:13 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank Dawson CC: ietf-calendar@imc.org Subject: POLICY definitions: your input needed References: <389B03AB.4826ABFE@home.royer.com> Content-Type: multipart/mixed; boundary="------------BCD9CBAD7529046E216C9F99" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BCD9CBAD7529046E216C9F99 Content-Type: multipart/alternative; boundary="------------CEBDEBEC5575CD80B9184FF5" --------------CEBDEBEC5575CD80B9184FF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Frank (and others), We need some clarity on the Policy specification. The only "specification" I've seen is Doug's earlier message "POLICY in general." I don't think there's general concensus on what each of the policies means. Since we started working on iTIP, I've talked with many folks in this working group about "policies", and I know we all have slightly different ideas about certain things. For example, exactly what it means for one user to act on behalf of another differs a bit between products. The choices we have to resolve this, as I see them, are: 1. We give each policy a name and define precisely what it means with VCARs 2. We define a set of policy names and allow clients to query for the VCARs that describe what they mean 3. We remove policies completely If there's no feedback within a week or two, we'll just remove policies from the draft. We can add them back if/when we get definitions. -Steve Doug Royer wrote: > Frank_Dawson@lotus.com wrote: > > > > Yes, we are in agreement. > > > > - C&S VCAR Policy specification by the CU is in the CAP. > > As far as POLICY goes. They are -not- really in CAP yet. > > Frank - as you are the one that put 'POLICY' in CAP. Do you think > the VCAR definitions sent out are correct? If not could you please > explain what those POLICYs mean? > > If not - I would suggest we remove them from CAP as as they are currently > undefined and it would be impossible to create an interoperable CUA or CS > that knew what to do with them. We could put them back in once they > have been defined. > > Any objections? > > -Doug --------------CEBDEBEC5575CD80B9184FF5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Frank (and others),

We need some clarity on the Policy specification. The only "specification" I've seen is Doug's earlier message "POLICY in general."

I don't think there's general concensus on what each of the policies means. Since we started working on iTIP, I've talked with many folks in this working group about "policies", and I know we all have slightly different ideas about certain things. For example, exactly what it means for one user to act on behalf of another differs a bit between products.

The choices we have to resolve this, as I see them, are:

  1. We give each policy a name and define precisely what it means with VCARs
  2. We define a set of policy names and allow clients to query for the VCARs that describe what they mean
  3. We remove policies completely
If there's no feedback within a week or two, we'll just remove policies from the draft. We can add them back if/when we get definitions.

-Steve

Doug Royer wrote:

Frank_Dawson@lotus.com wrote:
>
> Yes, we are in agreement.
>
> - C&S VCAR Policy specification by the CU is in the CAP.

As far as POLICY goes. They are -not- really in CAP yet.

Frank - as you are the one that put 'POLICY' in CAP. Do you think
the VCAR definitions sent out are correct? If not could you please
explain what those POLICYs mean?

If not - I would suggest we remove them from CAP as as they are currently
undefined and it would be impossible to create an interoperable CUA or CS
that knew what to do with them. We could put them back in once they
have been defined.

Any objections?

-Doug

--------------CEBDEBEC5575CD80B9184FF5-- --------------BCD9CBAD7529046E216C9F99 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner x-mozilla-cpt:;0 fn:Steve Mansour end:vcard --------------BCD9CBAD7529046E216C9F99-- From owner-ietf-calendar@imc.org Sat Feb 5 17:27:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07916 for ; Sat, 5 Feb 2000 17:27:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA10320 for ietf-calendar-bks; Sat, 5 Feb 2000 14:00:59 -0800 (PST) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10316 for ; Sat, 5 Feb 2000 14:00:57 -0800 (PST) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: Adalaide Agenda Time for CALSCH X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Sat, 5 Feb 2000 17:03:30 -0500 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at 02/05/2000 05:03:32 PM, Serialize complete at 02/05/2000 05:03:32 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 007981558525687C_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007981558525687C_= Content-Type: text/plain; charset="us-ascii" FYI - the time for the CALSCH working group meeting in Adelaide is below: TUESDAY, March 28, 2000 0900-1130 calsch Calendaring and Scheduling WG --=_alternative 007981558525687C_= Content-Type: text/html; charset="us-ascii"
FYI - the time for the CALSCH working group meeting in Adelaide is below:


TUESDAY, March 28, 2000
0900-1130  calsch                 Calendaring and Scheduling WG
 --=_alternative 007981558525687C_=-- From owner-ietf-calendar@imc.org Sat Feb 5 19:11:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08575 for ; Sat, 5 Feb 2000 19:11:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA10827 for ietf-calendar-bks; Sat, 5 Feb 2000 15:44:20 -0800 (PST) Received: from biz1.mailsrvcs.net (biz1.gte.net [207.115.153.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10823 for ; Sat, 5 Feb 2000 15:44:18 -0800 (PST) Received: from [32.100.255.32] by biz1.mailsrvcs.net (Post.Office MTA v3.5.3 release 223 ID# 0-64117L5000S0V35) with ESMTP id net for ; Sat, 5 Feb 2000 17:46:15 -0600 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Sat, 05 Feb 2000 15:48:08 -0800 Subject: time zone database interface and formatting From: Rives McDow To: Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="MS_Mac_OE_3032610490_1726047_MIME_Part" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3032610490_1726047_MIME_Part Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I have been in communication with Doug Royer concerning the VTIMEZONE postings concerning the new list, and one thing led to another. Doug suggested that I post my last email to this list for discussion. I have done this with a little bit of editing. I have posted information to this list before, but have not been involved in any of the development discussions, although I have monitored them. I don't know anything except the data at this point, so please excuse my ignorance. I have thought about your emails, the current state of VTIMEZONE in my limited understanding of it from you, and the current state of the Olsen database. I have suggestions that may involve changes too radical for the current data and code, and would like to run a few things by you for your consideration. Possibly you can help me in posting something that will be helpful. The primary changes I would suggest are to make a clear distinction between information, symbols, machine readable text, and human readable tex= t in the data. Here are a few notes about specifics, using some formatting examples from VTIMEZONE as discussion points. > TZNAME:US/Los_Angles This is a classic example of trying to make something both machine readable and human readable, and failing on both counts in the long run. The human is taken into consideration here more than the machine, as this symbol is easily human readable. However, in making it human readable, the time zone is tied to a particular point location, rather than a region. This has caused problems in the past not only with Olsen's list but with every other group that has put together time zone data. The problem occur= s when the city chosen decides to do something different and the rest of the region that it was representing stays the same. The historical records the= n have a discontinuity unless some method is used to correct them or the new chosen name for the region. This has and will occur in many of the cities that are used currently in the Olsen database. If you look at the politica= l and economic situation in some of the cities chosen as area representative city, it is obvious that they will eventually separate from the surrounding region in regards to their timekeeping method. IATA gets around this problem, which I believe they also experienced at one point in their development of Appendix F, by using a country abbreviation followed by a number iterator, and sometimes followed by a letter for a sub-region. This has worked fairly well, and has not been a cause for confusion with the airlines thus far.=20 The method of using America/Pangnirtung as an example designation is mixing data with symbol representation, which is the equivalent of having hard numbers mixed in C code as opposed to having header definitions. America/Pangnirtung currently uses two time zones within the city, whereas the surrounding region it would supposedly represent does not. Because of this another designator will need to be chosen to represent the surrounding area. As a solution I would propose something more like the IATA method, possibly using the ISO 3166 codes along with iterators if a move to consolidating time zones was desired. > BEGIN:DAYLIGHT Of the 30 methods currently used that we might call daylight savings time= , many are not looked on as daylight savings by the local government and populace. The changes in time zone that the country makes are based on energy, political, economic, and local conditions other than extending the daylight hours. =20 Argentina is a recent example. Their change to daylight savings time without changing the time was a move based on local conditions, and not wha= t we would consider a daylight savings time mechanism, even though it will have daylight savings effects. Georgia is another good example, as they base the change of their time zone primarily on how many nuclear reactors they have up and running. This allows them to be a net importer or exporte= r of electrical power and in control of how much their populace spends on electricity by manipulating which time zone they are in. Lebanon is a thir= d example, as they do not base their time change on daylight savings at all i= n most cases (1999 was a perfect example of this), but on local neighboring political climates and negotiations. I don't have an alternative name, but I think this is important to address so that incorrect assumptions are not made by the users of the database. If daylight extension is the reason for the change, with the intention clearly stated in an edict or law that the time will be changed back, the term daylight savings is relevant. Otherwis= e another second term should be used where applicable. This is an area that I have spent hours on trying to define for each country that changes their time zone at some point during the year. All I can say at this point is that there are these categories: 1) Countries for which a methodology can be defined, as it exists in national policy, edicts, agreements, etc. (examples: North America, EC, Cuba, Syria, New Zealand, Chile, Paraguay, Namibia, Thule Airbase Greenland= ) 2) Countries in which someone decides each year with a proclamation or edict; it may or may not be the same each year, and may or may not be implemented each year (examples: the states of Australia, the states of Brazil, Israel) 3) Countries in which someone decides each year based on local conditions not necessarily directly tied to extending the daylight hours as the primar= y objective (examples: Georgia, Lebanon, Armenia, Fiji, Tonga) 4) Countries that have mixed daylight savings and non-daylight savings time within geographic boundaries that sometimes overlap (examples: Canada (part= s of the Nunavut province), Falkland Islands) 5) Countries that decide to switch time zones for other reasons, which overlaps with 3): (example: Lebanon) As yet I have not come up with a satisfactory method of dealing with this, although I have tried several. I think that something should be buil= t into the data that recognizes these types of differences if any prediction of future time zone changes is to be included. At the very least, what is not predictable can be defined, and the predictable can be defined until th= e methodologies in 1) are changed by the country. > DTSTART:YYYYMMDDTHHMMSS The majority of the world's population, including what will be the larges= t computer user base in the world in the near future, does not use the Gregorian calendar. Because of this it makes much more sense to use the Julian day count, or Modified Julian day count, as NASA and most other scientific agencies dealing in important time keeping matters use. This embedding of the Gregorian calendar into systems is a much, much larger problem than the Y2K problem ever was. It will cause problems in the futur= e that will make the Y2K problem look like an pretty insignificant bug. I think that it is very important to recognize this now and correct the problem before it is too late. It is the responsibility of the people on this list to do this. No one else is addressing this in a way that affects as many people as this source of information does. A simple fix for now would be to include a field specifying the calendar method used before the field YYYYMMDDTHHMMSS or before any reference to a year. A better fix woul= d be to reference all past dates as the Julian day count, and specify which calendar system is being used to predict future dates. Calendar conversion algorithms are available from many sources. The book "Calendrical Calculations" is thorough, although I find it difficult to follow because o= f the author's style. "Standard C Date/Time Library" (available from Amazon.com) is much more easily followed, and appears very thorough, although I have not had a chance to fully go over it for its usefulness in all the calendar systems, as I just got it. There are several other good references, including the "Explanatory Supplement to the Astronomical Almanac", whatever is used, conversions can be made from the Julian day count and back with a minimum effort of programming, giving a much more universally useful database. > BEGIN:STANDARD This is a misnomer in some cases due to information stated above when addressing daylight savings time. It probably, however, can be understood in most cases, Argentina being a recent exception. There are other exceptions that will come up, so it may be of some use to define what is meant by Standard. >=20 > Good point --- PLEASE PLEASE contribute to the ietf-calendar@imc.org > list with your suggestions. It will proceed without them if you > don't! I think possibly an interface to the data (the equivalent of a header file) would be the main thing I suggest, rather than having the data mixed with misleading symbols. In addition, with all respect to the former British Empire, I would suggest using positive offsets from the west side o= f the International Date line to avoid the use of negative offsets. This eliminates any date confusion in calculations and notations. Using the wes= t side of the International Date Line gives a clear and unchanging representation of the last hour of the present time at any time, and is fre= e of the confusion that can arrive when London uses daylight savings time, which believe it or not, happens a lot with people. This is especially important when writing code or recording data that needs to be parsed by humans as well as read by machines. >=20 > -MOST- Applications will care about their own time zone and perhaps > that of their offices in other countries. So I don't think that > a typical application will download the entire database. And > it will often never care about the past. The past is about the only thing we can pin down with certainty, unfortunate as this is. IATA and the OAG have had a very difficult time scheduling three years in advance for all airports. It has caused numerous headaches with flight scheduling. I think a few cues should be taken from their experience when proposing something that is dependable. The best I have been able to come up with, working on this full time, is a prediction six months in advance, with small updates every month that don't affect the majority of the world. Whatever is developed, it has to be dynamic and presented as such to its users. Otherwise it will loose credibility very fast, and with no one willing to take responsibility as IATA does for the airlines, it will not be used. I currently print a 30" by 40" map of the time zones of the world every month or so. It takes me 3 days to enter all the changes since the last printing. I have not yet printed one that was not out of date the day it was printed. It was a little frustrating at first, but finally it helped m= e to develop a system that can be used, and is dynamic. The method I use, which I refer to as Global Time Systems=81, is currently ported as a library to the Mac OS and ready to port to Windows. I have als= o ported it to an obscure 8 bit microprocessor, and have it successfully running. It takes up about 115K in the 8 bit micro; the Mac version is 168K; the Windows library is still to be determined, but I expect it to be about the same as the Mac version. It does not have any interface built no= w except in my development platform, but will have one soon, as it is being ported to a clock program now sold for the Mac and being ported to Windows. Any arrangement of symbols can be used to access the data. These symbols are what you are calling the time zone names. I believe the choice of symbols is as important as the understanding of what the symbols are representing. If the choice of symbols clouds this understanding, another more generic symbol should be selected. The data it is representing can then be of any depth; it can be four dimensional, three dimensional, or lis= t based. There is always the concern about legacy code and data when making changes. I think this can be addressed with the proper interface or header file equivalent. What should be our concern is that the code and data we generate and use is forward compatible, as this is something that we can do something about now with a little thought and planning, but is much more difficult to correct in the future without affecting a large number of programs that have come to rely on what has been written. I hope that this is not too big a chunk of information to be useful to this list. I posted this at the encouragement of Doug, and because I would like to see something develop that will be useful in the long run. In addition, I would like to see that the methodology I have developed will interface with what is being developed here, as there are several large users that have said that they will use what I have developed for embedded systems. Sincerely, Rives McDow --MS_Mac_OE_3032610490_1726047_MIME_Part Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable time zone database interface and formatting    I have been in communication with Doug Royer concern= ing the VTIMEZONE postings concerning the new list, and one thing led to ano= ther.  Doug suggested that I post my last email to this list for discus= sion.  I have done this with a little bit of editing.  I have post= ed information to this list before, but have not been involved in any of the= development discussions, although I have monitored them.  I don't know= anything except the data at this point, so please excuse my ignorance.

  I have thought about your emails, the current state of VTIMEZO= NE in my limited understanding of it from you, and the current state of the = Olsen database.  I have suggestions that may involve changes too radica= l for the current data and code, and would like to run a few things by you f= or your consideration.  Possibly you can help me in posting something t= hat will be helpful.

  The primary changes I would suggest are to make a clear distin= ction between information, symbols, machine readable text, and human readabl= e text in the data.  Here are a few notes about specifics, using some f= ormatting examples from VTIMEZONE as discussion points.

> TZNAME:US/Los_Angles

  This is a classic example of trying to make something both mac= hine readable and human readable, and failing on both counts in the long run= .  The human is taken into consideration here more than the machine, as= this symbol is easily human readable.  However, in making it human rea= dable, the time zone is tied to a particular point location, rather than a r= egion.  This has caused problems in the past not only with Olsen's list= but with every other group that has put together time zone data.  &nbs= p;The problem occurs when the city chosen decides to do something different = and the rest of the region that it was representing stays the same.  Th= e historical records then have a discontinuity unless some method is used to= correct them or the new chosen name for the region.  This has and will= occur in many of the cities that are used currently in the Olsen database. =  If you look at the political and economic situation in some of the cit= ies chosen as area representative city, it is obvious that they will eventua= lly separate from the surrounding region in regards to their timekeeping met= hod.   IATA gets around this problem, which I believe they also ex= perienced at one point in their development of Appendix F, by using a countr= y abbreviation followed by a number iterator, and sometimes followed by a le= tter for a sub-region.  This has worked fairly well, and has not been a= cause for confusion with the airlines thus far.  
  The method of using America/Pangnirtung as an example designat= ion is mixing data with symbol representation, which is the equivalent of ha= ving hard numbers mixed in C code as opposed to having header definitions. &= nbsp;America/Pangnirtung currently uses two time zones within the city, wher= eas the surrounding region it would supposedly represent does not.  Bec= ause of this another designator will need to be chosen to represent the surr= ounding area.
  As a solution I would propose something more like the IATA met= hod, possibly using the ISO 3166 codes along with iterators if a move to con= solidating time zones was desired.

> BEGIN:DAYLIGHT

  Of the 30 methods currently used that we might call daylight s= avings time, many are not looked on as daylight savings by the local governm= ent and populace.  The changes in time zone that the country makes are = based on energy, political, economic, and local conditions other than extend= ing the daylight hours.  
  Argentina is a recent example.  Their change to daylight = savings time without changing the time was a move based on local conditions,= and not what we would consider a daylight savings time mechanism, even thou= gh it will have daylight savings effects.  Georgia is another good exam= ple, as they base the change of their time zone primarily on how many nuclea= r reactors they have up and running.  This allows them to be a net impo= rter or exporter of electrical power and in control of how much their popula= ce spends on electricity by manipulating which time zone they are in.  = Lebanon is a third example, as they do not base their time change on dayligh= t savings at all in most cases (1999 was a perfect example of this), but on = local neighboring political climates and negotiations.  I don't have an= alternative name, but I think this is important to address so that incorrec= t assumptions are not made by the users of the database.  If daylight e= xtension is the reason for the change, with the intention clearly stated in = an edict or law that the time will be changed back, the term daylight saving= s is relevant.  Otherwise another second term should be used where appl= icable.

   This is an area that I have spent hours on trying to def= ine for each country that changes their time zone at some point during the y= ear.  All I can say at this point is that there are these categories:
1) Countries for which a methodology can be defined, as it exists in nation= al policy, edicts, agreements, etc. (examples: North America, EC, Cuba, Syri= a, New Zealand, Chile, Paraguay, Namibia, Thule Airbase Greenland)
2) Countries in which someone decides each year with a proclamation or edic= t; it may or may not be the same each year, and may or may not be implemente= d each year (examples: the states of Australia, the states of Brazil, Israel= )
3) Countries in which someone decides each year based on local conditions n= ot necessarily directly tied to extending the daylight hours as the primary = objective (examples: Georgia, Lebanon, Armenia, Fiji, Tonga)  
4) Countries that have mixed daylight savings and non-daylight savings time= within geographic boundaries that sometimes overlap (examples: Canada (part= s of the Nunavut province), Falkland Islands)
5) Countries that decide to switch time zones for other reasons, which over= laps with 3): (example: Lebanon)

   As yet I have not come up with a satisfactory method of = dealing with this, although I have tried several.  I think that somethi= ng should be built into the data that recognizes these types of differences = if any prediction of future time zone changes is to be included.  At th= e very least, what is not predictable can be defined, and the predictable ca= n be defined until the methodologies in 1) are changed by the country.


> DTSTART:YYYYMMDDTHHMMSS

  The majority of the world's population, including what will be= the largest computer user base in the world in the near future, does not us= e the Gregorian calendar.  Because of this it makes much more sense to = use the Julian day count, or Modified Julian day count, as NASA and most oth= er scientific agencies dealing in important time keeping matters use.  = This embedding of the Gregorian calendar into systems is a much, much larger= problem than the Y2K problem ever was.  It will cause problems in the = future that will make the Y2K problem look like an pretty insignificant bug.=  I think that it is very important to recognize this now and correct t= he problem before it is too late.  It is the responsibility of the peop= le on this list to do this.  No one else is addressing this in a way th= at affects as many people as this source of information does.  A simple= fix for now would be to include a field specifying the calendar method used= before the field YYYYMMDDTHHMMSS or before any reference to a year.  A= better fix would be to reference all past dates as the Julian day count, an= d specify which calendar system is being used to predict future dates.  = ;Calendar conversion algorithms are available from many sources.  The b= ook "Calendrical Calculations" is thorough, although I find it dif= ficult to follow because of the author's style.   "Standard C= Date/Time Library" (available from Amazon.com) is much more easily fol= lowed, and appears very thorough, although I have not had a chance to fully = go over it for its usefulness in all the calendar systems, as I just got it.=  There are several other good references, including the "Explanat= ory Supplement to the Astronomical Almanac", whatever is used, conversi= ons can be made from the Julian day count and back with a minimum effort of = programming, giving a much more universally useful database.


> BEGIN:STANDARD

  This is a misnomer in some cases due to information stated abo= ve when addressing daylight savings time.  It probably, however, can be= understood in most cases, Argentina being a recent exception.  There a= re other exceptions that will come up, so it may be of some use to define wh= at is meant by Standard.


>
> Good point --- PLEASE PLEASE contribute to the <= U>ietf-calendar@imc.org
> list with your suggestions. It will proceed without them if= you
> don't!

    I think possibly an interface to the data (the equ= ivalent of a header file) would be the main thing I suggest, rather than hav= ing the data mixed with misleading symbols.  In addition, with all resp= ect to the former British Empire, I would suggest using positive offsets fro= m the west side of the International Date line to avoid the use of negative = offsets.  This eliminates any date confusion in calculations and notati= ons.  Using the west side of the International Date Line gives a clear = and unchanging representation of the last hour of the present time at any ti= me, and is free of the confusion that can arrive when London uses daylight s= avings time, which believe it or not, happens a lot with people.  This = is especially important when writing code or recording data that needs to be= parsed by humans as well as read by machines.

>
> -MOST- Applications will care about their own time zone and perhaps > that of their offices in other countries. So I don't think that
> a typical application will download the entire database. And
> it will often never care about the past.

  The past is about the only thing we can pin down with certaint= y, unfortunate as this is.  IATA and the OAG have had a very difficult = time scheduling three years in advance for all airports.  It has caused= numerous headaches with flight scheduling.  I think a few cues should = be taken from their experience when proposing something that is dependable. =  The best I have been able to come up with, working on this full time, = is a prediction six months in advance, with small updates every month that d= on't affect the majority of the world.  Whatever is developed, it has t= o be dynamic and presented as such to its users.  Otherwise it will loo= se credibility very fast, and with no one willing to take responsibility as = IATA does for the airlines, it will not be used.

  I currently print a 30" by 40" map of the time zones= of the world every month or so.  It takes me 3 days to enter all the c= hanges since the last printing.  I have not yet printed one that was no= t out of date the day it was printed.  It was a little frustrating at f= irst, but finally it helped me to develop a system that can be used, and is = dynamic.

  The method I use, which I refer to as Global Time Systems=81, is= currently  ported as a library to the Mac OS and ready to port to Wind= ows.  I have also ported it to an obscure 8 bit microprocessor, and hav= e it successfully running.  It takes up about 115K in the 8 bit micro; = the Mac version is 168K; the Windows library is still to be determined, but = I expect it to be about the same as the Mac version.  It does not have = any interface built now except in my development platform, but will have one= soon, as it is being ported to a clock program now sold for the Mac and bei= ng ported to Windows.

  Any arrangement of symbols can be used to access the data. &nb= sp;These symbols are what you are calling the time zone names.  I belie= ve the choice of symbols is as important as the understanding of what the sy= mbols are representing.  If the choice of symbols clouds this understan= ding, another more generic symbol should be selected.  The data it is r= epresenting can then be of any depth; it can be four dimensional, three dime= nsional, or list based.

  There is always the concern about legacy code and data when ma= king changes.  I think this can be addressed with the proper interface = or header file equivalent.  What should be our concern is that the code= and data we generate and use is forward compatible, as this is something th= at we can do something about now with a little thought and planning, but is = much more difficult to correct in the future without affecting a large numbe= r of programs that have come to rely on what has been written.

   I hope that this is not too big a chunk of information t= o be useful to this list.  I posted this at the encouragement of Doug, = and because I would like to see something develop that will be useful in the= long run.  In addition, I would like to see that the methodology I hav= e developed will interface with what is being developed here, as there are s= everal large users that have said that they will use what I have developed f= or embedded systems.

Sincerely,

Rives McDow

 --MS_Mac_OE_3032610490_1726047_MIME_Part-- From owner-ietf-calendar@imc.org Sun Feb 6 01:19:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13682 for ; Sun, 6 Feb 2000 01:19:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA20687 for ietf-calendar-bks; Sat, 5 Feb 2000 21:58:09 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20681 for ; Sat, 5 Feb 2000 21:58:08 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA12890 for ; Sat, 5 Feb 2000 21:56:53 -0800 (PST) Received: from netscape.com ([198.93.95.223]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FPHVCG00.378; Sat, 5 Feb 2000 22:00:16 -0800 Message-ID: <389D0DE6.40940BF3@netscape.com> Date: Sat, 05 Feb 2000 22:00:06 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Rives McDow CC: ietf-calendar@imc.org Subject: Re: time zone database interface and formatting References: Content-Type: multipart/mixed; boundary="------------819F16D23A7EF04DB9B535FA" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------819F16D23A7EF04DB9B535FA Content-Type: multipart/alternative; boundary="------------DB5E4BAB6CB173B2C5D608F5" --------------DB5E4BAB6CB173B2C5D608F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rives McDow wrote: > ... > I hope that this is not too big a chunk of information to be useful > to this list. I posted this at the encouragement of Doug, and because > I would like to see something develop that will be useful in the long > run. In addition, I would like to see that the methodology I have > developed will interface with what is being developed here, as there > are several large users that have said that they will use what I have > developed for embedded systems. > > Sincerely, > > Rives McDow Rives, This was absolutely fantastic input. I'm going to have to read this over a few more times. This working group needs your expertise on this matter. We want to get it right. Any chance you will be coming to the upcoming IETF meeting? -Steve --------------DB5E4BAB6CB173B2C5D608F5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Rives McDow wrote:
...
  I hope that this is not too big a chunk of information to be useful to this list.  I posted this at the encouragement of Doug, and because I would like to see something develop that will be useful in the long run.  In addition, I would like to see that the methodology I have developed will interface with what is being developed here, as there are several large users that have said that they will use what I have developed for embedded systems.

Sincerely,

Rives McDow

Rives,

This was absolutely fantastic input. I'm going to have to read this over a few more times. This working group needs your expertise on this matter. We want to get it right.

Any chance you will be coming to the upcoming IETF meeting?

-Steve --------------DB5E4BAB6CB173B2C5D608F5-- --------------819F16D23A7EF04DB9B535FA Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------819F16D23A7EF04DB9B535FA-- From owner-ietf-calendar@imc.org Sun Feb 6 03:15:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01293 for ; Sun, 6 Feb 2000 03:15:40 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA22065 for ietf-calendar-bks; Sat, 5 Feb 2000 23:57:37 -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 XAA22061 for ; Sat, 5 Feb 2000 23:57:35 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA21226 for ietf-calendar@imc.org; Sun, 6 Feb 2000 00:00:03 -0800 (PST) Date: Sun, 6 Feb 2000 00:00:03 -0800 (PST) From: Doug Royer Message-Id: <200002060800.AAA21226@royer.com> X-Authentication-Warning: royer.com: doug set sender to Doug@Royer.Com using -r To: ietf-calendar@imc.org Subject: CALSCH Action Items Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of action items for the CALSCH Working Group. This list will be sent out once a week and updated as often as practical (That means if I am not available it may take an extra week or two before you see your changes). Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM . There are three parts to this action list: (W) Working group action items. (C) CAP editor action items. (I) iCalendar action items (Frank Dawson) Each action item will be assigned a unique ID that will aid in tracking the items. ------------------------------------------------------------------------------ Working Group Action Items Where Resolution is one of: U - undecided. Y - Chair determined consensus is in favor of the proposal. N - Chair determined consensus is NOT in favor of the proposal. D - Dropped. Chair has decided that it may never reach consensus. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-1 CAP Use HTTP as transport N W-2 CAP If all booked and scheduled U appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. U [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema U W-14 CAP VEVENT Schema U W-15 CAP VTODO Schema U W-16 CAP VJOURNAL Schema U W-17 CAP VCAR Schema U W-18 CAP UPN definition, including anonymous U user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and U static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED U and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA U W-23 CAP Calendar property to allow/disallow U overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues U W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH U (CAP-00 - 12.2) Will there need to be one? U Optional? U W-29 Import/Export U W-30 Transport protocol name (transport vs U application layer) W-31 NOOP command? U W-32 NOOP advisory only? U W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are U they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? U ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@imc.org Mon Feb 7 12:06:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15415 for ; Mon, 7 Feb 2000 12:06:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA29649 for ietf-calendar-bks; Mon, 7 Feb 2000 08:41:27 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29645 for ; Mon, 7 Feb 2000 08:41:25 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id LAA12708; Mon, 7 Feb 2000 11:46:14 -0500 Message-ID: <389EF6D6.46EBDC4@ecal.com> Date: Mon, 07 Feb 2000 11:46:14 -0500 From: John Stracke X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: Rives McDow CC: ietf-calendar@imc.org Subject: Re: time zone database interface and formatting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rives McDow wrote: > In addition, with all respect to the former British Empire, I > would suggest using positive offsets from the west side of the > International Date line to avoid the use of negative offsets. Just for clarification: do you advocate using the date line itself, or the 180th meridian? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |He wondered if Elli was going to buy that | |francis@ecal.com|explanation. His taste for heavily-armed | | |girlfriends did have its drawbacks. | \==============================================================/ From owner-ietf-calendar@imc.org Mon Feb 7 12:16:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15822 for ; Mon, 7 Feb 2000 12:16:50 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA29934 for ietf-calendar-bks; Mon, 7 Feb 2000 08:53:52 -0800 (PST) Received: from biz1.mailsrvcs.net (biz1.gte.net [207.115.153.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29929 for ; Mon, 7 Feb 2000 08:53:51 -0800 (PST) Received: from [166.72.184.210] by biz1.mailsrvcs.net (Post.Office MTA v3.5.3 release 223 ID# 0-64117L5000S0V35) with ESMTP id net for ; Mon, 7 Feb 2000 10:56:05 -0600 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Mon, 07 Feb 2000 08:58:05 -0800 Subject: corrective measures From: Rives McDow To: ietf Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="MS_Mac_OE_3032758685_523308_MIME_Part" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3032758685_523308_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Earlier I made a post that was misinterpreted. Here is a correcting bit. I wasn't proposing to convert to the Julian Calendar, but to the julian day count. This use of a name that is so similar to an existing calendar system has caused a lot of confusion, but there is no relationship at all between the two methods. The julian day count was proposed by the astronomer Scallinger in some former century, after running into problems converting back and forth between ancient calendar systems to pin down astronomical events. Scallinger picked a calendrical conjunction that predated all the calendar systems in history with the exception, I believe of the Mayan calendar. This date was Gregorian 4713 BC Jan. 1, I believe. I am travelling right now, and my references are at home, along with all my source and header files. Today is julian Day 2451581, or 2451582.1717 right now to be exact, as the day is usually expressed as a float referenced to Greenwich. The modified julian date, used by Nasa and others not wanting or having space for such a large number in their memory map or processor capabilities, is the julian day minus 2,400,000. Today's modified julian day is 51581. Either works, as the other can be derived by simple subtraction or addition. Here is a url that has a pretty good overview of today's date in various calendar systems. http://www.ecben.net/calendar.shtml This can seem a little overwhelming when first considering the coding. However, I have found that calendar systems are solar, lunar, or solar/lunar, and that the differences are primarily the setting of the epoch, with a few exceptions (Hebrew being one). Converting back and forth between the julian day count and any calendar system is fairly straightforward, using the proper algorithm. I reference the julian day count to the west side of the International Date Line, for reasons stated earlier. This has proved to be the best approach in the applications I have developed so far, but I am open to arguments. Sincerely, Rives McDow --MS_Mac_OE_3032758685_523308_MIME_Part Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable corrective measures

Earlier I made a post that was misinterpreted.  Here is a correcting b= it.

   I wasn't proposing to convert to the Julian Calendar= , but to the julian day count.  This use of a name that is so similar t= o an existing calendar system has caused a lot of confusion, but there is no= relationship at all between the two methods.  The julian day count was= proposed by the astronomer Scallinger in some former century, after running= into problems converting back and forth between ancient calendar systems to= pin down astronomical events.   Scallinger picked a calendrical c= onjunction that predated all the calendar systems in history with the except= ion, I believe of the Mayan calendar.  This date was Gregorian 4713 BC = Jan. 1, I believe.  I am travelling right now, and my references are at= home, along with all my source and header files.  Today is julian Day = 2451581, or 2451582.1717 right now to be exact, as the day is usually expres= sed as a float referenced to Greenwich.  The modified julian date, used= by Nasa and others not wanting or having space for such a large number in t= heir memory map or processor capabilities, is the julian day minus 2,400,000= .  Today's modified julian day is 51581.  Either works, as the oth= er can be derived by simple subtraction or addition.  Here is a url tha= t has a pretty good overview of today's date in various calendar systems. &n= bsp;

http://www.ecben.net/calendar.shtml

   This can seem a little overwhelming when first consideri= ng the coding.  However, I have found that calendar systems are solar, = lunar, or solar/lunar, and that the differences are primarily the setting of= the epoch, with a few exceptions (Hebrew being one).  Converting back = and forth between the julian day count and any calendar system is fairly str= aightforward, using the proper algorithm.  I reference the julian day c= ount to the west side of the International Date Line, for reasons stated ear= lier.  This has proved to be the best approach in the applications I ha= ve developed so far, but I am open to arguments.

Sincerely,


Rives McDow --MS_Mac_OE_3032758685_523308_MIME_Part-- From owner-ietf-calendar@imc.org Mon Feb 7 20:16:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24970 for ; Mon, 7 Feb 2000 20:16:14 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA10515 for ietf-calendar-bks; Mon, 7 Feb 2000 16:48:58 -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 QAA10511 for ; Mon, 7 Feb 2000 16:48:56 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id QAA22125 for ietf-calendar@imc.org; Mon, 7 Feb 2000 16:51:43 -0800 (PST) Date: Mon, 7 Feb 2000 16:51:43 -0800 (PST) From: Doug Royer Message-Id: <200002080051.QAA22125@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 (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. U [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema U W-14 CAP VEVENT Schema U W-15 CAP VTODO Schema U W-16 CAP VJOURNAL Schema U W-17 CAP VCAR Schema U W-18 CAP UPN definition, including anonymous U user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and U static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED U and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA U W-23 CAP Calendar property to allow/disallow U overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues U W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH U (CAP-00 - 12.2) Will there need to be one? U Optional? U W-29 Import/Export U W-30 Transport protocol name (transport vs U application layer) W-31 NOOP command? U W-32 NOOP advisory only? U W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are U they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? U ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@imc.org Mon Feb 7 21:30:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25486 for ; Mon, 7 Feb 2000 21:30:02 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA11878 for ietf-calendar-bks; Mon, 7 Feb 2000 17:58:14 -0800 (PST) Received: from smthqwsm01.siebel.com (ATHM-216-217-xxx-201.home.net [216.217.80.201] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA11871 for ; Mon, 7 Feb 2000 17:58:12 -0800 (PST) Received: from 10.1.24.32 by smthqwsm01.siebel.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Mon, 07 Feb 00 17:44:56 -0800 X-Server-Uuid: 345c517b-5fb4-11d3-a613-00508b3222df Received: from 206.154.116.15 by smthqwsm01.siebel.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Mon, 07 Feb 00 09:00:37 -0800 X-Server-Uuid: 345c517b-5fb4-11d3-a613-00508b3222df Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by merlin.siebel.com (8.9.3/8.9.3) with ESMTP id JAA14032 for ; Mon, 7 Feb 2000 09:05:46 -0800 (PST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA29934 for ietf-calendar-bks; Mon, 7 Feb 2000 08:53:52 -0800 (PST) Received: from biz1.mailsrvcs.net (biz1.gte.net [207.115.153.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29929 for ; Mon, 7 Feb 2000 08:53:51 -0800 (PST) Received: from [166.72.184.210] by biz1.mailsrvcs.net (Post.Office MTA v3.5.3 release 223 ID# 0-64117L5000S0V35) with ESMTP id net for ; Mon, 7 Feb 2000 10:56:05 -0600 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Mon, 07 Feb 2000 08:58:05 -0800 Subject: corrective measures From: "Rives McDow" To: "ietf" Message-ID: MIME-Version: 1.0 List-Archive: List-ID: List-Unsubscribe: X-WSS-ID: 1481AA9217681-01-01 Content-Type: multipart/alternative; boundary=MS_Mac_OE_3032758685_523308_MIME_Part Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3032758685_523308_MIME_Part Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Earlier I made a post that was misinterpreted. Here is a correcting bit. I wasn't proposing to convert to the Julian Calendar, but to the julian day count. This use of a name that is so similar to an existing calendar system has caused a lot of confusion, but there is no relationship at all between the two methods. The julian day count was proposed by the astronomer Scallinger in some former century, after running into problems converting back and forth between ancient calendar systems to pin down astronomical events. Scallinger picked a calendrical conjunction that predated all the calendar systems in history with the exception, I believe of the Mayan calendar. This date was Gregorian 4713 BC Jan. 1, I believe. I am travelling right now, and my references are at home, along with all my source and header files. Today is julian Day 2451581, or 2451582.1717 right now to be exact, as the day is usually expressed as a float referenced to Greenwich. The modified julian date, used by Nasa and others not wanting or having space for such a large number in their memory map or processor capabilities, is the julian day minus 2,400,000. Today's modified julian day is 51581. Either works, as the other can be derived by simple subtraction or addition. Here is a url that has a pretty good overview of today's date in various calendar systems. http://www.ecben.net/calendar.shtml This can seem a little overwhelming when first considering the coding. However, I have found that calendar systems are solar, lunar, or solar/lunar, and that the differences are primarily the setting of the epoch, with a few exceptions (Hebrew being one). Converting back and forth between the julian day count and any calendar system is fairly straightforward, using the proper algorithm. I reference the julian day count to the west side of the International Date Line, for reasons stated earlier. This has proved to be the best approach in the applications I have developed so far, but I am open to arguments. Sincerely, Rives McDow --MS_Mac_OE_3032758685_523308_MIME_Part Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable corrective measures

Earlier I made a post that was misinterpreted.  Here is a correcting b= it.

   I wasn't proposing to convert to the Julian Calendar= , but to the julian day count.  This use of a name that is so similar t= o an existing calendar system has caused a lot of confusion, but there is no= relationship at all between the two methods.  The julian day count was= proposed by the astronomer Scallinger in some former century, after running= into problems converting back and forth between ancient calendar systems to= pin down astronomical events.   Scallinger picked a calendrical c= onjunction that predated all the calendar systems in history with the except= ion, I believe of the Mayan calendar.  This date was Gregorian 4713 BC = Jan. 1, I believe.  I am travelling right now, and my references are at= home, along with all my source and header files.  Today is julian Day = 2451581, or 2451582.1717 right now to be exact, as the day is usually expres= sed as a float referenced to Greenwich.  The modified julian date, used= by Nasa and others not wanting or having space for such a large number in t= heir memory map or processor capabilities, is the julian day minus 2,400,000= .  Today's modified julian day is 51581.  Either works, as the oth= er can be derived by simple subtraction or addition.  Here is a url tha= t has a pretty good overview of today's date in various calendar systems. &n= bsp;

http://www.ecben.net/calendar.shtml

   This can seem a little overwhelming when first consideri= ng the coding.  However, I have found that calendar systems are solar, = lunar, or solar/lunar, and that the differences are primarily the setting of= the epoch, with a few exceptions (Hebrew being one).  Converting back = and forth between the julian day count and any calendar system is fairly str= aightforward, using the proper algorithm.  I reference the julian day c= ount to the west side of the International Date Line, for reasons stated ear= lier.  This has proved to be the best approach in the applications I ha= ve developed so far, but I am open to arguments.

Sincerely,


Rives McDow --MS_Mac_OE_3032758685_523308_MIME_Part-- From owner-ietf-calendar@imc.org Tue Feb 8 21:34:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15102 for ; Tue, 8 Feb 2000 21:34:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA25640 for ietf-calendar-bks; Tue, 8 Feb 2000 17:51:49 -0800 (PST) Received: from biz1.mailsrvcs.net (biz1.gte.net [207.115.153.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA25636 for ; Tue, 8 Feb 2000 17:51:47 -0800 (PST) Received: from [166.72.184.66] by biz1.mailsrvcs.net (Post.Office MTA v3.5.3 release 223 ID# 0-64117L5000S0V35) with ESMTP id net for ; Tue, 8 Feb 2000 19:53:59 -0600 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) Date: Tue, 08 Feb 2000 17:55:56 -0800 Subject: julian day count From: Rives McDow To: ietf Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="MS_Mac_OE_3032877359_65379_MIME_Part" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3032877359_65379_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Joseph Meyers pointed out some errors in my presentation of the julian day count. I notice in the ietf-calendar archives you comments on use of Julian days. One thing that was perhaps not made clear enough in those messages: the JD count is referenced to UT noon, and so might be more appropriate if you wish to work from the 180-degree meridian. The MJD count, however, is referenced to UT midnight - the formula should, I think, have a subtraction of 2400000.5. These refer to particular points of time rather than to local calendar days. If referring to past times in them, you would presumably use a base 24/60/60 system rather than the conventional decimal. Rives McDow --MS_Mac_OE_3032877359_65379_MIME_Part Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable julian day count
Joseph Meyers pointed out some errors in my presentation of the julian day = count.  

I notice in the ietf-calendar archives you comments on use of Julian da= ys.
One thing that was perhaps not made clear enough in those messages: the JD<= BR> count is referenced to UT noon, and so might be more appropriate if you
wish to work from the 180-degree meridian.  The MJD count, however, is=
referenced to UT midnight - the formula should, I think, have a
subtraction of 2400000.5.  These refer to particular points of time ra= ther
than to local calendar days.  If referring to past times in them, you<= BR> would presumably use a base 24/60/60 system rather than the conventional decimal.

Rives McDow=20 --MS_Mac_OE_3032877359_65379_MIME_Part-- From owner-ietf-calendar@imc.org Tue Feb 8 22:01:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16209 for ; Tue, 8 Feb 2000 22:01:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA28651 for ietf-calendar-bks; Tue, 8 Feb 2000 18:23:03 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA28647 for ; Tue, 8 Feb 2000 18:23:00 -0800 (PST) Received: from thinkpad600e (A200-39.PPP.FTWO.TX.VERIO.NET [206.50.209.39]) by mailhost.onramp.net (8.9.3/8.9.3) with SMTP id UAA09957; Tue, 8 Feb 2000 20:25:44 -0600 (CST) From: "Rik Drummond" To: "Gregg V. Rock" , Cc: "BethM" , "IETF-calendar" Subject: RE: Dawn Eagan @ BGI Date: Tue, 8 Feb 2000 20:25:46 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.1.20000207155156.00a81a40@mail.brainstorm-group.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit XML which forms such a wonderful base for EC across the world is fragmenting in to dissimilar standards in exactly the same way that EDI did in the early 1970's. If this trend continues people will be thinking the same about xml in twenty years as the EC community thinks about EDI now... which is not often positive. Come hear about an internationally sponsored workgroups vision and progress in the area of interoperable EC standards which work across industries, business environments and languages. This workgroup is the only chance of establishing a worldwide EC standard in this decade. -----Original Message----- From: Gregg V. Rock [mailto:gvr@brainstorm-group.com] Sent: Monday, February 07, 2000 2:53 PM To: drummond@onramp.com Subject: Dawn Eagan @ BGI Rik - here's how we'll list your talk in Orlando unless you have any objections. Creating A Global e-Business Framework Rik Drummond, President, Drummond Group and member of the ebXML Steering Committee Best regards, Gregg V. Rock 508-393-3266 phone President 508-393-8845 fax BrainStorm Group, Inc. www.brainstorm-group.com Producers of: SMARTsourcing Conference & Expo Series XMLeadership Conference & Expo Series e-Business Strategy Conference Series YEAR 2000 National Symposium Series From owner-ietf-calendar@imc.org Fri Feb 11 22:33:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03925 for ; Fri, 11 Feb 2000 22:33:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA05288 for ietf-calendar-bks; Fri, 11 Feb 2000 19:05:07 -0800 (PST) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA05283 for ; Fri, 11 Feb 2000 19:05:00 -0800 (PST) From: pregen@egenconsulting.com To: "Paul B. Hill" , ietf-calendar@imc.org Subject: Security X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Fri, 11 Feb 2000 22:07:52 -0500 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at 02/11/2000 10:08:09 PM, Serialize complete at 02/11/2000 10:08:09 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0011208085256883_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0011208085256883_= Content-Type: text/plain; charset="us-ascii" Paul, I have not seen much on the list regarding security and what we will be implementing or recommending as part of CAP. Was that discussed at the Interim? Can you put something on the list that briefly describes where we are headed. Thanks. I've gone back through the notes and messages and can not find much - but I know this is a key component. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0011208085256883_= Content-Type: text/html; charset="us-ascii"
Paul, I have not seen much on the list regarding security and what we will be implementing or recommending as part of CAP.  Was that discussed at the Interim? Can you put something on the list that briefly describes where we are headed.  Thanks.  I've gone back through the notes and messages and can not find much - but I know this is a key component.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0011208085256883_=-- From owner-ietf-calendar@imc.org Sat Feb 12 12:21:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23843 for ; Sat, 12 Feb 2000 12:21:31 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA28355 for ietf-calendar-bks; Sat, 12 Feb 2000 08:59:33 -0800 (PST) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28349 for ; Sat, 12 Feb 2000 08:59:30 -0800 (PST) From: pregen@egenconsulting.com To: ietf-calendar@imc.org Subject: Undecided items on Action Items list X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Sat, 12 Feb 2000 12:02:36 -0500 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at 02/12/2000 12:02:38 PM, Serialize complete at 02/12/2000 12:02:38 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005D7AFD85256883_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005D7AFD85256883_= Content-Type: text/plain; charset="us-ascii" The action items list posted by Doug Royer still has quite a few items flagged as Undecided. I have isolated those items below. I have not seen enough activity on the list to be able to deem whether there is concensus or not on any of these items. I would like to ask the list to provide comments and/or feedback on these items, either for or against, so we can put them to rest and finish the document for March. Thanks for your help. Working Group Action Items Where Resolution is one of: U - undecided. The following are a list of proposals and their status in the WG: WG Action Item Resolution -------------- ---------- W-2 CAP If all booked and scheduled U appointments are in same table W-9 CAP MOVE method. Issues with VCARs. U [see note in CAP 7.2.1.5] 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-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-28 Cal-Props - PATH U (CAP-00 - 12.2) Will there need to be one? U Optional? U W-29 Import/Export U W-30 Transport protocol name (transport vs U application layer) W-31 NOOP command? U W-32 NOOP advisory only? U W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are U they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? U --=_alternative 005D7AFD85256883_= Content-Type: text/html; charset="us-ascii"

The action items list posted by Doug Royer still has quite a few items flagged as Undecided.  I have isolated those items below.   I have not seen enough activity on the list to be able to deem whether there is concensus or not on any of these items.  I would like to ask the list to provide comments and/or feedback on these items, either for or against, so we can put them to rest and finish the document for March. Thanks for your help.

                 Working Group Action Items  

Where Resolution is one of:  U - undecided.
The following are a list of proposals and their status in the WG:

WG Action Item                                   Resolution
--------------                                   ----------

W-2 CAP If all booked and scheduled                 U
   appointments are in same table

W-9 CAP MOVE method. Issues with VCARs.             U
   [see note in CAP 7.2.1.5]

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

W-29 Import/Export                                  U

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

W-31 NOOP command?                                  U

W-32 NOOP advisory only?                            U

W-33 Should DISCONNECT be called QUIT?              U

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

W-35 Move DNS and SLP to seperate draft?            U --=_alternative 005D7AFD85256883_=-- From owner-ietf-calendar@imc.org Sun Feb 13 03:21:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01662 for ; Sun, 13 Feb 2000 03:21:12 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA25950 for ietf-calendar-bks; Sat, 12 Feb 2000 23:57:04 -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 XAA25943 for ; Sat, 12 Feb 2000 23:57:02 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA28471 for ietf-calendar@imc.org; Sun, 13 Feb 2000 00:00:06 -0800 (PST) Date: Sun, 13 Feb 2000 00:00:06 -0800 (PST) From: Doug Royer Message-Id: <200002130800.AAA28471@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 (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. U [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema U W-14 CAP VEVENT Schema U W-15 CAP VTODO Schema U W-16 CAP VJOURNAL Schema U W-17 CAP VCAR Schema U W-18 CAP UPN definition, including anonymous U user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and U static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED U and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA U W-23 CAP Calendar property to allow/disallow U overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues U W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH U (CAP-00 - 12.2) Will there need to be one? U Optional? U W-29 Import/Export U W-30 Transport protocol name (transport vs U application layer) W-31 NOOP command? U W-32 NOOP advisory only? U W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are U they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? U ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@imc.org Mon Feb 14 12:14:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17983 for ; Mon, 14 Feb 2000 12:14:16 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA10147 for ietf-calendar-bks; Mon, 14 Feb 2000 08:34:41 -0800 (PST) Received: from lb4.listbot.com (lb4.listbot.com [204.71.191.14]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA10143 for ; Mon, 14 Feb 2000 08:34:40 -0800 (PST) Received: (qmail 5245 invoked by uid 60001); 14 Feb 2000 16:39:32 -0000 Date: 14 Feb 2000 16:39:32 -0000 Message-ID: <950546372.5242.qmail@ech> Mailing-List: ListBot mailing list contact ooh_ooh_ooh-help@listbot.com Delivered-To: forwarder for ooh_ooh_ooh@listbot.com From: ListBot Verifier To: ietf-calendar@imc.org Subject: REPLY REQUIRED: Very Very Funny Jokes Subscription Verify Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thank you for your request to join Very Very Funny Jokes! YOU MUST REPLY TO THIS MESSAGE TO JOIN THE LIST. == Simply reply with a blank message to join. == The list owner has included the following welcome message: =========================================================== You are receiving this message because either you or a friend wanted us to deliver daily jokes to your email box, and submitted this email address at our website. Click Reply to have very Very Funny Jokes delivered, Probably every day, but I'm on vacation a lot so..... You can always cancel, so give us a try :) See you tommorow!!! =========================================================== This verification message is used to confirm that we are able to send you mail, and protects you in case someone forges a subscription request in your name. If you believe this was a forged subscription request, ignore this message and you will not be added to the mailing list. If you are having problems using the reply function in your e-mail client, the address to respond to is: v-7AC9DF5F798F6473@listbot.com Visit this list's home page at: http://ooh_ooh_ooh.listbot.com Thanks! Sincerely, The MSN ListBot Team http://www.listbot.com/ From owner-ietf-calendar@imc.org Mon Feb 14 19:05:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27022 for ; Mon, 14 Feb 2000 19:05:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25213 for ietf-calendar-bks; Mon, 14 Feb 2000 15:43:34 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25058; Mon, 14 Feb 2000 15:34:23 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA00271; Mon, 14 Feb 2000 18:37:05 -0500 (EST) Message-Id: <200002142337.SAA00271@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: apps area chairs and working groups: ; cc: ietf@ietf.org reply-to: ietf@ietf.org From: Keith Moore Subject: IETF Adelaide and interim meetings for APPS WGs Date: Mon, 14 Feb 2000 18:37:05 -0500 Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It has come to the attention of the Applications Area Directors that one or more Applications area working groups have elected to not meet in Adelaide, and instead to hold an "interim meeting" in the United States, presumably because of distance and/or cost issues. IETF is an international organization, and it is IETF's longstanding practice to hold its meetings in various locations around the planet. This serves both to encourage wider participation in IETF and also to more fairly distribute travel costs and inconvenience (over time) among all participants. The scheduleing of an interim WG meeting in the US in lieu of a WG meeting in Adelaide undermines this policy. This is insulting to non-US participants of IETF (many of whom have attended meetings in the US for years), embarassing to IETF as a whole, and a threat to IETF's international stature. Even if a working group has few participants outside the United States, a working group does not work in isolation from other working groups. Attendance at IETF meetings is an invaluable mechanism for cross-group collaboration. RFC 2418 states: Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. Since normal working group meetings require advance notification via email to the entire IETF list, and the process for getting a meeting slot involves prior approval of the Area Directors, the same requirements apply to interim working group meetings. Part of the reason for prior approval being required is to ensure that the locations of the meetings are not being chosen to favor certain participants over others. There have been several violations of this policy since publication of RFC 2418. Therefore, - All interim meetings within the Applications Area which were not previously and explicitly approved by the Applications Area Directors, are hereby cancelled. - No Applications Area group will hold any interim meeting prior to April 15. - No Applications Area group which does not hold a meeting in Adelaide, will hold any interim meeting prior to July 31. (i.e. prior to the Pittsburg IETF meeting) - This applies to all face to face meetings held for the purpose of conducting working group discussion and to which the working group is invited, even if labelled "informal" or otherwise labelled to distinguish them from official working group meetings. - Exceptions to this policy may be made for recently chartered groups, but Area Director approval is still required for such groups to schedule interim meetings. for the Applications Area Directors, Keith Moore From owner-ietf-calendar@imc.org Mon Feb 14 19:53:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28117 for ; Mon, 14 Feb 2000 19:53:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA26121 for ietf-calendar-bks; Mon, 14 Feb 2000 16:36:53 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26117 for ; Mon, 14 Feb 2000 16:36:52 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA27437 for ; Mon, 14 Feb 2000 16:37:53 -0800 (PST) Received: from netscape.com ([207.1.153.248]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FPY4I900.DLZ for ; Mon, 14 Feb 2000 16:39:45 -0800 Message-ID: <38A8A015.BE9B0A99@netscape.com> Date: Mon, 14 Feb 2000 16:38:45 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: SEQUENCE number on recurrences Content-Type: multipart/mixed; boundary="------------F25DE512B107C11EC6973C99" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F25DE512B107C11EC6973C99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, Say that you create a recurring event. Now let's say that you update the DTSTART value of a single instance of that recurring event. Do you need to bump the sequence number of just the single instance you changed or do you bump the sequence number for all instances? I wasn't clear on this after reading the Sequence Number text in RFC 2445. -Steve --------------F25DE512B107C11EC6973C99 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------F25DE512B107C11EC6973C99-- From owner-ietf-calendar@imc.org Tue Feb 15 11:15:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11857 for ; Tue, 15 Feb 2000 11:15:07 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA25868 for ietf-calendar-bks; Tue, 15 Feb 2000 07:49:07 -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 HAA25864 for ; Tue, 15 Feb 2000 07:49:05 -0800 (PST) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: ietf-calendar@imc.org Subject: Groups revisited X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Tue, 15 Feb 2000 10:54:34 -0500 X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Release 5.0.2b |December 16, 1999) at 02/15/2000 10:52:01 AM, Serialize by Notes Client on Bruce Kahn/Iris(Release 5.0.2b |December 16, 1999) at 02/15/2000 10:52:01 AM, Serialize complete at 02/15/2000 10:52:01 AM, Itemize by Notes Client on Bruce Kahn/Iris(Release 5.0.2b |December 16, 1999) at 02/15/2000 10:52:01 AM, S/MIME Sign complete at 02/15/2000 10:52:01 AM, Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 02/15/2000 10:52:34 AM, Serialize complete at 02/15/2000 10:52: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: text/plain; charset="us-ascii" Ive been more than a little busy lately to keep up w/all the threads going on but I have been chewing on the issue of groups in CAP and how we can/should be dealing with them. After going back to the basics a bit I think we do not really need to do much, if any, extra effort to have them. Here is my reasoning: When a CU authenticates to the CS the credentialling system will output a series of UPNs for that mechanism and set of credentials. So what is to prevent that authentication mechanism from including a UPN that both Frank, Steve, Doug, Pat and Alex have that is, say, "CAPEditors@calsched.apps.ietf.org". This is in effect a group UPN since all 5 of them share it. The UPN can then be used as part of a VCAR to give them write access to a particular calendar or entry. When any of them try to modify the particular calendar or entry the CS can check their list of UPNs to see if they have the proper rights. The real work now shifts from doing some evaluation for every access (where some previous ideas were seemingly heading) to being handled once at AUTHENTICATE time. This shift means that we need to be very precise in how we spec out our authentication mechanisms so that every vendor who implements it will generate the correct set of UPNs. This task may be non-trivial but it simplifies MUCH of the later work. Ive tried to be as clear as I can describing my train of thought w/o being too rambling or circumspect. After a second pass at it I do not see any glaring logic flaws so I thought Id propose this to the group to see if its off in left field or if we just overlooked something so simple by jumping to more complex solutions... 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... ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMjE1MTU1MjAxWjAj BgkqhkiG9w0BCQQxFgQUlBBP8Q0ef8xDETzq646d88xtGAowTAYJKoZIhvcNAQkP MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQAeB1pqq1m+/Xj8eLboE Slv3Uy5rq4Ydb3lMviOzlaCacpGCyrUkD1SiIgVk2ksC+dGa/bEC9YqAo+XicD2f J9AAAAAAAAAAAA== ---------z01886_boundary_sign-- From owner-ietf-calendar@imc.org Tue Feb 15 11:15:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11877 for ; Tue, 15 Feb 2000 11:15:49 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA25972 for ietf-calendar-bks; Tue, 15 Feb 2000 07:52:21 -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 HAA25968 for ; Tue, 15 Feb 2000 07:52:19 -0800 (PST) From: Bruce_Kahn@iris.com To: CalSched IETF Subject: Re: W-19 - open item - can we defer it? X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Tue, 15 Feb 2000 10:57:44 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 02/15/2000 10:55:49 AM, Serialize complete at 02/15/2000 10:55:49 AM 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: Doug replied: >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. Of course the CS will have to do some expansion to properly evaluate the entries. Ive never claimed it would not have to. However, doing it at the time you set the VCAR is NOT the proper time. The proper way should be when they are needed (say when you Authenticate and the CS builds up any meta information about the CU it needs for later work). If the CS does an 'up front' expansion, you lose the usefulness of groups. They become some hacked up form of macro. If the admins/CU change the users in a group, just how would the CS know to go back and 'update' any VCARs that it previously exploded out?! Thats MUCH MUCH more work than doing dynamic group expansion when necessary and its just plain ugly! (Imagine how the CS would try to deal with removal of a CU from 1 group but not another where both are on the same VCAR; would it be good enough to realize that it should not really remove a CU?? Ugh!!) >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. For interoperability to work, this cannot be just a hit or miss deal. We must have just 1 way to do this or groups on VCARs wont function consistantly. Imagine one CUA that just uses groups for VCARs but the CS does static explosion of members. Besides the mess I pointed out above, just what would the scenario be for what the CUA sees when it reads the VCARs back (or sets new values). Would the CUA be required to send the FULL VCARs list back (it would have to in your mixed behaviour case) or could it just send a new ADD message with a new VCAR with a new user?? If the CUA were to query the CS for the VCARs, would you expect the CS to rebuild the original list that the CUA set or just return the exploded entries? As a CUA writer I would find that what I sent in was not the same as when I got back and Id have to do some form of reconciliation. And all for nothing really... (There could be cases where VCAR ADDs do not 'take' and that should be indicated when the CUA attempts the ADD, not by guessing based on what comes back on a query.) >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). We have already have some directory (LDAP or other really) needs such as how to find out CAP or iTIP addresses, etc so having yet another directory link is not so arcane or horrific. Every CUA/CS will need some form of directory link so it can handle address look and resolution, credential lookups for authentication or UPN checking, etc. There may be some ties between current MUAs/PIMs and the CUAs (ie: Notes has its NAB and your mail file/calendar, Outlook has its MUA/CUA and Address Book, etc). Just wheredo you expect your CUA to store that new CAP address you got off someones vCard?? So far we have not directly required 1 specific directory (LDAP, X.500, Active Directory, etc.) and I dont think we need to expressly call them out. What is probably needed is something like the locating draft that covers how to get said info from different sources. >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. Agreed. Sounds like you want to mandate some specific directory links that both the CUA and CS share. Do you have any particular mechanism in mind or something generalized like the locating draft was? BTW: It is possible that the expansion yields different data for the CUA and the CS if they use different directories (ie: a CUA uses a personal address book or different LDAP server than the, say, LDAP server that the CS uses.) Some could call this an error, others may call this a config/admin issue... > (A.1) If the CS is unable or unwilling to expand the > list, OR the CS administrator has elected not to > allow list expansion: Expand WHEN?? That is the crux here. Expand when added (statically) or when needed (dynamically)?? > 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: [Snip] > > 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. I dont think this would work if there were > 1 lists set on the VCAR. For example, if I set a GRANT 'full access' to the list IrisCSAdmins and I set 'read only access' to the list IrisQEFolks then just how would the CS rebuild the proper VCAR for a user who is a member of > 1 list?? In order for this to work, the CS would have to keep meta information about each UPN in all VCARs and track which group(s) they came from, etc. This still would not solve the problems of A) subsequent list changes not being applied to the VCARs and B) keeping parity with the VCARs input vs output when set and then querried. > (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. Sorry but it does not. The issues of scalability, maintenance and updating are not covered. You covered what the CS could do when VCARs are querried by a CUA, not when they are set or the other issues above. >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. If we do not have a very very common feature of current MUAs and non-RFC 2445 PIMs like groups then we can close up shop and head home. There would be no acceptance by our end users if we say "Hey, guess what?! We have this great new standard for Interpersonal C&S but we decided you cannot have any groups like you do now in your current products." How many medium and large customers would buy a product like that?? 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... From owner-ietf-calendar@imc.org Tue Feb 15 12:12:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14321 for ; Tue, 15 Feb 2000 12:12:42 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA27120 for ietf-calendar-bks; Tue, 15 Feb 2000 08:43:28 -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 IAA27115 for ; Tue, 15 Feb 2000 08:43:26 -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 IAA01900 for ; Tue, 15 Feb 2000 08:46:51 -0800 (PST) Message-ID: <38A982F5.64B48B44@home.royer.com> Date: Tue, 15 Feb 2000 08:46:45 -0800 From: Doug Royer X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF CC: CalSched IETF Subject: Re: SEQUENCE number on recurrences References: <38A8A015.BE9B0A99@netscape.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBD901CB05079A3BE5120E496" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msBD901CB05079A3BE5120E496 Content-Type: multipart/mixed; boundary="------------E5A25936B05749769FEE6AD2" This is a multi-part message in MIME format. --------------E5A25936B05749769FEE6AD2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Mansour wrote: > > Folks, > > Say that you create a recurring event. Now let's say that you update the > DTSTART value of a single instance of that recurring event. Do you need > to bump the sequence number of just the single instance you changed or > do you bump the sequence number for all instances? > > I wasn't clear on this after reading the Sequence Number text in RFC > 2445. Ether way the component as a whole is not the same. It would need a new sequence number. As I recall, you were going to expand the instances and then store them, however that is not iCalendar, its just your storage method. The object instance changed, and via iTIP you would need to be able to tell something important changed. -Doug --------------E5A25936B05749769FEE6AD2 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------E5A25936B05749769FEE6AD2-- --------------msBD901CB05079A3BE5120E496 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMjE1MTY0NjQ1WjAjBgkqhkiG9w0BCQQxFgQU9JwRN3Gt vPuXrPy1MjW3qn0N8YIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYCseCqCK80ldLXEK9NLy1c/x7V/Eg0Gvgk2gBhMJoCZLjbo83wE58oxImBbOydo X2HCDNzFU7WW9P6CKuGynAG3TEcqkpQPlek6SkWeIWHqtYrDM1LTeFdCALc95ILC+dVShRj0 n7tqOMvQBVg+XafgxW+NiSWZmqkdfPVSUrRWmQ== --------------msBD901CB05079A3BE5120E496-- From owner-ietf-calendar@imc.org Tue Feb 15 12:48:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16028 for ; Tue, 15 Feb 2000 12:48:05 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27999 for ietf-calendar-bks; Tue, 15 Feb 2000 09:22:48 -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 JAA27995 for ; Tue, 15 Feb 2000 09:22:47 -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 MAA24961; Tue, 15 Feb 2000 12:41:31 -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 MAA24247; Tue, 15 Feb 2000 12:25:42 -0500 (EST) To: Doug Royer Cc: CalSched IETF Subject: Re: SEQUENCE number on recurrences X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Tue, 15 Feb 2000 12:26:59 -0500 X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2b |December 16, 1999) at 02/15/2000 12:27:03 PM, Serialize complete at 02/15/2000 12:27:03 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005FF34F85256886_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005FF34F85256886_= Content-Type: text/plain; charset="us-ascii" Doug: Agree that the recurrence instance has changed. So, the SEQUENCE value for the instance would be monotonically incremented. But it is a leap, in my mind, to say that the SEQUENCE for any of the other instances MUST also be incremented. I say the specification is correct. It is ambiguous about the other instances, which means "implementation dependent". -- Frank --=_alternative 005FF34F85256886_= Content-Type: text/html; charset="us-ascii"
Doug:

Agree that the recurrence instance has changed. So, the SEQUENCE value for the instance would be monotonically incremented. But it is a leap, in my mind, to say that the SEQUENCE for any of the other instances MUST also be incremented.

I say the specification is correct. It is ambiguous about the other instances, which means "implementation dependent".

-- Frank

--=_alternative 005FF34F85256886_=-- From owner-ietf-calendar@imc.org Tue Feb 15 13:11:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16837 for ; Tue, 15 Feb 2000 13:11:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28413 for ietf-calendar-bks; Tue, 15 Feb 2000 09:49:42 -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 JAA28409 for ; Tue, 15 Feb 2000 09:49:41 -0800 (PST) Received: from home.royer.com (home.royer.com [63.195.80.50]) by royer.com (8.9.1/8.9.1) with SMTP id JAA11728 for ; Tue, 15 Feb 2000 09:53:06 -0800 (PST) Message-Id: <200002151753.JAA11728@royer.com> Date: Tue, 15 Feb 2000 09:53:06 -0800 (PST) From: Doug Royer Reply-To: ietf-calendar@imc.org Subject: Re: SEQUENCE number on recurrences To: ietf-calendar@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6nfpuKGBYbhUzzxE0HhL/g== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > From: Frank_Dawson@lotus.com > Subject: Re: SEQUENCE number on recurrences > Date: Tue, 15 Feb 2000 12:26:59 -0500 > > Doug: > Agree that the recurrence instance has changed. So, the SEQUENCE value for > the instance would be monotonically incremented. But it is a leap, in my > mind, to say that the SEQUENCE for any of the other instances MUST also be > incremented. There is only ONE component. So if you (or anyone) could please send me a VEVENT that has TWO sequence numbers, one for the old value and the other for the new instance that has changed. I could see how a component could exist with TWO VEVENTS, one with an EXDATE or EXRULE. The other with METHOD:ADD and the new DTSTART. However BOTH would have changed, so both would need sequence numbers, the old one with the new EXDATE/EXRULE, and the new one. But how could you ever show it on the wire if only one instance had a new DTSTART, and the sequence number did not change? I really do not see how one could ever be describe it in iCalendar without the entire objects sequence number being changed. > I say the specification is correct. It is ambiguous about the other > instances, which means "implementation dependent". Perhaps when I see how it would look on the wire I could agree. From owner-ietf-calendar@imc.org Tue Feb 15 13:41:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17910 for ; Tue, 15 Feb 2000 13:40:59 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA28998 for ietf-calendar-bks; Tue, 15 Feb 2000 10:21:14 -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 KAA28994 for ; Tue, 15 Feb 2000 10:21: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 NAA01127 for ; Tue, 15 Feb 2000 13:39:55 -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 NAA01946 for ; Tue, 15 Feb 2000 13:24:06 -0500 (EST) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org Subject: Re: SEQUENCE number on recurrences X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Tue, 15 Feb 2000 13:25:24 -0500 X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2b |December 16, 1999) at 02/15/2000 01:25:27 PM, Serialize complete at 02/15/2000 01:25:28 PM, Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2b |December 16, 1999) at 02/15/2000 01:25:28 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00654C6785256886_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00654C6785256886_= Content-Type: text/plain; charset="us-ascii" Doug: Why do you say there is only one component? How do you know that the recurrence isn't composed of an initial REQUEST and a subsequent ADD to add in the recurrence? Plus, why do you make the assumption that recurring events aren't stored as separate components? Certainly, neither iCalendar nor iTIP presume this. CAP drafts don't presume this, do they. So where do we have the dogma that recurring calendar components MUST BE defined by a single calendar component? -- Frank --=_alternative 00654C6785256886_= Content-Type: text/html; charset="us-ascii"
Doug:

Why do you say there is only one component?

How do you know that the recurrence isn't composed of an initial REQUEST and a subsequent ADD to add in the recurrence?

Plus, why do you make the assumption that recurring events aren't stored as separate components?

Certainly, neither iCalendar nor iTIP presume this. CAP drafts don't presume this, do they. So where do we have the dogma that recurring calendar components MUST BE defined by a single calendar component?

-- Frank

--=_alternative 00654C6785256886_=-- From owner-ietf-calendar@imc.org Tue Feb 15 13:55:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18403 for ; Tue, 15 Feb 2000 13:55:17 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA29167 for ietf-calendar-bks; Tue, 15 Feb 2000 10:31:44 -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 KAA29163 for ; Tue, 15 Feb 2000 10:31:43 -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 NAA02072 for ; Tue, 15 Feb 2000 13:50:27 -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 NAA03091 for ; Tue, 15 Feb 2000 13:34:38 -0500 (EST) To: ietf-calendar@imc.org Cc: ietf-calendar@imc.org Subject: Re: SEQUENCE number on recurrences X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Tue, 15 Feb 2000 13:35:56 -0500 X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2b |December 16, 1999) at 02/15/2000 01:35:59 PM, Serialize complete at 02/15/2000 01:35:59 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0066433D85256886_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066433D85256886_= Content-Type: text/plain; charset="us-ascii" First component to set a Thursday PR telecon: BEGIN:VCALENDAR ... METHOD:REQUEST BEGIN:VEVENT DTSTART:20000217T160000Z DTEND:20000217T170000Z SUMMARY:Press Conference UID:123 ORGANIZER:foo@host1.com ATTENDEE;RSVP=FALSE:prcorp@host2.com END:VEVENT END:VCALENDAR Second component to add a Friday follow-on: BEGIN:VCALENDAR ... METHOD:ADD BEGIN:VEVENT DTSTART:20000218T160000Z DTEND:20000218T170000Z SUMMARY:Press Conference UID:123 SEQUENCE:1 ORGANIZER:foo@host1.com ATTENDEE;RSVP=FALSE:prcorp@host2.com END:VEVENT END:VCALENDAR Third component to change the time of Friday's follow-on: BEGIN:VCALENDAR ... METHOD:REQUEST BEGIN:VEVENT DTSTART:20000217T170000Z DTEND:20000217T173000Z SUMMARY:Press Conference UID:123 RECURRENCE-ID:20000217T170000Z SEQUENCE:2 ORGANIZER:foo@host1.com ATTENDEE;RSVP=FALSE:prcorp@host2.com END:VEVENT END:VCALENDAR At this point (read Frank with green face, I now agree!) all of the recurrence instances for VEVENT, UID:123, RECURRENCE-ID:whatever have SEQUENCE:2. Any iTIP for this VEVENT with a SEQUENCE < 2 will be stale and can be ignored. We had discussed this precise case when progressing iTIP. Thanks for the patience, Doug! -- Frank --=_alternative 0066433D85256886_= Content-Type: text/html; charset="us-ascii"
First component to set a Thursday PR telecon:

BEGIN:VCALENDAR
...
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20000217T160000Z
DTEND:20000217T170000Z
SUMMARY:Press Conference
UID:123
ORGANIZER:foo@host1.com
ATTENDEE;RSVP=FALSE:prcorp@host2.com
END:VEVENT
END:VCALENDAR

Second component to add a Friday follow-on:

BEGIN:VCALENDAR
...
METHOD:ADD
BEGIN:VEVENT
DTSTART:20000218T160000Z
DTEND:20000218T170000Z
SUMMARY:Press Conference
UID:123
SEQUENCE:1
ORGANIZER:foo@host1.com
ATTENDEE;RSVP=FALSE:prcorp@host2.com
END:VEVENT
END:VCALENDAR

Third component to change the time of Friday's follow-on:

BEGIN:VCALENDAR
...
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20000217T170000Z
DTEND:20000217T173000Z
SUMMARY:Press Conference
UID:123
RECURRENCE-ID:20000217T170000Z
SEQUENCE:2
ORGANIZER:foo@host1.com
ATTENDEE;RSVP=FALSE:prcorp@host2.com
END:VEVENT
END:VCALENDAR

At this point (read Frank with green face, I now agree!) all of the recurrence instances for VEVENT, UID:123, RECURRENCE-ID:whatever have SEQUENCE:2. Any iTIP for this VEVENT with a SEQUENCE < 2 will be stale and can be ignored.

We had discussed this precise case when progressing iTIP. Thanks for the patience, Doug!

-- Frank

--=_alternative 0066433D85256886_=-- From owner-ietf-calendar@imc.org Tue Feb 15 14:49:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20235 for ; Tue, 15 Feb 2000 14:49:05 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA00633 for ietf-calendar-bks; Tue, 15 Feb 2000 11:20:51 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00629 for ; Tue, 15 Feb 2000 11:20:50 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA10926 for ; Tue, 15 Feb 2000 11:21:54 -0800 (PST) Received: from netscape.com ([207.1.153.248]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FPZKJM00.1T7; Tue, 15 Feb 2000 11:23:46 -0800 Message-ID: <38A9A789.DBCA1B10@netscape.com> Date: Tue, 15 Feb 2000 11:22:49 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Doug Royer CC: CalSched IETF Subject: Re: SEQUENCE number on recurrences References: <38A8A015.BE9B0A99@netscape.com> <38A982F5.64B48B44@home.royer.com> Content-Type: multipart/mixed; boundary="------------B1A1D005F4FCB8323903C6F7" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------B1A1D005F4FCB8323903C6F7 Content-Type: multipart/alternative; boundary="------------A2093269CA3B662C6EF6717D" --------------A2093269CA3B662C6EF6717D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Steve Mansour wrote: > > > > Folks, > > > > Say that you create a recurring event. Now let's say that you update the > > DTSTART value of a single instance of that recurring event. Do you need > > to bump the sequence number of just the single instance you changed or > > do you bump the sequence number for all instances? > > > > I wasn't clear on this after reading the Sequence Number text in RFC > > 2445. > > Ether way the component as a whole is not the same. It would need a new sequence > number. As I recall, you were going to expand the instances and then store them, > however that is not iCalendar, its just your storage method. Right. Some implementations will expand, some will not. The question is, what does it look like? It should look the same to a client regardless of the implementation. Let's say that the recurrence rule expanded to 3 instances to keep things simple. When we create the event initially, we have: Instance 1 Sequence 0 Instance 2 Sequence 0 Instance 3 Sequence 0 Now, I make a change to instance number 2, that would cause its sequence number to bump up to 1. If a client now asked for ALL instances of the event, what should it should it be? I see two possibilities: Instance 1 Sequence 0 Instance 2 Sequence 1 Instance 3 Sequence 0 or Instance 1 Sequence 1 Instance 2 Sequence 1 Instance 3 Sequence 1 Which one should it be? > The object instance changed, and via iTIP you would need to be able to tell > something important changed. yep. So, when I resend the updated event, which of the two options above is correct? -Steve --------------A2093269CA3B662C6EF6717D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote:

Steve Mansour wrote:
>
> Folks,
>
> Say that you create a recurring event. Now let's say that you update the
> DTSTART value of a single instance of that recurring event. Do you need
> to bump the sequence number of just the single instance you changed or
> do you bump the sequence number for all instances?
>
> I wasn't clear on this after reading the Sequence Number text in RFC
> 2445.

Ether way the component as a whole is not the same. It would need a new sequence number. As I recall, you were going to expand the instances and then store them, however that is not iCalendar, its just your storage method.

Right. Some implementations will expand, some will not. The question is, what does it look like? It should look the same to a client regardless of the implementation.

Let's say that the recurrence rule expanded to 3 instances to keep things simple. When we create the event initially, we have:

Instance 1  Sequence 0
Instance 2  Sequence 0
Instance 3  Sequence 0
Now, I make a change to instance number 2, that would cause its sequence number to bump up to 1.  If a client now asked for ALL instances of the event, what should it should it be?  I see two possibilities:
Instance 1  Sequence 0
Instance 2  Sequence 1
Instance 3  Sequence 0
or
Instance 1  Sequence 1
Instance 2  Sequence 1
Instance 3  Sequence 1
Which one should it be?
The object instance changed, and via iTIP you would need to be able to tell something important changed.
yep. So, when I resend the updated event, which of the two options above is correct?

-Steve --------------A2093269CA3B662C6EF6717D-- --------------B1A1D005F4FCB8323903C6F7 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------B1A1D005F4FCB8323903C6F7-- From owner-ietf-calendar@imc.org Tue Feb 15 14:58:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20516 for ; Tue, 15 Feb 2000 14:58:31 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA00777 for ietf-calendar-bks; Tue, 15 Feb 2000 11:27:40 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00773 for ; Tue, 15 Feb 2000 11:27:39 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA28229 for ; Tue, 15 Feb 2000 11:26:50 -0800 (PST) Received: from netscape.com ([207.1.153.248]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FPZKUC00.USR; Tue, 15 Feb 2000 11:30:12 -0800 Message-ID: <38A9A90A.1CB5BE8C@netscape.com> Date: Tue, 15 Feb 2000 11:29:14 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: ietf-calendar@imc.org, Ki Wong , John Sun Subject: Re: SEQUENCE number on recurrences References: Content-Type: multipart/mixed; boundary="------------582957A6AE2EFBD3E09FCA49" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------582957A6AE2EFBD3E09FCA49 Content-Type: multipart/alternative; boundary="------------B343227DBF4F46B4C808E835" --------------B343227DBF4F46B4C808E835 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit So, to summarize, the sequence number is always the same for all instances, and it must always be the highest sequence number. Right? -Steve Frank_Dawson@lotus.com wrote: > > First component to set a Thursday PR telecon: > > BEGIN:VCALENDAR > ... > METHOD:REQUEST > BEGIN:VEVENT > DTSTART:20000217T160000Z > DTEND:20000217T170000Z > SUMMARY:Press Conference > UID:123 > ORGANIZER:foo@host1.com > ATTENDEE;RSVP=FALSE:prcorp@host2.com > END:VEVENT > END:VCALENDAR > > Second component to add a Friday follow-on: > > BEGIN:VCALENDAR > ... > METHOD:ADD > BEGIN:VEVENT > DTSTART:20000218T160000Z > DTEND:20000218T170000Z > SUMMARY:Press Conference > UID:123 > SEQUENCE:1 > ORGANIZER:foo@host1.com > ATTENDEE;RSVP=FALSE:prcorp@host2.com > END:VEVENT > END:VCALENDAR > > Third component to change the time of Friday's follow-on: > > BEGIN:VCALENDAR > ... > METHOD:REQUEST > BEGIN:VEVENT > DTSTART:20000217T170000Z > DTEND:20000217T173000Z > SUMMARY:Press Conference > UID:123 > RECURRENCE-ID:20000217T170000Z > SEQUENCE:2 > ORGANIZER:foo@host1.com > ATTENDEE;RSVP=FALSE:prcorp@host2.com > END:VEVENT > END:VCALENDAR > > At this point (read Frank with green face, I now agree!) all of the > recurrence instances for VEVENT, UID:123, RECURRENCE-ID:whatever have > SEQUENCE:2. Any iTIP for this VEVENT with a SEQUENCE < 2 will be stale > and can be ignored. > > We had discussed this precise case when progressing iTIP. Thanks for > the patience, Doug! > > -- Frank > > --------------B343227DBF4F46B4C808E835 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit So, to summarize, the sequence number is always the same for all instances, and it must always be the highest sequence number. Right?

-Steve

Frank_Dawson@lotus.com wrote:

 
First component to set a Thursday PR telecon:

BEGIN:VCALENDAR
...
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20000217T160000Z
DTEND:20000217T170000Z
SUMMARY:Press Conference
UID:123
ORGANIZER:foo@host1.com
ATTENDEE;RSVP=FALSE:prcorp@host2.com
END:VEVENT
END:VCALENDAR

Second component to add a Friday follow-on:

BEGIN:VCALENDAR
...
METHOD:ADD
BEGIN:VEVENT
DTSTART:20000218T160000Z
DTEND:20000218T170000Z
SUMMARY:Press Conference
UID:123
SEQUENCE:1
ORGANIZER:foo@host1.com
ATTENDEE;RSVP=FALSE:prcorp@host2.com
END:VEVENT
END:VCALENDAR

Third component to change the time of Friday's follow-on:

BEGIN:VCALENDAR
...
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20000217T170000Z
DTEND:20000217T173000Z
SUMMARY:Press Conference
UID:123
RECURRENCE-ID:20000217T170000Z
SEQUENCE:2
ORGANIZER:foo@host1.com
ATTENDEE;RSVP=FALSE:prcorp@host2.com
END:VEVENT
END:VCALENDAR

At this point (read Frank with green face, I now agree!) all of the recurrence instances for VEVENT, UID:123, RECURRENCE-ID:whatever have SEQUENCE:2. Any iTIP for this VEVENT with a SEQUENCE < 2 will be stale and can be ignored.

We had discussed this precise case when progressing iTIP. Thanks for the patience, Doug!

-- Frank
 
 

--------------B343227DBF4F46B4C808E835-- --------------582957A6AE2EFBD3E09FCA49 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------582957A6AE2EFBD3E09FCA49-- From owner-ietf-calendar@imc.org Tue Feb 15 15:17:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21127 for ; Tue, 15 Feb 2000 15:17:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01557 for ietf-calendar-bks; Tue, 15 Feb 2000 11:54:30 -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 LAA01553 for ; Tue, 15 Feb 2000 11:54: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 PAA13284; Tue, 15 Feb 2000 15:13:10 -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 OAA15432; Tue, 15 Feb 2000 14:57:20 -0500 (EST) To: sman@netscape.com (Steve Mansour) Cc: ietf-calendar@imc.org, Ki Wong , John Sun Subject: Re: SEQUENCE number on recurrences X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Tue, 15 Feb 2000 14:58:38 -0500 X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2b |December 16, 1999) at 02/15/2000 02:58:42 PM, Serialize complete at 02/15/2000 02:58:42 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006DD59185256886_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006DD59185256886_= Content-Type: text/plain; charset="us-ascii" >So, to summarize, the sequence number is always the same for all >instances, and it must always be the highest sequence number. Right? Effectively, I think so. That is, you received an initial REQUEST (implicitly with SEQUENCE:0), a subsequent ADD (with SEQUENCE:1) and then a reschedule of an instance (with SEQUENCE:2). So, if an Attendee asked for a REFRESH, then the subsequent REQUEST would specify at least SEQUENCE:1. I say at least SEQUENCE:1 because we have allowed in iTIP that each message sent by the Organizer can involve an increment to the SEQUENCE property. I know of one implementation that seems to do this. -- Frank --=_alternative 006DD59185256886_= Content-Type: text/html; charset="us-ascii"
>So, to summarize, the sequence number is always the same for all
>instances, and it must always be the highest sequence number. Right?

Effectively, I think so. That is, you received an initial REQUEST (implicitly with SEQUENCE:0), a subsequent ADD (with SEQUENCE:1) and then a reschedule of an instance (with SEQUENCE:2).

So, if an Attendee asked for a REFRESH, then the subsequent REQUEST would specify at least SEQUENCE:1. I say at least SEQUENCE:1 because we have allowed in iTIP that each message sent by the Organizer can involve an increment to the SEQUENCE property. I know of one implementation that seems to do this.

-- Frank

--=_alternative 006DD59185256886_=-- From owner-ietf-calendar@imc.org Tue Feb 15 15:20:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21196 for ; Tue, 15 Feb 2000 15:20:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01666 for ietf-calendar-bks; Tue, 15 Feb 2000 11:58:18 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01662 for ; Tue, 15 Feb 2000 11:58:17 -0800 (PST) From: Frank_Dawson@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id PAA13788 for ; Tue, 15 Feb 2000 15:17: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 PAA15944 for ; Tue, 15 Feb 2000 15:01:12 -0500 (EST) Subject: RFC 2445 Typo in Section 4.8.1.7 To: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Tue, 15 Feb 2000 15:02:31 -0500 X-MIMETrack: Serialize by Router on Barium/CAM/M/Lotus(Release 5.0.2b |December 16, 1999) at 02/15/2000 03:02:34 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: The example in Section 4.8.1.7: LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": Conference Room - F123, Bldg. 002 Should read: LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": Conference Room - F123\, Bldg. 002 The COMMA character is in the property value text, not a list separator. -- Frank From owner-ietf-calendar@imc.org Tue Feb 15 16:49:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24535 for ; Tue, 15 Feb 2000 16:49:51 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA04408 for ietf-calendar-bks; Tue, 15 Feb 2000 13:23:27 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04404 for ; Tue, 15 Feb 2000 13:23:27 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA14634 for ; Tue, 15 Feb 2000 13:22:39 -0800 (PST) Received: from netscape.com ([207.1.153.248]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FPZQ7W00.C1U; Tue, 15 Feb 2000 13:26:20 -0800 Message-ID: <38A9C428.893CD880@netscape.com> Date: Tue, 15 Feb 2000 13:24:56 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Frank_Dawson@lotus.com CC: ietf-calendar@imc.org, Ki Wong , John Sun Subject: Re: SEQUENCE number on recurrences References: Content-Type: multipart/mixed; boundary="------------0E1617A43AFAEBCFC782F7BD" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0E1617A43AFAEBCFC782F7BD Content-Type: multipart/alternative; boundary="------------093E5CBF1A0AA64004FE9E79" --------------093E5CBF1A0AA64004FE9E79 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree. This seems correct. -Steve Frank_Dawson@lotus.com wrote: > > >So, to summarize, the sequence number is always the same for all > >instances, and it must always be the highest sequence number. Right? > > Effectively, I think so. That is, you received an initial REQUEST > (implicitly with SEQUENCE:0), a subsequent ADD (with SEQUENCE:1) and > then a reschedule of an instance (with SEQUENCE:2). > > So, if an Attendee asked for a REFRESH, then the subsequent REQUEST > would specify at least SEQUENCE:1. I say at least SEQUENCE:1 because > we have allowed in iTIP that each message sent by the Organizer can > involve an increment to the SEQUENCE property. I know of one > implementation that seems to do this. > > -- Frank > > --------------093E5CBF1A0AA64004FE9E79 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree. This seems correct.
-Steve

Frank_Dawson@lotus.com wrote:

 
>So, to summarize, the sequence number is always the same for all
>instances, and it must always be the highest sequence number. Right?

Effectively, I think so. That is, you received an initial REQUEST (implicitly with SEQUENCE:0), a subsequent ADD (with SEQUENCE:1) and then a reschedule of an instance (with SEQUENCE:2).

So, if an Attendee asked for a REFRESH, then the subsequent REQUEST would specify at least SEQUENCE:1. I say at least SEQUENCE:1 because we have allowed in iTIP that each message sent by the Organizer can involve an increment to the SEQUENCE property. I know of one implementation that seems to do this.

-- Frank
 
 

--------------093E5CBF1A0AA64004FE9E79-- --------------0E1617A43AFAEBCFC782F7BD Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------0E1617A43AFAEBCFC782F7BD-- From owner-ietf-calendar@imc.org Wed Feb 16 06:12:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22128 for ; Wed, 16 Feb 2000 06:12:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA28065 for ietf-calendar-bks; Wed, 16 Feb 2000 02:45:04 -0800 (PST) Received: from mumrik.nada.kth.se (mumrik.nada.kth.se [130.237.226.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28061 for ; Wed, 16 Feb 2000 02:45:03 -0800 (PST) Received: from localhost (d92-pla@localhost) by mumrik.nada.kth.se (8.8.7/8.8.7) with ESMTP id LAA12785 for ; Wed, 16 Feb 2000 11:48:27 +0100 (MET) Date: Wed, 16 Feb 2000 11:48:27 +0100 (MET) From: =?ISO-8859-1?Q?P=E4r_Lanner=F6?= To: ietf-calendar@imc.org Subject: GEO question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8BIT Hello! We would like to get some more information concerning the GEO property. In order for us to be able to use the GEO coordinates in a GIS application we need to know what coordinate system to use. Ie. what geographic datum, hemisphere, offset etc. The information seems to be missing in RFC2445 (perhaps it's in the "Federal Information Processing Standard 70-1, but where do I get _that_?). Thanks! /Par (SKiCal project) -Pär-Lannerö---------------------------------------------------------- mailto:par.lannero@metamatrix.se jobb:+46(0)8337785 http://www.d.kth.se/~d92-pla/ hem:+46(0)853039951 icq:306436 gsm:+46(0)708/826888 ---------------------------------------------------------------------- - anpassar databaser till Internetåldern From owner-ietf-calendar@imc.org Wed Feb 16 14:26:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10853 for ; Wed, 16 Feb 2000 14:26:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09770 for ietf-calendar-bks; Wed, 16 Feb 2000 10:58:20 -0800 (PST) Received: from localhost.localdomain (3.144.8.207.in-addr.arpa [207.8.144.3] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09766 for ; Wed, 16 Feb 2000 10:58:19 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id OAA19959 for ; Wed, 16 Feb 2000 14:01:29 -0500 Message-ID: <38AAF408.58DFDF29@ecal.com> Date: Wed, 16 Feb 2000 14:01:29 -0500 From: John Stracke X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: GEO question References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit "Pär Lannerö" wrote: > In order for us to be able to use the GEO coordinates in a > GIS application we need to know what coordinate system to use. Ie. > what geographic datum, hemisphere, offset etc. The information seems > to be missing in RFC2445 ? It looks to me like it's there: The longitude represents the location east or west of the prime meridian as a positive or negative real number, respectively. [...] Latitudes north of the equator shall be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the digits designating degrees. Latitudes south of the Equator shall be designated by a minus sign (-) preceding the digits designating degrees. A point on the Equator shall be assigned to the Northern Hemisphere. Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the digits designating degrees. Longitudes west of the meridian shall be designated by minus sign (-) preceding the digits designating degrees. A point on the prime meridian shall be assigned to the Eastern Hemisphere. A point on the 180th meridian shall be assigned to the Western Hemisphere. [...] Do you need something more than this? It looks to me as if the mention of FIPS 70-1 is not normative (it's not even in the References); the text just mentions it to make it clear that the spec was copied from there. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I'm not imaginary. I'm ontologically challenged.| |francis@ecal.com| | \=================================================================/ From owner-ietf-calendar@imc.org Wed Feb 16 14:53:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11538 for ; Wed, 16 Feb 2000 14:53:20 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA10302 for ietf-calendar-bks; Wed, 16 Feb 2000 11:26:55 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10298 for ; Wed, 16 Feb 2000 11:26:54 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA21204 for ; Wed, 16 Feb 2000 11:26:13 -0800 (PST) Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FQ1FHS00.8BZ; Wed, 16 Feb 2000 11:29:52 -0800 Message-ID: <38AAFA6B.4591AD7D@netscape.com> Date: Wed, 16 Feb 2000 11:28:43 -0800 From: rans@netscape.com (Richard Shusterman) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org Subject: Re: Groups revisited References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@iris.com wrote: > When a CU authenticates to the CS the credentialling system will output a > series of UPNs for that mechanism and set of credentials. So what is to > prevent that authentication mechanism from including a UPN that both > Frank, Steve, Doug, Pat and Alex have that is, say, > "CAPEditors@calsched.apps.ietf.org". This is in effect a group UPN since > all 5 of them share it. I don't think I understand. Are you saying that the CS would have to search thru it's directory and find all the groups that reference the UPN that your CU is presenting for you? I guess it would then keep these group references for VCAR evaluation and if asked, return these group references to the CU so that it could use them for VAR create/edit? Since group names are not usually that descriptive, the CU should also be able to show the user the list of UPNs in a group. And, what if the CU wanted to use one of these groups for populating it's attendee list? > The UPN can then be used as part of a VCAR to give them write access to a > particular calendar or entry. When any of them try to modify the > particular calendar or entry the CS can check their list of UPNs to see if > they have the proper rights. This assumes that your set of group's matches the set of group's for another user. This may not be the case for personal address book groups. As I see it, the CS must evaluate all VCARs associated with a particular calendar, expanding groups down to their individual UPN's. While it's doing this evaluation/expansion, it will try to match your UPN with a VCAR until you are allowed access or it runs out of VCARs to evaluate/expand. This needs to be done dynamically to ensure that the CS picks up any new UPNs that are added to a group. > The real work now shifts from doing some evaluation for every access > (where some previous ideas were seemingly heading) to being handled once > at AUTHENTICATE time. This shift means that we need to be very precise in > how we spec out our authentication mechanisms so that every vendor who > implements it will generate the correct set of UPNs. This task may be > non-trivial but it simplifies MUCH of the later work. I'm not sure I like this approach. This forces CS vendors to support groups. The approach presented by the Boston draft additions makes group support optional, i.e., the CS must still respond to EXPAND/LOOKUP but if it doesn't support groups, it would always return the passed-in CSID or UPN. > Ive tried to be as clear as I can describing my train of thought w/o being > too rambling or circumspect. After a second pass at it I do not see any > glaring logic flaws so I thought Id propose this to the group to see if > its off in left field or if we just overlooked something so simple by > jumping to more complex solutions... On first thought, this approach seems more complex, especially for the CS. But maybe, I just need to hear more... From owner-ietf-calendar@imc.org Wed Feb 16 15:35:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12841 for ; Wed, 16 Feb 2000 15:34:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11275 for ietf-calendar-bks; Wed, 16 Feb 2000 12:11:45 -0800 (PST) Received: from pop02.iname.net (pop02.iname.net [165.251.20.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11268 for ; Wed, 16 Feb 2000 12:11:40 -0800 (PST) Received: from JrMedley ([209.220.160.113]) by pop02.iname.net (8.9.3/8.9.3) with SMTP id PAA08360; Wed, 16 Feb 2000 15:15:11 -0500 (EST) Message-ID: <002c01bf78ba$780050c0$71a0dcd1@arasys.com> Reply-To: "John Rose" From: "John Rose" To: Cc: Subject: Re: GEO question Date: Wed, 16 Feb 2000 12:14:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit As I understand your question, you want to know the details of the map projection (which uses datum, hemisphere, offset, etc.) to be used for the GEO property. However, the GEO property is defined as being expressed in latitude/longitude, which is a spherical coordinate system and NOT a map projection. If you have a location coordinate that's currently expressed in some map projection (e.g. Albers, Robinson, etc.), you must convert that projection to the standard non-projected lat/lon coordinate space in order to assign it to the GEO property. Conversely, to use a GEO property that you've received, you MAY need to convert it to whatever projection is being used by your GIS application/data. Note also that the lat/lon coordinates for the GEO property are in "decimal degrees", rather than in a degrees-minutes-seconds format. RFC2445 provides the exact formula for generating the decimal degrees value used by the GEO property. The Federal Information Processing Standard was mentioned for completeness, but my recollection is that it's long, boring and very confusing, and not typically useful unless there's some very exact detail which almost nobody should every need for the general purpose of the GEO property (which is to provide the approximate location of a given meeting). I hope this answers your question. If not, please email me directly with any further questions. - JR - - John Rose Altawave, Inc. jrsubs@iname.com jrose@altawave.com --------------- Pär-Lannerö wrote (on Wed, 16 Feb 2000 11:48:27 +0100 (MET)): > > Hello! > > We would like to get some more information concerning the GEO > property. In order for us to be able to use the GEO coordinates in a > GIS application we need to know what coordinate system to use. Ie. > what geographic datum, hemisphere, offset etc. The information seems > to be missing in RFC2445 (perhaps it's in the "Federal Information > Processing Standard 70-1, but where do I get _that_?). > > Thanks! > /Par (SKiCal project) > > > -Pär-Lannerö---------------------------------------------------------- > mailto:par.lannero@metamatrix.se jobb:+46(0)8337785 > http://www.d.kth.se/~d92-pla/ hem:+46(0)853039951 > icq:306436 gsm:+46(0)708/826888 > ---------------------------------------------------------------------- > - anpassar databaser till Internetåldern From owner-ietf-calendar@imc.org Wed Feb 16 16:34:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14613 for ; Wed, 16 Feb 2000 16:34:41 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA12763 for ietf-calendar-bks; Wed, 16 Feb 2000 13:11:37 -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 NAA12753 for ; Wed, 16 Feb 2000 13:11:31 -0800 (PST) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: rans@netscape.com (Richard Shusterman) Cc: ietf-calendar@imc.org Subject: Re: Groups revisited X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Wed, 16 Feb 2000 16:14:31 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 02/16/2000 04:15:56 PM, Serialize complete at 02/16/2000 04:15:56 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: Richard wrote: >> When a CU authenticates to the CS the credentialling system will output a >> series of UPNs for that mechanism and set of credentials. So what is to >> prevent that authentication mechanism from including a UPN that both >> Frank, Steve, Doug, Pat and Alex have that is, say, >> "CAPEditors@calsched.apps.ietf.org". This is in effect a group UPN since >> all 5 of them share it. > >I don't think I understand. Are you saying that the CS would have to search >thru it's directory and find all the groups that reference the UPN that your CU >is presenting for you? When I AUTHENTICATE with my CS, the credentialling process will result in 1 or more UPNs being 'spat out' if the process works. Lets say that when Frank AUTHENTICATEs with his CS, it (his CS thanks to the authentication mechanism) says that the pair of UPNs Frank_Dawson@lotus.com and CAPEditors@calsched.apps.ietf.org are 'valid' identities for Frank. He can use them as part of VCARs or wherever else we allow UPNs. >I guess it would then keep these group references for >VCAR evaluation and if asked, return these group references to the CU so that >it could use them for VAR create/edit? The CS _really_ should keep all the UPNs that are spat out for VCAR comparison, etc. That way, if there is a VCAR on a paricular event in the calendar that has a VCAR that only allows CAPEditors@calsched.apps.ietf.org to read or edit it then Frank should be able to access that entry. Just because Franks "primary" (ugh, for lack of a better description so do not take literally) UPN is Frank_Dawson@lotus.com does not mean that he has to do nasty things like switching identities to be able to access an entry that does have CAPEditors@calsched.apps.ietf.org on the VCAR. The CS should do this equivalence for him! >Since group names are not usually that >descriptive, the CU should also be able to show the user the list of UPNs in a >group. Smack the group UPN creator up side the head. Groups are much more useful if their are descriptive than if they are just mangled sequences of seemingly random junk. Sometimes they are not easily distinguished from that of a single CU (ie: postmaster@lotus.com is probably shared among a couple folks even though it could be just 1 person). Im still a big KISS advocate and Im not sure we need/want to have the CS do group expansion by request. That sounds like a directory issue really rather than a C&S one. Just as a CUA would probably do some kind of lookup (ie: LDAP, etc) on Frank_Dawson@lotus.com to get some info Frank, the same can and probably should be done by the CUA for the other UPN. In addition, I think the CS should fully unwind nested groups for the fairly obvious reason that ANY nested group could be on a VCAR. As such as long as Frank is a member of a nested group he should be granted/denied access accordingly. >> The UPN can then be used as part of a VCAR to give them write access to a >> particular calendar or entry. When any of them try to modify the >> particular calendar or entry the CS can check their list of UPNs to see if >> they have the proper rights. > >This assumes that your set of group's matches the set of group's for another >user. This may not be the case for personal address book groups. Personal address books cannot be used by the CS to enforce or expand group UPNs during AUTHENTICATion. Besides being a BIG security hole, its not feasible to even consider HOW the CS could safely get the info from the CUA and really trust it.. I dont want to murky the waters by talking about local replicas of the CSs address book (or partial replicas, etc). Thats OOB for CAP I think. For the CU to create their own group UPNs that the CS can use, it would have to be done in such a way that the CS can trust the data (ie: via read/write control to a shared LDAP server, etc). We can dive on some of the nitty gritty issues later but Im trying to see if the higher level view/logic I posted originally is accurate... >As I see it, the CS must evaluate all VCARs associated with a particular >calendar, expanding groups down to their individual UPN's. While it's doing >this evaluation/expansion, it will try to match your UPN with a VCAR until you >are allowed access or it runs out of VCARs to evaluate/expand. We are of similar thought I think but you are doing the expansion in a different way then I proposed. If the CS determines ALL the UPNs I am synonymous with when I AUTHENTICATE then it does not have to expaned EVERY VCAR on every ACCESS to try and find a match for my 'primary' (sic.) UPN. Its much much cheaper to take the hit up front than for every request/response that needs to be done. As long as ANY UPN in my list of identities matches the VCARs then that VCAR is applied to me. That only drawback is that a change to a group UPN wont take effect until I reAUTHENTICATE. Typically though this is not such a big deal and can be handled by some good upfront CS architecture for handling change notifications. >I'm not sure I like this approach. This forces CS vendors to support groups. >The approach presented by the Boston draft additions makes group support >optional, i.e., the CS must still respond to EXPAND/LOOKUP but if it doesn't >support groups, it would always return the passed-in CSID or UPN. Argh, a step backwards in agreement. WAAY back in Montreal we agreed that the authentication process could generate > 1 UPN for a set of credentials. We never precluded that all of those UPNs must be unique for a CU. If its not unique per CU then it in effect is a group UPN. Im claiming that groups can be easily handled by this ability to have > 1 UPN generated when I AUTHENTICATE with the CS and that is something that all CS vendors will have to deal with. Im NOT a big fan of bloating CAP even more by having the CS act as a UPN directory server of sorts as it just deters vendors from making CS implementations. Just how do were you (collectively now) envissioning that the CS would use the other UPNs that are generated as part of the certification process?? Are they to be ignored? If all CSs must generate the same list of UPNs for a given set of credentials then what is the big deal in the CS using them to evaluate VCARs, etc later one? I think that in an effort to 'add groups' into CAP we are making this issue overly complex. It is not that difficult for a CS to compare a list of UPNs (for an authenticated CU) against those on VCARs instead of simply comparing 1 UPN. Or am I missing some argument somewhere that says groups have to be a complex beast?? >On first thought, this approach seems more complex, especially for the CS. But >maybe, I just need to hear more... Ok this may be bass ackwards but Ill try to rephrase my idea in as simple terms as Im able at this time of day: Given: 1: The AUTHENTICATion process may result in > 1 UPN being generated for a given set of credentials and 2: Not all UPNs are 100% unique per CU That: 1: It is possible to have a 'group' UPN generated as one of a CUs UPNs when they AUTHENTICATE and 2: A CS should be able to match ANY of the UPNs generated during authentication in a normal UPN check (ie: in VCAR evaluation) Therefore: 1: This 'group' UPN can be used anywhere a UPN is normally used (ie: VCAR) and 2: No extra or overly complex extra mechanisms are needed in CAP to distinguish a 'group' UPN from an 'non-group' UPN and 3: We do not need to distingush beteen 'group' and 'non-group' UPN flavors anymore. Does this help clarify my original posting?? 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... From owner-ietf-calendar@imc.org Wed Feb 16 19:13:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18846 for ; Wed, 16 Feb 2000 19:13:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16213 for ietf-calendar-bks; Wed, 16 Feb 2000 15:51:37 -0800 (PST) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA16209 for ; Wed, 16 Feb 2000 15:51:36 -0800 (PST) Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP id AA21147; Wed, 16 Feb 00 18:56:26 EST Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45]) by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id SAA06870 for ; Wed, 16 Feb 2000 18:47:54 -0500 (EST) Received: from [18.177.0.98] (WINGNUT.MIT.EDU [18.177.0.98]) by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id SAA06589 for ; Wed, 16 Feb 2000 18:47:54 -0500 (EST) Mime-Version: 1.0 X-Sender: bobmah@po12.mit.edu Message-Id: Date: Wed, 16 Feb 2000 18:47:12 -0500 To: ietf-calendar@imc.org From: Bob Mahoney Subject: With apologies- delayed Interim meeting minutes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Essentially everything that was discussed went immediately to the list. Some amount of time was also spent working on the list with feedback to our suggested text. We were hampered somewhat by travel problems, and a few planned attendees were unable to arrive in time. (Another reason that our work went immediately to the list) For completeness sake, here is the list of attendees, and the rough sequence of events: -------------- Calsch Interim Meeting 1/25-26, 2000 Present: Paul B. Hill, Bob Mahoney, Richard Shusterman, Michael Ciavari, Dave Madeo ----------- Tuesday We started in on some security-related portions of the draft, borrowing some text from section 6 of: http://search.ietf.org/internet-drafts/draft-ietf-ldapext-authmeth-04.txt which states some of the problems very nicely. Paul worked on some security text, which was reviewed Wednesday, while the rest of us concentrated on Groups. The resulting suggested text went to the list. We brought Jeff Schiller in towards the end of the day, to answer some security questions. ------------ Wednesday Some further work on the security text was done before breaking to reorganize the CAP table of contents a bit for clarity. (For example, we consolidated the security-related text in one place.) This work also went to the list. -Bob Mahoney From owner-ietf-calendar@imc.org Wed Feb 16 21:20:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19989 for ; Wed, 16 Feb 2000 21:20:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA18232 for ietf-calendar-bks; Wed, 16 Feb 2000 17:53:59 -0800 (PST) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18228 for ; Wed, 16 Feb 2000 17:53:57 -0800 (PST) From: pregen@egenconsulting.com To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, rans@netscape.com (Richard Shusterman) Subject: Re: Groups revisited X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Wed, 16 Feb 2000 20:57:20 -0500 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at 02/16/2000 08:57:24 PM, Serialize complete at 02/16/2000 08:57:24 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000A9EFF85256888_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 000A9EFF85256888_= Content-Type: text/plain; charset="us-ascii" Bruce/Richard: Regarding the long note on Groups (which I don't want to reprint because it's now too long) - basically, I think you both are saying the same thing. Bruce, I think you may have hit upon something. Everyone is really getting down into the nitty gritty on groups and worried that there is a problem. But, to summarize what you are saying (or what I think you are saying) is that a group is really just a list of UPN's. All the calendar product has to do is read the list and validate the members as if they were each an independent UPN. Correct? If so, that seems like a "well, duh..." Am I missing something, or does this really sound like it's a non issue and simplier than everyone has been assuming. If it is true, than implementing groups should not be as hard as we envisioned?? Also, I agree with Bruce's comment about not using the Personal NAB to authenticate UPN's. --=_alternative 000A9EFF85256888_= Content-Type: text/html; charset="us-ascii"
Bruce/Richard:

Regarding the long note on Groups (which I don't want to reprint because it's now too long) -  basically, I think you both are saying the same thing.  Bruce, I think you may have hit upon something.  Everyone is really getting down into the nitty gritty on groups and worried that there is a problem.  But, to summarize what you are saying (or what I think you are saying) is that a group is really just a list of UPN's.  All the calendar product has to do is read the list and validate the members as if they were each an independent UPN.  Correct? If so, that seems like a "well, duh..."  Am I missing something, or does this really sound like it's a non issue and simplier than everyone has been assuming.   If it is true, than implementing groups should not be as hard as we envisioned??

Also, I agree with Bruce's comment about not using the Personal NAB to authenticate UPN's.  
--=_alternative 000A9EFF85256888_=-- From owner-ietf-calendar@imc.org Fri Feb 18 17:50:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03479 for ; Fri, 18 Feb 2000 17:50:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04968 for ietf-calendar-bks; Fri, 18 Feb 2000 14:22:54 -0800 (PST) Received: from mail.rdc1.il.home.com (imail@ha1.rdc1.il.home.com [24.2.1.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04964 for ; Fri, 18 Feb 2000 14:22:53 -0800 (PST) Received: from cy27465a ([24.12.140.214]) by mail.rdc1.il.home.com (InterMail v4.01.01.00 201-229-111) with SMTP id <20000218222635.NSVE482.mail.rdc1.il.home.com@cy27465a> for ; Fri, 18 Feb 2000 14:26:35 -0800 Message-ID: <009a01bf7a5e$d7ef6c50$0400a8c0@muncie1.in.home.com> From: "Dannie M Stanley" To: Subject: What/Where is ICAP Date: Fri, 18 Feb 2000 17:23:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I realize ICAP is a protocol, but I want to start using it in combination with mcal and I cannot for the life of me figure out where to start. If someone could answer the following to help me get started I would be greatly appreciative: Where can I find an ICAP compliant server? Thanks, DS -- Dannie M Stanley Webmaster/Developer SpinWeb Net Designs, Inc - http://www.spinweb.net From owner-ietf-calendar@imc.org Sun Feb 20 03:21:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01753 for ; Sun, 20 Feb 2000 03:21:16 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA09371 for ietf-calendar-bks; Sat, 19 Feb 2000 23:56:33 -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 XAA09367 for ; Sat, 19 Feb 2000 23:56:31 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA03635 for ietf-calendar@imc.org; Sun, 20 Feb 2000 00:00:06 -0800 (PST) Date: Sun, 20 Feb 2000 00:00:06 -0800 (PST) From: Doug Royer Message-Id: <200002200800.AAA03635@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 (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. U [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema U W-14 CAP VEVENT Schema U W-15 CAP VTODO Schema U W-16 CAP VJOURNAL Schema U W-17 CAP VCAR Schema U W-18 CAP UPN definition, including anonymous U user and how UPN's are used in LDAP and certificates. W-19 CAP Group definitions, dynamic and U static and how groups are used in VCARs. Policy definitions, in a VCAR format. W-20 Associating UPN values with CREATED U and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA U W-23 CAP Calendar property to allow/disallow U overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues U W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH U (CAP-00 - 12.2) Will there need to be one? U Optional? U W-29 Import/Export U W-30 Transport protocol name (transport vs U application layer) W-31 NOOP command? U W-32 NOOP advisory only? U W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are U they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? U ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@imc.org Sun Feb 20 14:10:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12254 for ; Sun, 20 Feb 2000 14:10:10 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA21513 for ietf-calendar-bks; Sun, 20 Feb 2000 10:45:56 -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 KAA21509 for ; Sun, 20 Feb 2000 10:45:54 -0800 (PST) Received: from home.royer.com (home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id KAA12658 for ; Sun, 20 Feb 2000 10:49:44 -0800 (PST) Message-ID: <38B0373F.8AF52BCC@home.royer.com> Date: Sun, 20 Feb 2000 10:49:35 -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: CALSCH Action Items References: <200002200800.AAA03635@royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms49C58204A4F860F7BE2A4776" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms49C58204A4F860F7BE2A4776 Content-Type: multipart/mixed; boundary="------------41E8DB5F9062619C5DDC19C5" This is a multi-part message in MIME format. --------------41E8DB5F9062619C5DDC19C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > W-2 CAP If all booked and scheduled U > appointments are in same table The current CAP draft says 'YES', unless there are objections. I'll change this to a 'Y' next week. > W-9 CAP MOVE method. Issues with VCARs. U > [see note in CAP 7.2.1.5] Section 7.2.1.5 of CAP-01, has issues with MOVE. I'll add a statement like: All VCARs must be updated to reflect the MOVE. The the CU does not have VCAR access to MODIFY VCARs or any other necessary VCAR access, then the MOVE will not be allowed. > W-20 Associating UPN values with CREATED U > and LAST-MODIFIED properties. LAST-MODIFIED is a audit function. I say we drop LAST-MODIFIED and change CAP and this to a NO. > W-23 CAP Calendar property to allow/disallow U > overlapped booking OPAQUE entries? We have a ALLOW-CONFLICTS - I'll change this to a N unless someone objects. > W-24 CAP Calendar CHARSET property issues U Solved. We added CHARSET. I'll change this to a N unless someone objects. > W-28 Cal-Props - PATH U > (CAP-00 - 12.2) > Will there need to be one? U > Optional? U I'll change CAP to N, N, and N of no one objects. There is nothing that uses this. > W-29 Import/Export U I'll change this to a 'Y' BUT only to support synchronization. > W-30 Transport protocol name (transport vs U > application layer) Done -'Y' > W-31 NOOP command? U I think the group says 'Y'. I'll change this unless there are objections. > W-32 NOOP advisory only? U I want Y - and I have not heard any objections, I'll change this unless there are objections. With IMAP, you want to stay connected to your own INBOX. With iCalendar, an administrator could browse >100 calendars in a day. Keeping them all open simply because they have bookings on all of them is why I say 'Y'. > W-33 Should DISCONNECT be called QUIT? U I have not heard any feedback on this. > W-34 Format following error codes. Are U > they well defined? If not they > need to be machine determinable. I say 'Y', however they are not yet defined. I seem to recall that in DC everyone assumed they were well formed. I'll change this to a Y. > W-35 Move DNS and SLP to seperate draft? U I heard no objections, I'll change this to a Y. --------------41E8DB5F9062619C5DDC19C5 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------41E8DB5F9062619C5DDC19C5-- --------------ms49C58204A4F860F7BE2A4776 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKpAYJKoZIhvcNAQcCoIIKlTCCCpECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDAwggT6MIIEY6ADAgECAhAV9nEqnM8b86AlSm7V1bgJMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MTAyMDAwMDAw MFoXDTAwMTAxOTIzNTk1OVowggEVMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0RvdWdsYXMgTSBSb3llcjEiMCAGCSqG SIb3DQEJARYTZG91Z0Bob21lLnJveWVyLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv2PIWJY1kuOozvEfoLqMAefggITPljietkurVEhTBQZU/c2q2c8qCQiIFZ2dP3H/MoEx bVVDmtXsyZrRINk1aWC4yo/dT/3tB3eD41F0KMIpBexD8zN9SfPxzkjaEl/7zD8F6ekERmCU 9irA0zAOF7msHNnxa/InBnZ5f95Y75kCAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1Ud IASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1W ZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZl cmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNm MjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdk YTVkM2YyMTQxYmVhZGIyYmQyZTg5MjFmYTk2YmY1ZDcxMTQ5OWNhM2JlNDdmNWYzZWE0NTBj MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAWuXwK5FbAAU1urGBob5PPRQiCOUeWNQIkDr2F0WECiYnJfeG iawEVMS1PxsIe6BJ9MDxOvz0XyQhNsAXbv/hf0vhy398cd5ICKTpMMeyEEVX6IEVgXcpcyJf N7HKbfQZgRngT3uh/IXSObtFt+cC03VTG12Dic6EfyWihGAmeb0wggMuMIICl6ADAgECAhEA 0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UE ChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV 2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/ Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZI AYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYf d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1Ud DwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ4 3BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1 pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4 AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAV 9nEqnM8b86AlSm7V1bgJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDAwMjIwMTg0OTM4WjAjBgkqhkiG9w0BCQQxFgQUQ/judA1Z qJUr8X5SVP9v5sH6Q0owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYA1gl8fBmNX6nL2gUPuisSErpRFYrfTmkJQqv9kqgERj6fYig+Oj37SIpj/hoQh Osruvwn93j2Szid7TDMV9zoZ892g2cyzdeMGYufbokPudox5xmZ0nQQdggg+KucYr5rNlOCi JJZYAusjM5rufLKgsb9fQshn1+5T3zBTQxbitA== --------------ms49C58204A4F860F7BE2A4776-- From owner-ietf-calendar@imc.org Sun Feb 20 14:35:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12424 for ; Sun, 20 Feb 2000 14:35:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21887 for ietf-calendar-bks; Sun, 20 Feb 2000 11:05:45 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21883 for ; Sun, 20 Feb 2000 11:05:43 -0800 (PST) Received: from home.royer.com (home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA12777 for ; Sun, 20 Feb 2000 11:09:34 -0800 (PST) Message-ID: <38B03BEE.73496282@home.royer.com> Date: Sun, 20 Feb 2000 11:09:34 -0800 From: Doug Royer Reply-To: IETF CALSCH WG X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: Latest in-process draft Content-Type: multipart/mixed; boundary="------------8E01BBFEDD355F620C002E9D" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8E01BBFEDD355F620C002E9D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have placed the latest CAP draf at: ftp://royer.com/pub/CALSCH Included is cap.txt, the source file cap.nr, and a Makefile using gnu tools. Steve Mansour and myself currently have access to modify the files @home.royer.com. And these will be pushed to ftp://royer.com/pub/CALSCH . Any modification suggestions (other than typo's and simple formatting errors) MUST be sent to the list before they will be included. Typos and formatting errors can be sent to the list or directly to the editors. I am setting up an automated process to notify this list whenever cap.txt is updated by any one of the editors. This script will run once per day and generate email only when cap.txt changes. -Doug --------------8E01BBFEDD355F620C002E9D Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------8E01BBFEDD355F620C002E9D-- From owner-ietf-calendar@imc.org Sun Feb 20 15:11:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12612 for ; Sun, 20 Feb 2000 15:11:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA22914 for ietf-calendar-bks; Sun, 20 Feb 2000 11:48:31 -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 LAA22910 for ; Sun, 20 Feb 2000 11:48:29 -0800 (PST) Received: (from sman@localhost) by home.royer.com (8.9.1/8.9.1) id LAA13556 for ietf-calendar@imc.org; Sun, 20 Feb 2000 11:52:21 -0800 (PST) Date: Sun, 20 Feb 2000 11:52:21 -0800 (PST) From: ietf-calendar@imc.org Message-Id: <200002201952.LAA13556@home.royer.com> To: ietf-calendar@imc.org Subject: CAP draft update Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The CAP draft files have been updated on: ftp://royer.com/pub/CALSCH From owner-ietf-calendar@imc.org Mon Feb 21 02:25:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00602 for ; Mon, 21 Feb 2000 02:25:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA08354 for ietf-calendar-bks; Sun, 20 Feb 2000 23:00:13 -0800 (PST) Received: from hqvsbh1.ms.com (hqvsbh1.ms.com [205.228.12.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08350 for ; Sun, 20 Feb 2000 23:00:08 -0800 (PST) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/fw v1.30) id CAA00034 for ; Mon, 21 Feb 2000 02:04:01 -0500 (EST) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9511166361.029996; Mon, 21 Feb 00 02:03:56 -0500 Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id CAA29989 for ; Mon, 21 Feb 2000 02:03:55 -0500 (EST) X-Authentication-Warning: hqvsbh1.ms.com: Processed from queue /var/spool/mqueue-vs X-Authentication-Warning: hqvsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf Received: from sasmh4.ms.com(144.14.193.5) by hqvsbh1 via smap (4.1) id sma.9511166211.029849; Mon, 21 Feb 00 02:03:41 -0500 Received: from msdw.com (hqdsl26.morgan.com [205.228.1.26]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id CAA04274 for ; Mon, 21 Feb 2000 02:03:40 -0500 (EST) Message-ID: <38B0E34E.89947AC5@msdw.com> Date: Mon, 21 Feb 2000 02:03:42 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: [Fwd: POSIX time_t study group created] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I suspect many here would be interested as well. Forwarding with permission. dmadeo -------- Original Message -------- Subject: POSIX time_t study group created Resent-Date: Sun, 20 Feb 2000 00:21:55 -0500 (EST) Resent-From: tz@elsie.nci.nih.gov Date: Sat, 19 Feb 2000 21:18:12 -0800 (PST) From: Paul Eggert Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) To: tz@elsie.nci.nih.gov The Open Group, which is drafting the next POSIX.1 standard, has formed a mailing list for issues relating to the standardization of new time_t primitives. The idea, I believe, is to invent a new time type, which would be an integer count of nanoseconds since an epoch (or something close to that). This would assume the availability of 64-bit integer types, as required by the 1999 C Standard and common in recent C implementations. It's not clear to me whether this new type would be in the next POSIX.1 standard, or the one after that. I'm forwarding the following announcement of this new mailing list with permission from Andrew Josey of the Open Group. ------- Start of forwarded message ------- Date: Fri, 18 Feb 2000 11:28:38 GMT From: Andrew Josey Message-Id: <1000218112838.ZM17952@skye.rdg.opengroup.org> Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) To: pasc-sec@opengroup.org Subject: (pasc-sec 675) Creation of the time_t study group Cc: austin-group@opengroup.org All I have created a mailing list for the time_t study group. This is pasc-time-study@opengroup.org If you'd like to be added as a subscriber please let me know. best regards Andrew - ----- Andrew Josey The Open Group Director, Server Platforms Apex Plaza,Forbury Road, Email: a.josey@opengroup.org Reading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 GSM: +44 7974207557 ------- End of forwarded message ------- From owner-ietf-calendar@imc.org Mon Feb 21 14:45:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15426 for ; Mon, 21 Feb 2000 14:45:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA25632 for ietf-calendar-bks; Mon, 21 Feb 2000 11:11:50 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25628 for ; Mon, 21 Feb 2000 11:11:49 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA14988 for ; Mon, 21 Feb 2000 11:11:21 -0800 (PST) Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FQAO5F00.N0D for ; Mon, 21 Feb 2000 11:15:15 -0800 Message-ID: <38B18E70.B4992814@netscape.com> Date: Mon, 21 Feb 2000 11:13:52 -0800 From: rans@netscape.com (Richard Shusterman) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: Re: Latest in-process draft References: <38B03BEE.73496282@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, I quickly scanned this draft and did not see any of the text that was generated at the Boston meeting and sent to this list included in this latest draft. Can you please update this draft with that text. I realize there are some discussions that still need to be made around some of this text but a number of us did spend 2 full days working on this text AND I didn't see any major objections to it's inclusion. If you need me to point you to emails with the relevant text, I can do that. Thanks, Richard Doug Royer wrote: > I have placed the latest CAP draf at: > > ftp://royer.com/pub/CALSCH > > Included is cap.txt, the source file cap.nr, and a Makefile using gnu tools. > > Steve Mansour and myself currently have access to modify the files > @home.royer.com. > And these will be pushed to ftp://royer.com/pub/CALSCH . > > Any modification suggestions (other than typo's and simple formatting errors) > MUST be sent to the list before they will be included. Typos and formatting > errors can be sent to the list or directly to the editors. > > I am setting up an automated process to notify this list whenever > cap.txt is updated by any one of the editors. This script will run > once per day and generate email only when cap.txt changes. > > -Doug From owner-ietf-calendar@imc.org Mon Feb 21 15:04:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15707 for ; Mon, 21 Feb 2000 15:04:55 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26448 for ietf-calendar-bks; Mon, 21 Feb 2000 11:35:29 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26444 for ; Mon, 21 Feb 2000 11:35:28 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA21926 for ; Mon, 21 Feb 2000 11:36:55 -0800 (PST) Received: from netscape.com ([207.1.153.248]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FQAP8V00.LXE; Mon, 21 Feb 2000 11:38:55 -0800 Message-ID: <38B193F7.B7F992CA@netscape.com> Date: Mon, 21 Feb 2000 11:37:27 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Richard Shusterman CC: IETF CALSCH WG Subject: Re: Latest in-process draft References: <38B03BEE.73496282@home.royer.com> <38B18E70.B4992814@netscape.com> Content-Type: multipart/mixed; boundary="------------A8AF9E9BAA7871F6E3E96AAE" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------A8AF9E9BAA7871F6E3E96AAE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I sent the .nr and .txt files to Paul who was going to insert the text and provide more explanation. If you point me to the exact text you want put in the spec I'll do that this afternoon. -Steve Richard Shusterman wrote: > Doug, > > I quickly scanned this draft and did not see any of the text that was generated > at the Boston meeting and sent to this list included in this latest draft. Can > you please update this draft with that text. I realize there are some discussions > that still need to be made around some of this text but a number of us did spend > 2 full days working on this text AND I didn't see any major objections to it's > inclusion. If you need me to point you to emails with the relevant text, I can do > that. > > Thanks, > Richard > > Doug Royer wrote: > > > I have placed the latest CAP draf at: > > > > ftp://royer.com/pub/CALSCH > > > > Included is cap.txt, the source file cap.nr, and a Makefile using gnu tools. > > > > Steve Mansour and myself currently have access to modify the files > > @home.royer.com. > > And these will be pushed to ftp://royer.com/pub/CALSCH . > > > > Any modification suggestions (other than typo's and simple formatting errors) > > MUST be sent to the list before they will be included. Typos and formatting > > errors can be sent to the list or directly to the editors. > > > > I am setting up an automated process to notify this list whenever > > cap.txt is updated by any one of the editors. This script will run > > once per day and generate email only when cap.txt changes. > > > > -Doug --------------A8AF9E9BAA7871F6E3E96AAE Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------A8AF9E9BAA7871F6E3E96AAE-- From owner-ietf-calendar@imc.org Mon Feb 21 15:13:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15807 for ; Mon, 21 Feb 2000 15:13:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA26926 for ietf-calendar-bks; Mon, 21 Feb 2000 11:48:53 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26922 for ; Mon, 21 Feb 2000 11:48:52 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA23100 for ; Mon, 21 Feb 2000 11:50:19 -0800 (PST) Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FQAPV700.DQI; Mon, 21 Feb 2000 11:52:19 -0800 Message-ID: <38B19720.89609E20@netscape.com> Date: Mon, 21 Feb 2000 11:50:56 -0800 From: rans@netscape.com (Richard Shusterman) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour CC: IETF CALSCH WG Subject: Re: Latest in-process draft References: <38B03BEE.73496282@home.royer.com> <38B18E70.B4992814@netscape.com> <38B193F7.B7F992CA@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Part I was contained in Bob Mahoney's email of 1/26/00 at 12:48PM PST entitled "W-19 CAP Group Definitions - corrections to yesterday's work". Part II was contained in Paul Hill's emails of 1/27/00 at 12:47PM PST entitled "revised UPN definition" and 1/27/00 at 7:59AM PST entitled "revised security section". Steve Mansour wrote: > I sent the .nr and .txt files to Paul who was going to insert the text and provide > more explanation. If you point me to the exact text you want put in the spec I'll do > that this afternoon. > -Steve > > Richard Shusterman wrote: > > > Doug, > > > > I quickly scanned this draft and did not see any of the text that was generated > > at the Boston meeting and sent to this list included in this latest draft. Can > > you please update this draft with that text. I realize there are some discussions > > that still need to be made around some of this text but a number of us did spend > > 2 full days working on this text AND I didn't see any major objections to it's > > inclusion. If you need me to point you to emails with the relevant text, I can do > > that. > > > > Thanks, > > Richard > > > > Doug Royer wrote: > > > > > I have placed the latest CAP draf at: > > > > > > ftp://royer.com/pub/CALSCH > > > > > > Included is cap.txt, the source file cap.nr, and a Makefile using gnu tools. > > > > > > Steve Mansour and myself currently have access to modify the files > > > @home.royer.com. > > > And these will be pushed to ftp://royer.com/pub/CALSCH . > > > > > > Any modification suggestions (other than typo's and simple formatting errors) > > > MUST be sent to the list before they will be included. Typos and formatting > > > errors can be sent to the list or directly to the editors. > > > > > > I am setting up an automated process to notify this list whenever > > > cap.txt is updated by any one of the editors. This script will run > > > once per day and generate email only when cap.txt changes. > > > > > > -Doug From owner-ietf-calendar@imc.org Mon Feb 21 16:36:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17605 for ; Mon, 21 Feb 2000 16:36:05 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA28838 for ietf-calendar-bks; Mon, 21 Feb 2000 13:14:28 -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 NAA28834 for ; Mon, 21 Feb 2000 13:14:26 -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 NAA11347 for ; Mon, 21 Feb 2000 13:18:22 -0800 (PST) Message-ID: <38B1AB9E.E8BEC3F3@home.royer.com> Date: Mon, 21 Feb 2000 13:18:22 -0800 From: Doug Royer Reply-To: IETF CALSCH WG X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: Re: Latest in-process draft References: <38B03BEE.73496282@home.royer.com> <38B18E70.B4992814@netscape.com> Content-Type: multipart/mixed; boundary="------------BC1C9E466EFDC6A482077C40" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------BC1C9E466EFDC6A482077C40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard Shusterman wrote: > > Doug, > > I quickly scanned this draft and did not see any of the text that was generated > at the Boston meeting and sent to this list included in this latest draft. Can > you please update this draft with that text. I realize there are some discussions > that still need to be made around some of this text but a number of us did spend > 2 full days working on this text AND I didn't see any major objections to it's > inclusion. If you need me to point you to emails with the relevant text, I can do > that. As steve pointed out it is in the works. Also, I still do not understand some of the text as I still have unanswered questions that I have posted. In summary (with respect to trying to generate a VCAR for an anonymous UPN): Anonymous - looked ambiguous in the text. What is an anonymous UPN? Anonymous from any domain or any @specifc-domain. I could not tell which. There may have been more. Also, some ABNF or examples needs to be updated to show how to use them. -Doug --------------BC1C9E466EFDC6A482077C40 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------BC1C9E466EFDC6A482077C40-- From owner-ietf-calendar@imc.org Mon Feb 21 18:51:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19131 for ; Mon, 21 Feb 2000 18:51:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA00940 for ietf-calendar-bks; Mon, 21 Feb 2000 15:26:07 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00936 for ; Mon, 21 Feb 2000 15:26:06 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA13274 for ; Mon, 21 Feb 2000 15:27:34 -0800 (PST) Received: from netscape.com ([207.1.153.248]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FQAZX900.JB9 for ; Mon, 21 Feb 2000 15:29:33 -0800 Message-ID: <38B1C9FD.17DD6E24@netscape.com> Date: Mon, 21 Feb 2000 15:27:58 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Clarification on W-19 CAP Group Definitions Content-Type: multipart/mixed; boundary="------------3F537D4F62485254DDB4ACCE" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3F537D4F62485254DDB4ACCE Content-Type: multipart/alternative; boundary="------------9A44C4B8B641A2CED3B9F8E2" --------------9A44C4B8B641A2CED3B9F8E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From Bob Mahoney's W-19 CAP Group Definitions message: EXPAND Return the members of the argument CSID. Successful result yields one or more Calendars and/or Resource Calendars. More than one C or RC returned implies that the CSID was a CC. LOOKUP Return the members of the argument UPN. Successful result yields one or more CSIDs. More than one CSID returned implies that the UPN was a UG. I'm assuming the term "CSID" needs to be replaced with "CalID". It does not make sense to expand a Calendar Store ID (that's it host and port). -Steve --------------9A44C4B8B641A2CED3B9F8E2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit From Bob Mahoney's W-19 CAP Group Definitions message:
EXPAND          Return the members of the argument CSID.  Successful
result yields one or more Calendars and/or Resource Calendars.  More
than one C or RC returned implies that the CSID was a CC.

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

I'm assuming the term "CSID" needs to be replaced with "CalID". It does not make sense to expand a Calendar Store ID (that's it host and port).

-Steve --------------9A44C4B8B641A2CED3B9F8E2-- --------------3F537D4F62485254DDB4ACCE Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------3F537D4F62485254DDB4ACCE-- From owner-ietf-calendar@imc.org Mon Feb 21 19:08:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19270 for ; Mon, 21 Feb 2000 19:08:16 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01254 for ietf-calendar-bks; Mon, 21 Feb 2000 15:49:03 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01250 for ; Mon, 21 Feb 2000 15:49:02 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA11352 for ; Mon, 21 Feb 2000 15:48:35 -0800 (PST) Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FQB0ZI00.UQW; Mon, 21 Feb 2000 15:52:30 -0800 Message-ID: <38B1CF6A.435AC617@netscape.com> Date: Mon, 21 Feb 2000 15:51:06 -0800 From: rans@netscape.com (Richard Shusterman) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: Clarification on W-19 CAP Group Definitions References: <38B1C9FD.17DD6E24@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Mansour wrote: > From Bob Mahoney's W-19 CAP Group Definitions message: > > EXPAND Return the members of the argument CSID. > Successful > result yields one or more Calendars and/or Resource > Calendars. More > than one C or RC returned implies that the CSID was a CC. > > LOOKUP Return the members of the > argument UPN. > Successful result yields one or more CSIDs. More than one > CSID > returned implies that the UPN was a UG. > > I'm assuming the term "CSID" needs to be replaced with "CalID". It > does not make sense to expand a Calendar Store ID (that's it host and > port). Yes, and the text after LOOKUP should be changed to "...yields one or more UPNs. More than one UPN..." From owner-ietf-calendar@imc.org Mon Feb 21 19:08:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19281 for ; Mon, 21 Feb 2000 19:08:31 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01184 for ietf-calendar-bks; Mon, 21 Feb 2000 15:45:26 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01180 for ; Mon, 21 Feb 2000 15:45:26 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA11001 for ; Mon, 21 Feb 2000 15:44:48 -0800 (PST) Received: from netscape.com ([207.1.153.248]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FQB0T700.LA4 for ; Mon, 21 Feb 2000 15:48:43 -0800 Message-ID: <38B1CE77.2A6BE335@netscape.com> Date: Mon, 21 Feb 2000 15:47:04 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: More on W-19 CAP Group Definitions Content-Type: multipart/mixed; boundary="------------CD02272052DB00E13ECF2C86" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------CD02272052DB00E13ECF2C86 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit EXPAND and LOOKUP are listed as CAP Calendaring Commands. I'm assuming we really want these to be Transfer Protocol Commands. Is that correct? -Steve --------------CD02272052DB00E13ECF2C86 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------CD02272052DB00E13ECF2C86-- From owner-ietf-calendar@imc.org Mon Feb 21 19:17:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19355 for ; Mon, 21 Feb 2000 19:17:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01372 for ietf-calendar-bks; Mon, 21 Feb 2000 15:59:28 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01368 for ; Mon, 21 Feb 2000 15:59:27 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA15566 for ; Mon, 21 Feb 2000 16:00:55 -0800 (PST) Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FQB1GU00.INP; Mon, 21 Feb 2000 16:02:54 -0800 Message-ID: <38B1D1DB.87FC4DCA@netscape.com> Date: Mon, 21 Feb 2000 16:01:31 -0800 From: rans@netscape.com (Richard Shusterman) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour CC: CalSched IETF Subject: Re: More on W-19 CAP Group Definitions References: <38B1CE77.2A6BE335@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve Mansour wrote: > EXPAND and LOOKUP are listed as CAP Calendaring Commands. > > I'm assuming we really want these to be Transfer Protocol Commands. Is > that correct? > Yes From owner-ietf-calendar@imc.org Mon Feb 21 22:37:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22719 for ; Mon, 21 Feb 2000 22:37:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA09129 for ietf-calendar-bks; Mon, 21 Feb 2000 18:58:10 -0800 (PST) Received: from pivsbh1.ms.com (pivsbh1.ms.com [199.89.64.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09125 for ; Mon, 21 Feb 2000 18:58:08 -0800 (PST) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id WAA25827; Mon, 21 Feb 2000 22:01:56 -0500 (EST) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9511885101.025650; Mon, 21 Feb 00 22:01:50 -0500 Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id WAA25645; Mon, 21 Feb 2000 22:01:50 -0500 (EST) X-Authentication-Warning: pivsbh1.ms.com: Processed from queue /var/spool/mqueue-vs X-Authentication-Warning: pivsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf Received: from sasmh4.ms.com(144.14.193.5) by pivsbh1 via smap (4.1) id sma.9511884931.025344; Mon, 21 Feb 00 22:01:33 -0500 Received: from msdw.com (hqdsl26.morgan.com [205.228.1.26]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id WAA07064; Mon, 21 Feb 2000 22:01:33 -0500 (EST) Message-ID: <38B1FC0D.DB6E6B9B@msdw.com> Date: Mon, 21 Feb 2000 22:01:33 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: Richard Shusterman CC: Steve Mansour , CalSched IETF Subject: Re: Clarification on W-19 CAP Group Definitions References: <38B1C9FD.17DD6E24@netscape.com> <38B1CF6A.435AC617@netscape.com> Content-Type: multipart/mixed; boundary="------------0D0D26393B85036409C45CDE" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0D0D26393B85036409C45CDE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Richard Shusterman wrote: > > Steve Mansour wrote: > > > From Bob Mahoney's W-19 CAP Group Definitions message: > > > > EXPAND Return the members of the argument CSID. > > Successful > > result yields one or more Calendars and/or Resource > > Calendars. More > > than one C or RC returned implies that the CSID was a CC. > > > > LOOKUP Return the members of the > > argument UPN. > > Successful result yields one or more CSIDs. More than one > > CSID > > returned implies that the UPN was a UG. > > > > I'm assuming the term "CSID" needs to be replaced with "CalID". It > > does not make sense to expand a Calendar Store ID (that's it host and > > port). > > Yes, and the text after LOOKUP should be changed to "...yields one or > more UPNs. More than one UPN..." Not to start a firestorm, but I have two points on this. I suspect EXPAND and LOOKUP will be confused by countless calendar developers from now on, since they both are similiar. Perhaps CALIDEXPAND and UPNEXPAND? This should also be where we have a hook to the SLP to ask the server to use it's version of SLP to figure out which calendar to book a particular UPN against. I'm all for smart clients that can use the SLP to figure this out, but I'd also like to see the client be able to ask the server to do this for it. dmadeo --------------0D0D26393B85036409C45CDE Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;fax:212-762-1009 tel;work:212-762-2348 x-mozilla-html:FALSE url:www.ms.com org:Morgan Stanley Dean Witter and Discover;Information Technology version:2.1 email;internet:dmadeo@ms.com adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA x-mozilla-cpt:;0 fn:David Madeo end:vcard --------------0D0D26393B85036409C45CDE-- From owner-ietf-calendar@imc.org Mon Feb 21 23:51:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23789 for ; Mon, 21 Feb 2000 23:51:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA13866 for ietf-calendar-bks; Mon, 21 Feb 2000 20:06:43 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA13859 for ; Mon, 21 Feb 2000 20:06:41 -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 UAA12640 for ; Mon, 21 Feb 2000 20:10:39 -0800 (PST) Message-ID: <38B20C3E.C9C1A2C0@home.royer.com> Date: Mon, 21 Feb 2000 20:10:38 -0800 From: Doug Royer Reply-To: CalSched IETF X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: CalSched IETF Subject: Re: Clarification on W-19 CAP Group Definitions References: <38B1C9FD.17DD6E24@netscape.com> <38B1CF6A.435AC617@netscape.com> <38B1FC0D.DB6E6B9B@msdw.com> Content-Type: multipart/mixed; boundary="------------53107E44B0E3465C82BC0291" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------53107E44B0E3465C82BC0291 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Madeo wrote: > Not to start a firestorm, but I have two points on this. > > I suspect EXPAND and LOOKUP will be confused by countless calendar > developers from now on, since they both are similiar. Perhaps > CALIDEXPAND and UPNEXPAND? I 2nd that!! --------------53107E44B0E3465C82BC0291 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------53107E44B0E3465C82BC0291-- From owner-ietf-calendar@imc.org Tue Feb 22 02:20:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06398 for ; Tue, 22 Feb 2000 02:20:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22553 for ietf-calendar-bks; Mon, 21 Feb 2000 22:42:08 -0800 (PST) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22546 for ; Mon, 21 Feb 2000 22:42:05 -0800 (PST) From: pregen@egenconsulting.com To: CalSched IETF Subject: Re: Clarification on W-19 CAP Group Definitions X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Tue, 22 Feb 2000 01:45:54 -0500 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at 02/22/2000 01:45:57 AM MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_mixed 00250F758525688D_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 00250F758525688D_= Content-Type: multipart/alternative; boundary="=_alternative 00250F758525688D_=" --=_alternative 00250F758525688D_= Content-Type: text/plain; charset="us-ascii" I make a motion to approve it. It makes good sense. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer Sent by: owner-ietf-calendar@imc.org 02/21/00 11:10 PM Please respond to CalSched IETF To: CalSched IETF cc: Subject: Re: Clarification on W-19 CAP Group Definitions David Madeo wrote: > Not to start a firestorm, but I have two points on this. > > I suspect EXPAND and LOOKUP will be confused by countless calendar > developers from now on, since they both are similiar. Perhaps > CALIDEXPAND and UPNEXPAND? I 2nd that!! --=_alternative 00250F758525688D_= Content-Type: text/html; charset="us-ascii"
I make a motion to approve it.  It makes good sense.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Doug Royer <doug@home.royer.com>
Sent by: owner-ietf-calendar@imc.org

02/21/00 11:10 PM
Please respond to CalSched IETF

       
        To:        CalSched IETF <ietf-calendar@imc.org>
        cc:        
        Subject:        Re: Clarification on W-19 CAP Group Definitions


David Madeo wrote:

> Not to start a firestorm, but I have two points on this.
>
> I suspect EXPAND and LOOKUP will be confused by countless calendar
> developers from now on, since they both are similiar.  Perhaps
> CALIDEXPAND and UPNEXPAND?

I 2nd that!!

--=_alternative 00250F758525688D_=-- --=_mixed 00250F758525688D_= Content-Type: application/octet-stream; name="ATT3079C" Content-Disposition: attachment; filename="ATT3079C" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOlJveWVyO0RvdWcNCnRlbDtwYWdlcjo2NTAtMjc0LTg5NjAgb3IgcGFn ZXJAUm95ZXIuY29tDQp0ZWw7Y2VsbDo2NTAtMjc0LTg5NjANCnRlbDtob21lOjY1MC0yNzQtODk2 MA0KdGVsO3dvcms6ODA1LTk1Ny0xNzkwIHg1NDENCngtbW96aWxsYS1odG1sOkZBTFNFDQp1cmw6 aHR0cDovL1JveWVyLmNvbS9QZW9wbGUvRG91Zw0KdmVyc2lvbjoyLjENCmVtYWlsO2ludGVybmV0 OmRvdWdAaG9tZS5yb3llci5jb20NCmFkcjtxdW90ZWQtcHJpbnRhYmxlOjs7ODAxIFdvb2RzaWRl IFJkLiAjMTQ9MEQ9MEFTdWl0ZSAyNDQ7UmVkd29vZCBDaXR5O0NBOzk0MDYxO1VTQQ0KeC1tb3pp bGxhLWNwdDo7MA0KZm46RG91ZyBSb3llcg0KZW5kOnZjYXJkDQo= --=_mixed 00250F758525688D_=-- From owner-ietf-calendar@imc.org Tue Feb 22 10:03:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11698 for ; Tue, 22 Feb 2000 10:03:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA10071 for ietf-calendar-bks; Tue, 22 Feb 2000 06:35:05 -0800 (PST) Received: from hqvsbh1.ms.com (hqvsbh1.ms.com [205.228.12.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10067 for ; Tue, 22 Feb 2000 06:35:04 -0800 (PST) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/fw v1.30) id JAA00846 for ; Tue, 22 Feb 2000 09:39:03 -0500 (EST) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9512303251.000519; Tue, 22 Feb 00 09:38:45 -0500 Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id JAA00412 for ; Tue, 22 Feb 2000 09:38:44 -0500 (EST) X-Authentication-Warning: hqvsbh1.ms.com: Processed from queue /var/spool/mqueue-vs X-Authentication-Warning: hqvsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf Received: from sasmh4.ms.com(144.14.193.5) by hqvsbh1 via smap (4.1) id sma.9512303101.000028; Tue, 22 Feb 00 09:38:30 -0500 Received: from msdw.com (hqdsl26.morgan.com [205.228.1.26]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id JAA08153 for ; Tue, 22 Feb 2000 09:38:30 -0500 (EST) Message-ID: <38B29F66.26A94441@msdw.com> Date: Tue, 22 Feb 2000 09:38:30 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: CalSched IETF Subject: Re: Clarification on W-19 CAP Group Definitions References: <38B1C9FD.17DD6E24@netscape.com> <38B1CF6A.435AC617@netscape.com> <38B1FC0D.DB6E6B9B@msdw.com> Content-Type: multipart/mixed; boundary="------------E7955B6930FF557E09297CE5" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------E7955B6930FF557E09297CE5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > This should also be where we have a hook to the SLP to ask the server to > use it's version of SLP to figure out which calendar to book a > particular UPN against. I'm all for smart clients that can use the SLP > to figure this out, but I'd also like to see the client be able to ask > the server to do this for it. SLPEXPAND Returns one or more paired UPN's and CALID's for the argument UPN. More than one CALID would indicate that the UPN was a User Group (UG). This allows the client to request an Service Location Protocol (SLP) lookup from the server. I think that the return value should match up the UPN and the CALID. In a simplifid form with no allowance for machine parsing, something like this... dmadeo@ms.com calid://example.com/8489f9d8f pbh@mit.edu calid://example.com/89djfad0f One question I have is whether it's acceptable to say "until the SLP becomes an RFC, a server may use a private method to look this up". dmadeo --------------E7955B6930FF557E09297CE5 Content-Type: text/x-vcard; charset=us-ascii; name="David.Madeo.vcf" Content-Description: Card for David Madeo Content-Disposition: attachment; filename="David.Madeo.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Madeo;David tel;fax:212-762-1009 tel;work:212-762-2348 x-mozilla-html:FALSE url:www.ms.com org:Morgan Stanley Dean Witter and Discover;Information Technology version:2.1 email;internet:dmadeo@ms.com adr;quoted-printable:;;750 Seventh Ave=0D=0A;NY;NY;10019;USA x-mozilla-cpt:;0 fn:David Madeo end:vcard --------------E7955B6930FF557E09297CE5-- From owner-ietf-calendar@imc.org Tue Feb 22 12:36:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16235 for ; Tue, 22 Feb 2000 12:36:31 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA16396 for ietf-calendar-bks; Tue, 22 Feb 2000 09:08:45 -0800 (PST) Received: from hqvsbh1.ms.com (hqvsbh1.ms.com [205.228.12.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16391 for ; Tue, 22 Feb 2000 09:08:44 -0800 (PST) Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/fw v1.30) id MAA07341 for ; Tue, 22 Feb 2000 12:12:44 -0500 (EST) Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1) id sma.9512395381.006587; Tue, 22 Feb 00 12:12:18 -0500 Received: (from uucp@localhost) by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id MAA06471 for ; Tue, 22 Feb 2000 12:12:17 -0500 (EST) X-Authentication-Warning: hqvsbh1.ms.com: Processed from queue /var/spool/mqueue-vs X-Authentication-Warning: hqvsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf Received: from sasmh4.ms.com(144.14.193.5) by hqvsbh1 via smap (4.1) id sma.9512394891.004579; Tue, 22 Feb 00 12:11:29 -0500 Received: from msdw.com (vector.morgan.com [144.14.16.149]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id MAA10987 for ; Tue, 22 Feb 2000 12:11:29 -0500 (EST) Message-ID: <38B2C341.C6BA253D@msdw.com> Date: Tue, 22 Feb 2000 12:11:29 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: Re: Latest in-process draft References: <38B03BEE.73496282@home.royer.com> <38B18E70.B4992814@netscape.com> <38B1AB9E.E8BEC3F3@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Richard Shusterman wrote: > > > > Doug, > > > > I quickly scanned this draft and did not see any of the text that was generated > > at the Boston meeting and sent to this list included in this latest draft. Can > > you please update this draft with that text. I realize there are some discussions > > that still need to be made around some of this text but a number of us did spend > > 2 full days working on this text AND I didn't see any major objections to it's > > inclusion. If you need me to point you to emails with the relevant text, I can do > > that. > > As steve pointed out it is in the works. > > Also, I still do not understand some of the text as I still have unanswered > questions that I have posted. In summary (with respect to trying to generate > a VCAR for an anonymous UPN): > > Anonymous - looked ambiguous in the text. What is an anonymous UPN? > Anonymous from any domain or any @specifc-domain. I could not tell which. A totally anonymous UPN is "@". It may be possible to authenticate using a SASL method, but obtain the "domain anonymous" UPN such as "@example.com". This means you can be identified as someone from example.com, but we're not sure which person. It's important to distinguish between UPN's and ACL pattern matches. ACL's currently require a UPN. We've also discussed putting pattern matches into ACL rules as well as definitive UPN's. So I may choose to let "@" see my freebusy time, "@example.com" see certain types of data and "mybestfriend@example.com" see everything. This translates to anyone can see my freebusy. Anyone who can authenticate at example.com can see certain types of data and that specific UPN can see everything. A simple example: Using SASL, I can authenticate as me and get my normal UPN "dmadeo@example.com". Or I could authenticate as me and ask for another UPN. Whichever authentication method I use can look up to see if I'm allowed to ask for that particular UPN and either allow or disallow it. The CU trusts the SASL methods to only give it UPN's that are properly authorized. I ask to see the calendar calid://example.com/a9dfhj23jf which has an ACL which says "dmadeo@example.com" is an owner. I can modify the calendar as much as I'd like. I then ask to see calid://example.com/89jadf77adf which has an ACL saying "@example.com" has full read access. Because my UPN is "dmadeo@example.com", and the ACL says "@example.com", I should then have full read access. Hope this clarifies things. dmadeo > There may have been more. > > Also, some ABNF or examples needs to be updated to show how to use them. > > -Doug From owner-ietf-calendar@imc.org Tue Feb 22 13:00:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16970 for ; Tue, 22 Feb 2000 13:00:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17842 for ietf-calendar-bks; Tue, 22 Feb 2000 09:33:08 -0800 (PST) Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17802 for ; Tue, 22 Feb 2000 09:33:04 -0800 (PST) Received: from ebusboom3 (ebusboom3.qualcomm.com [129.46.69.207]) by jittlov.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with SMTP id JAA02150; Tue, 22 Feb 2000 09:37:02 -0800 (PST) Message-Id: <4.1.20000222091907.01769860@donelly.qualcomm.com> X-Sender: ebusboom@donelly.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 22 Feb 2000 09:29:29 -0800 To: "Dannie M Stanley" , From: Eric Busboom Subject: Re: What/Where is ICAP In-Reply-To: <009a01bf7a5e$d7ef6c50$0400a8c0@muncie1.in.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 02:23 PM 2/18/00 , Dannie M Stanley wrote: >I realize ICAP is a protocol, but I want to start using it in combination >with mcal and I cannot for the life of me figure out where to start. If >someone could answer the following to help me get started I would be greatly >appreciative: > >Where can I find an ICAP compliant server? You may be able to find an ICAP server on freshmeat.net. ICAP is the calendaring access protocol defined in a venerable draft that Pete O'Leary wrote in mid-1998. The draft expired in December of 1998 and was not renewed. The obsolete draft was removed from the CALSCH website several months ago after being superceded by the current CAP drafts. The protocol behind mcal was obsolete the day the project started, so if you are a programmer, you should probably devote your efforts to working on the currently accepted iCal protocols. eric. From owner-ietf-calendar@imc.org Tue Feb 22 13:39:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18307 for ; Tue, 22 Feb 2000 13:39:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA19962 for ietf-calendar-bks; Tue, 22 Feb 2000 10:11:07 -0800 (PST) Received: from c008.sfo.cp.net (c008-h013.c008.sfo.cp.net [209.228.14.202]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19958 for ; Tue, 22 Feb 2000 10:11:05 -0800 (PST) Received: (cpmta 13121 invoked from network); 22 Feb 2000 10:14:36 -0800 Received: from grazzt.eng.cp.net (HELO cp.net) (209.228.9.58) by smtp.criticalpath.net with SMTP; 22 Feb 2000 10:14:36 -0800 X-Sent: 22 Feb 2000 18:14:36 GMT Message-ID: <38B2D204.61BA9DB4@cp.net> Date: Tue, 22 Feb 2000 10:14:28 -0800 From: brian moseley X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Busboom CC: Dannie M Stanley , ietf-calendar@imc.org Subject: Re: What/Where is ICAP References: <4.1.20000222091907.01769860@donelly.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Eric Busboom wrote: > > At 02:23 PM 2/18/00 , Dannie M Stanley wrote: > >I realize ICAP is a protocol, but I want to start using it in combination > >with mcal and I cannot for the life of me figure out where to start. If > >someone could answer the following to help me get started I would be greatly > >appreciative: > > > >Where can I find an ICAP compliant server? the mcap guys make a test server available, as i recall. > You may be able to find an ICAP server on freshmeat.net. > > ICAP is the calendaring access protocol defined in a venerable draft that Pete O'Leary wrote in mid-1998. The draft expired in December of 1998 and was not renewed. The obsolete draft was removed from the CALSCH website several months ago after being superceded by the current CAP drafts. in fact a new draft is due to be submitted fairly soon. > The protocol behind mcal was obsolete the day the project started, so if you are a programmer, you should probably devote your efforts to working on the currently accepted iCal protocols. incorrect. icap is in use in production today at critical path. furthermore, the folks at helix code are planning to add icap support to the gnome office suite and reportedly are building their own icap server. given the snail's pace at which cap is progressing, our plans are to move ahead full steam with icap, extending it as necessary and submitting new drafts so that others can keep up with what we're doing and actually write some interoperable software. From owner-ietf-calendar@imc.org Tue Feb 22 15:49:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22566 for ; Tue, 22 Feb 2000 15:49:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA23108 for ietf-calendar-bks; Tue, 22 Feb 2000 12:26:46 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23104 for ; Tue, 22 Feb 2000 12:26:44 -0800 (PST) Received: (from sman@localhost) by home.royer.com (8.9.1/8.9.1) id MAA14695 for ietf-calendar@imc.org; Tue, 22 Feb 2000 12:30:46 -0800 (PST) Date: Tue, 22 Feb 2000 12:30:46 -0800 (PST) From: ietf-calendar@imc.org Message-Id: <200002222030.MAA14695@home.royer.com> To: ietf-calendar@imc.org Subject: CAP draft update Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The CAP draft files have been updated on: ftp://royer.com/pub/CALSCH From owner-ietf-calendar@imc.org Wed Feb 23 15:55:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02700 for ; Wed, 23 Feb 2000 15:55:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA01406 for ietf-calendar-bks; Wed, 23 Feb 2000 12:21:36 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01402 for ; Wed, 23 Feb 2000 12:21:31 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA27672 for ; Wed, 23 Feb 2000 12:23:05 -0800 (PST) Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FQEGPV00.L4K; Wed, 23 Feb 2000 12:25:07 -0800 Message-ID: <38B441CC.120DFA7D@netscape.com> Date: Wed, 23 Feb 2000 12:23:40 -0800 From: rans@netscape.com (Richard Shusterman) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: pregen@egenconsulting.com CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: Groups revisited References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > Bruce/Richard: > > Regarding the long note on Groups (which I don't want to reprint > because it's now too long) - basically, I think you both are saying > the same thing. Bruce, I think you may have hit upon something. > Everyone is really getting down into the nitty gritty on groups and > worried that there is a problem. But, to summarize what you are > saying (or what I think you are saying) is that a group is really just > a list of UPN's. All the calendar product has to do is read the list > and validate the members as if they were each an independent UPN. > Correct? If so, that seems like a "well, duh..." Am I missing > something, or does this really sound like it's a non issue and > simplier than everyone has been assuming. If it is true, than > implementing groups should not be as hard as we envisioned?? I don't think it's really a question of "is this hard". Without group support, I don't think CAP will be useful for most scheduling environments. I think Bruce and I are in agreement on this point. However, I want this group support to be optional for some CS/CUA implementations that don't require scheduling, just calendaring. Also, we need groups that can work with multiple directory implementations and for the thin CUA implementations that don't want to use multiple client protocols, we should have minimal group lookup/expansion capabilities available thru CAP. > Also, I agree with Bruce's comment about not using the Personal NAB to > authenticate UPN's. Agreed, this was a bad example on my part. However, some CS implementations may be able to use Personal NAB's in group expansions. From owner-ietf-calendar@imc.org Wed Feb 23 16:03:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02834 for ; Wed, 23 Feb 2000 16:03:37 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA01255 for ietf-calendar-bks; Wed, 23 Feb 2000 12:07:48 -0800 (PST) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01250 for ; Wed, 23 Feb 2000 12:07:47 -0800 (PST) Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA01966 for ; Wed, 23 Feb 2000 12:07:21 -0800 (PST) Received: from netscape.com ([207.1.151.176]) by tintin.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FQEG2W00.9CO; Wed, 23 Feb 2000 12:11:20 -0800 Message-ID: <38B43E90.276880C4@netscape.com> Date: Wed, 23 Feb 2000 12:09:52 -0800 From: rans@netscape.com (Richard Shusterman) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: ietf-calendar@imc.org Subject: Re: Groups revisited References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce, Sorry I took so long in responding. Some responses below: Bruce_Kahn@iris.com wrote: > When I AUTHENTICATE with my CS, the credentialling process > will result in 1 or more UPNs being 'spat out' if the process works. > Lets say that when Frank AUTHENTICATEs with his CS, it (his CS > thanks to the authentication mechanism) says that the pair of UPNs > Frank_Dawson@lotus.com and CAPEditors@calsched.apps.ietf.org > are 'valid' identities for Frank. He can use them as part of VCARs or > wherever else we allow UPNs. How does Frank get his list of UPNs? One of the new CAP commands that we came up with in Boston to solve this problem was LOOKUP (a proposal was recently made to rename this to UPNEXPAND). Or, are you suggesting that as part of the AUTHENTICATE response, these UPNs are returned? > The CS _really_ should keep all the UPNs that are spat out for VCAR > comparison, etc. That way, if there is a VCAR on a paricular event > in the calendar that has a VCAR that only allows > CAPEditors@calsched.apps.ietf.org to read or edit it then Frank should > be able to access that entry. Just because Franks "primary" (ugh, for lack > of a better description so do not take literally) UPN is > Frank_Dawson@lotus.com does not mean that he has to do nasty things > like switching identities to be able to access an entry that does have > CAPEditors@calsched.apps.ietf.org on the VCAR. The CS should do > this equivalence for him! I agree. That's why we also agreed in Boston to remove the IDENTIFY command (which somehow still lives in the CAP draft - I will ask the editors to remove it) since it's not needed. > Smack the group UPN creator up side the head. Groups are much more > useful if their are descriptive than if they are just mangled sequences of > seemingly random junk. Sometimes they are not easily distinguished from > that of a single CU (ie: postmaster@lotus.com is probably shared among a > couple folks even though it could be just 1 person). Since group names are not always descriptive, hence the need again for the LOOKUP (or UPNEXPAND) command. BTW, if the CS chooses not to support group expansion, it can simply return the same UPN passed in by this command. > Im still a big KISS advocate and Im not sure we need/want to have the > CS do group expansion by request. That sounds like a directory issue really > rather than a C&S one. Just as a CUA would probably do some kind of > lookup (ie: LDAP, etc) on Frank_Dawson@lotus.com to get some info Frank, > the same can and probably should be done by the CUA for the other UPN. > > In addition, I think the CS should fully unwind nested groups for the fairly > obvious reason that ANY nested group could be on a VCAR. As such > as long as Frank is a member of a nested group he should be granted/denied > access accordingly. Whether a CS supports groups and whether a CS unwinds nested groups is an implementation issue. If the CS supports groups (as in your VCAR example), it might as well make this information available to the CUA via the LOOKUP (or UPNEXPAND) command. > Personal address books cannot be used by the CS to enforce or expand > group UPNs during AUTHENTICATion. Besides being a BIG security hole, > its not feasible to even consider HOW the CS could safely get the info from > the CUA and really trust it.. I dont want to murky the waters by talking > about local replicas of the CSs address book (or partial replicas, etc). > Thats > OOB for CAP I think. For the CU to create their own group UPNs that > the CS can use, it would have to be done in such a way that the CS can > trust the data (ie: via read/write control to a shared LDAP server, etc). > We can dive on some of the nitty gritty issues later but Im trying to see > if the higher level view/logic I posted originally is accurate... Depends on where the personal address books are stored ... maybe they're on the CS? In any case, this is implementation specific. > We are of similar thought I think but you are doing the expansion in a > different way then I proposed. If the CS determines ALL the UPNs I am > synonymous with when I AUTHENTICATE then it does not have to > expaned EVERY VCAR on every ACCESS to try and find a match > for my 'primary' (sic.) UPN. Its much much cheaper to take the hit up > front than for every request/response that needs to be done. As long as > ANY UPN in my list of identities matches the VCARs then that VCAR > drawback is that a change to a group UPN wont take effect until I > is applied to me. That only reAUTHENTICATE. Typically though this > is not such a big deal and can be handled by some good up front CS > architecture for handling change notifications. Implementation specific. > Argh, a step backwards in agreement. WAAY back in Montreal we > agreed that the authentication process could generate > 1 UPN for a set of > credentials. We never precluded that all of those UPNs must be unique for > a CU. If its not unique per CU then it in effect is a group UPN. Agreed. > Im claiming that groups can be easily handled by this ability to have > 1 > UPN generated when I AUTHENTICATE with the CS and that is > something that all CS vendors will have to deal with. Im NOT a big fan > of bloating CAP even more by having the CS act as a UPN directory > server of sorts as it just deters vendors from making CS implementations. The CS is not required to be a UPN directory. However, if we agree that it's a good thing to put group UPNs in CAP, then we need definitions and commands to allow a CS to share this information with a CUA. A CUA should not assume that it's CS supports groups. Perhaps, it would help if we added a CAPABILITY response from the CS that can tell the CUA exactly what level of group support is available in this CS, e.g., group UPNs are allowed, nested groups are expanded, etc. > Just how do were you (collectively now) envissioning that the CS would use > the other UPNs that are generated as part of the certification process?? > Are they to be ignored? If all CSs must generate the same list of UPNs > for a given set of credentials then what is the big deal in the CS using > them to evaluate VCARs, etc later one? I think the AUTHENTICATE process has to allow a CS to ignore multiple UPNs just like a CS should be allowed to ignore group UPNs. Not every CS vendor will want to support these features. > Ok this may be bass ackwards but Ill try to rephrase my idea in as simple > terms as Im able at this time of day: > > Given: > 1: The AUTHENTICATion process may result in > 1 UPN being generated for a > given set of credentials and > 2: Not all UPNs are 100% unique per CU Agreed. > That: > 1: It is possible to have a 'group' UPN generated as one of a CUs UPNs > when they AUTHENTICATE and > 2: A CS should be able to match ANY of the UPNs generated during > authentication in a normal UPN check (ie: in VCAR evaluation) Agreed, especially the "should" part. > Therefore: > 1: This 'group' UPN can be used anywhere a UPN is normally used (ie: VCAR) > and > 2: No extra or overly complex extra mechanisms are needed in CAP to > distinguish a 'group' UPN from an 'non-group' UPN and > 3: We do not need to distingush beteen 'group' and 'non-group' UPN flavors > anymore. Agreed. I think this is what we came up with in Boston and is now reflected in the CAP draft. Richard From owner-ietf-calendar@imc.org Wed Feb 23 20:16:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06227 for ; Wed, 23 Feb 2000 20:16:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA05670 for ietf-calendar-bks; Wed, 23 Feb 2000 16:50:22 -0800 (PST) Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05666 for ; Wed, 23 Feb 2000 16:50:21 -0800 (PST) Received: from kaipara (mg-20425426-75.ricochet.net [204.254.26.75]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with SMTP id QAA18308 for ; Wed, 23 Feb 2000 16:53:06 -0800 (PST) Message-Id: <3.0.6.32.20000223163928.0095aa30@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 23 Feb 2000 16:39:28 -0800 To: ietf-calendar@imc.org From: Ross Finlayson Subject: Recurrence rule question 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: I have a question about how to specify a particular, rather complicated, kind of recurrence rule: "Every month on a certain day of the month, except that if this falls on a Saturday or Sunday, move it to the following Monday". I can see how to do this for days that *aren't* near the end of the month. E.g., for "Every 15th of the month, except that if it's a Saturday or Sunday, move to the following Monday", you could say: FREQ=MONTHLY;BYMONTHDAY=15,16,17;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=1 in other words: the first weekday each month that occurs on the 15th, 16th, or 17th. However, this doesn't work for days near the end of the month. How could you specify "30th of each month, except that if it's a Saturday or Sunday, move to the next Monday". Is this even possible? Ross. From owner-ietf-calendar@imc.org Wed Feb 23 21:39:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07230 for ; Wed, 23 Feb 2000 21:39:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA08797 for ietf-calendar-bks; Wed, 23 Feb 2000 18:11:54 -0800 (PST) Received: from tomts2-srv.bellnexxia.net (tomts2.bellnexxia.net [209.226.175.140]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08790 for ; Wed, 23 Feb 2000 18:11:51 -0800 (PST) Received: from puffin ([207.236.3.141]) by tomts2-srv.bellnexxia.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20000224021519.GDJ17030.tomts2-srv.bellnexxia.net@puffin>; Wed, 23 Feb 2000 21:15:19 -0500 Message-Id: <3.0.2.32.20000223211522.01063d7c@pop1.sympatico.ca> X-Sender: b1yzse88@pop1.sympatico.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32) Date: Wed, 23 Feb 2000 21:15:22 -0500 To: Ross Finlayson , ietf-calendar@imc.org From: Mark Baker Subject: Re: Recurrence rule question In-Reply-To: <3.0.6.32.20000223163928.0095aa30@shell7.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some days, I wish we would have just decided to do recurrence rules procedurally (via a script) rather than declaratively. I've personally implemented iCalendar recurrence rules, and I tell ya, I would much rather have implemented a script processor. 8-/ Sorry I can't help with your specific question. I'm better at going the other direction. 8-) MB At 04:39 PM 2/23/00 -0800, Ross Finlayson wrote: >I have a question about how to specify a particular, rather complicated, >kind of recurrence rule: "Every month on a certain day of the month, except >that if this falls on a Saturday or Sunday, move it to the following Monday". > >I can see how to do this for days that *aren't* near the end of the month. >E.g., for "Every 15th of the month, except that if it's a Saturday or >Sunday, move to the following Monday", you could say: > FREQ=MONTHLY;BYMONTHDAY=15,16,17;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=1 >in other words: the first weekday each month that occurs on the 15th, 16th, >or 17th. > >However, this doesn't work for days near the end of the month. How could >you specify "30th of each month, except that if it's a Saturday or Sunday, >move to the next Monday". Is this even possible? > > Ross. > > > > From owner-ietf-calendar@imc.org Thu Feb 24 00:19:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10961 for ; Thu, 24 Feb 2000 00:19:52 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19171 for ietf-calendar-bks; Wed, 23 Feb 2000 20:48:38 -0800 (PST) Received: from hotmail.com (f66.law7.hotmail.com [216.33.237.66]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA19167 for ; Wed, 23 Feb 2000 20:48:38 -0800 (PST) Received: (qmail 17200 invoked by uid 0); 24 Feb 2000 04:52:17 -0000 Message-ID: <20000224045217.17199.qmail@hotmail.com> Received: from 202.54.42.186 by www.hotmail.com with HTTP; Wed, 23 Feb 2000 20:52:17 PST X-Originating-IP: [202.54.42.186] From: "Nitin Shingne" To: ietf-calendar@imc.org Subject: RFC 2446 : Discrepancy in Organizer & Methods...? Date: Wed, 23 Feb 2000 20:52:17 PST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings !!! Under section "1.3 ITIP Roles and Transactions" refer to methods broken down by who can send them... It says an "Originator" can send PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER . Now please refer to section "3.2.6 REFRESH" for VEVENT objects.... It says "Organizer" is MUST. thanks & regrads, nitin. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ietf-calendar@imc.org Thu Feb 24 00:20:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10985 for ; Thu, 24 Feb 2000 00:20:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19126 for ietf-calendar-bks; Wed, 23 Feb 2000 20:47:11 -0800 (PST) Received: from hotmail.com (f14.law7.hotmail.com [216.33.237.14]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA19122 for ; Wed, 23 Feb 2000 20:47:10 -0800 (PST) Received: (qmail 92770 invoked by uid 0); 24 Feb 2000 04:50:50 -0000 Message-ID: <20000224045050.92767.qmail@hotmail.com> Received: from 202.54.42.186 by www.hotmail.com with HTTP; Wed, 23 Feb 2000 20:50:49 PST X-Originating-IP: [202.54.42.186] From: "Nitin Shingne" To: ietf-calendar@imc.org Subject: RFC2446: What's TZOFFSET ? Date: Wed, 23 Feb 2000 20:50:49 PST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings !!! Please refer to section "3.1 Common Component Restriction Tables" in RFC 2446. The property restrictions for "VTIMEZONE" component say that property "TZOFFSET" must be present. Should this be "TZID" instead. I could no locate TZOFFSET in RFC 2445 or 2446. Please clarify. thanks & regards, nitin ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ietf-calendar@imc.org Thu Feb 24 10:04:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01963 for ; Thu, 24 Feb 2000 10:04:40 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA09485 for ietf-calendar-bks; Thu, 24 Feb 2000 06:29:57 -0800 (PST) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09480 for ; Thu, 24 Feb 2000 06:29:57 -0800 (PST) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA00240 for ; Thu, 24 Feb 2000 06:31:31 -0800 (PST) Received: from netscape.com ([198.93.95.223]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FQFV3Y00.JP3; Thu, 24 Feb 2000 06:33:34 -0800 Message-ID: <38B540DB.D84F96E0@netscape.com> Date: Thu, 24 Feb 2000 06:31:55 -0800 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: pregen@egenconsulting.com CC: CalSched IETF Subject: Re: Clarification on W-19 CAP Group Definitions References: Content-Type: multipart/mixed; boundary="------------29917038E6F058A17CD00FCF" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------29917038E6F058A17CD00FCF Content-Type: multipart/alternative; boundary="------------CC54CBEA1EC5441BB9B6C56B" --------------CC54CBEA1EC5441BB9B6C56B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit These updates are now in the latest draft. -Steve pregen@egenconsulting.com wrote: > > I make a motion to approve it. It makes good sense. > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 > > > Doug Royer Sent by: To: CalSched IETF owner-ietf-calendar@imc.org cc: 02/21/00 11:10 PM Subject: Re: Please respond to CalSched IETF Clarification on W-19 CAP Group Definitions > > David Madeo wrote: > > > Not to start a firestorm, but I have two points on this. > > > > I suspect EXPAND and LOOKUP will be confused by countless calendar > > developers from now on, since they both are similiar. Perhaps > > CALIDEXPAND and UPNEXPAND? > > I 2nd that!! > --------------CC54CBEA1EC5441BB9B6C56B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit These updates are now in the latest draft.
-Steve

pregen@egenconsulting.com wrote:

 
I make a motion to approve it.  It makes good sense.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
 
 
Doug Royer <doug@home.royer.com>
Sent by: owner-ietf-calendar@imc.org

02/21/00 11:10 PM
Please respond to CalSched IETF
        To:        CalSched IETF <ietf-calendar@imc.org>
        cc: 
        Subject:        Re: Clarification on W-19 CAP Group Definitions

David Madeo wrote:

> Not to start a firestorm, but I have two points on this.
>
> I suspect EXPAND and LOOKUP will be confused by countless calendar
> developers from now on, since they both are similiar.  Perhaps
> CALIDEXPAND and UPNEXPAND?

I 2nd that!!
 

--------------CC54CBEA1EC5441BB9B6C56B-- --------------29917038E6F058A17CD00FCF Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:650-937-2103 tel;work:650-937-2378 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------29917038E6F058A17CD00FCF-- From owner-ietf-calendar@imc.org Thu Feb 24 16:00:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10313 for ; Thu, 24 Feb 2000 16:00:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16184 for ietf-calendar-bks; Thu, 24 Feb 2000 12:26:36 -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 MAA16180 for ; Thu, 24 Feb 2000 12:26:34 -0800 (PST) Received: (from sman@localhost) by home.royer.com (8.9.1/8.9.1) id MAA03204 for ietf-calendar@imc.org; Thu, 24 Feb 2000 12:30:44 -0800 (PST) Date: Thu, 24 Feb 2000 12:30:44 -0800 (PST) From: ietf-calendar@imc.org Message-Id: <200002242030.MAA03204@home.royer.com> To: ietf-calendar@imc.org Subject: CAP draft update Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The CAP draft files have been updated on: ftp://royer.com/pub/CALSCH From owner-ietf-calendar@imc.org Fri Feb 25 10:30:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11483 for ; Fri, 25 Feb 2000 10:30:46 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA27005 for ietf-calendar-bks; Fri, 25 Feb 2000 07:06:24 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27001 for ; Fri, 25 Feb 2000 07:06:22 -0800 (PST) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: "Nitin Shingne" Cc: ietf-calendar@imc.org Subject: Re: RFC 2446 : Discrepancy in Organizer & Methods...? X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Fri, 25 Feb 2000 10:11:38 -0500 X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Release 5.0.2b |December 16, 1999) at 02/25/2000 10:10:28 AM, Serialize by Notes Client on Bruce Kahn/Iris(Release 5.0.2b |December 16, 1999) at 02/25/2000 10:10:28 AM, Serialize complete at 02/25/2000 10:10:28 AM, Itemize by Notes Client on Bruce Kahn/Iris(Release 5.0.2b |December 16, 1999) at 02/25/2000 10:10:28 AM, S/MIME Sign complete at 02/25/2000 10:10:28 AM, Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 02/25/2000 10:11:09 AM, Serialize complete at 02/25/2000 10:11:09 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: text/plain; charset="us-ascii" Nitin noticed: >It says an "Originator" can send PUBLISH, REQUEST, ADD, CANCEL, >DECLINECOUNTER . > >Now please refer to section "3.2.6 REFRESH" for VEVENT objects.... >It says "Organizer" is MUST. Another good catch. REFRESH should also be listed in 1.3 as a method the Organizer can use. Keep those discrepancies coming! 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... ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMjI1MTUxMDI4WjAj BgkqhkiG9w0BCQQxFgQUn0kBKokvWPqsNLi/c7xJPqQKy44wTAYJKoZIhvcNAQkP MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQDw8nVvZ4akn5+rvsVNX vtr0BN7jV7AYjZBGqRkoMUw5yXKwT/VXgZK9frFlsMuNlxxUhYHtLr5s66qjvM7Q hcoAAAAAAAAAAA== ---------z01886_boundary_sign-- From owner-ietf-calendar@imc.org Fri Feb 25 10:31:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11575 for ; Fri, 25 Feb 2000 10:31:51 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA26777 for ietf-calendar-bks; Fri, 25 Feb 2000 07:04:05 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.42] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26773 for ; Fri, 25 Feb 2000 07:04:03 -0800 (PST) From: Bruce_Kahn@iris.com Importance: High X-Priority: 1 (High) To: "Nitin Shingne" Cc: ietf-calendar@imc.org Subject: Re: RFC2446: What's TZOFFSET ? X-Mailer: Lotus Notes Release 5.0.2b December 16, 1999 Message-ID: Date: Fri, 25 Feb 2000 10:09:17 -0500 X-MIMETrack: S/MIME Sign by Notes Client on Bruce Kahn/Iris(Release 5.0.2b |December 16, 1999) at 02/25/2000 10:08:07 AM, Serialize by Notes Client on Bruce Kahn/Iris(Release 5.0.2b |December 16, 1999) at 02/25/2000 10:08:07 AM, Serialize complete at 02/25/2000 10:08:07 AM, Itemize by Notes Client on Bruce Kahn/Iris(Release 5.0.2b |December 16, 1999) at 02/25/2000 10:08:07 AM, S/MIME Sign complete at 02/25/2000 10:08:07 AM, Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 02/25/2000 10:08:50 AM, Serialize complete at 02/25/2000 10:08: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: text/plain; charset="us-ascii" Nitin asked: >The property restrictions for "VTIMEZONE" component say that property >"TZOFFSET" must be present. >Should this be "TZID" instead. I could no locate TZOFFSET in RFC 2445 >or 2446. This is an artifact of edit changes to RFC 2445 and 2446 that got missed. We used to have a TZOFFSET property but with the change of VTIMEZONE to have a STANDARD and DAYLIGHT components, each of wich has a TZOFFSETTO and TZOFFSETFROM property to handle this now it became obsolete. RFC 2446 Editors: Chalk this up as an update that needs to get applied. Im sure there are more stale references as well since we didnt fine comb RFC 2446 to keep it in sync w/all the 2445 changes. 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... ---------z01886_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwMjI1MTUwODA3WjAj BgkqhkiG9w0BCQQxFgQUN91VsszOUmfQ4aFA/aSx8g87W2QwTAYJKoZIhvcNAQkP MT8wPTAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEQCGs2Qu8wPUN736xpefv GHdu0ece9w2OoEIN82oLpmrnljuDOHCT7R7jVHx2UzZPHHgvhN3poV/tKrtFs5H9 0qAAAAAAAAAAAA== ---------z01886_boundary_sign-- From owner-ietf-calendar@imc.org Sun Feb 27 02:32:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07055 for ; Sun, 27 Feb 2000 02:32:46 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA29917 for ietf-calendar-bks; Sat, 26 Feb 2000 23:16:27 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA29913 for ; Sat, 26 Feb 2000 23:16:26 -0800 (PST) Received: (from sman@localhost) by home.royer.com (8.9.1/8.9.1) id XAA19812 for ietf-calendar@imc.org; Sat, 26 Feb 2000 23:16:15 -0800 (PST) Date: Sat, 26 Feb 2000 23:16:15 -0800 (PST) From: ietf-calendar@imc.org Message-Id: <200002270716.XAA19812@home.royer.com> To: ietf-calendar@imc.org Subject: CAP draft update Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The CAP draft files have been updated on: ftp://royer.com/pub/CALSCH/cap.txt Source files and cap.txt: ftp://royer.com/pub/CALSCH/sources.tar.gz From owner-ietf-calendar@imc.org Sun Feb 27 03:16:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01402 for ; Sun, 27 Feb 2000 03:16:31 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA02002 for ietf-calendar-bks; Sun, 27 Feb 2000 00:00:21 -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 AAA01998 for ; Sun, 27 Feb 2000 00:00:17 -0800 (PST) Received: (from doug@localhost) by royer.com (8.9.1/8.9.1) id AAA12320 for ietf-calendar@imc.org; Sun, 27 Feb 2000 00:00:06 -0800 (PST) Date: Sun, 27 Feb 2000 00:00:06 -0800 (PST) From: Doug Royer Message-Id: <200002270800.AAA12320@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 Y appointments are in same table W-3 CAP Use SASL as authentication method Y W-4 Add UID and COUNTER to VFREEBUSY N W-5 CAP Should CAPABILITY reply be sent N as result of successful AUTHENTICATE and IDENTITY W-6 Do we need to handle 'unscheduled event' as described by the SKI project? N (In CAP - 'N', SKI to be a seperate project/draft as it will effect RFC2445,6,7) W-7 CAP Auto-logout Timer issues Do we need one? Y How long? Can the server decide not to do this? Y W-8 CAP Bounded Latency Issues D W-9 CAP MOVE method. Issues with VCARs. Y [see note in CAP 7.2.1.5] W-10 CAP Text mandatory in all response N codes W-11 CAP Text optional in response codes Y (some response codes may have mandatory data that follows) W-12 CAP Should parts of response code be Y separated by ';' W-13 CAP Store Schema Y W-14 CAP VEVENT Schema Y W-15 CAP VTODO Schema Y W-16 CAP VJOURNAL Schema Y W-17 CAP VCAR Schema Y W-18 CAP UPN definition, including anonymous 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 N and LAST-MODIFIED properties. W-21 CAP Get/Set calendar user properties N W-22 VTIMEZONE and IANA Y in process W-23 CAP Calendar property to allow/disallow N overlapped booking OPAQUE entries? W-24 CAP Calendar CHARSET property issues Y W-25 Remove MUST from UID in 4.8.4.7 Y W-26 Write/Submit information draft/rfc Y W-27 How a query can specify if the recurrence Y rules are to be expanded by the CS. W-28 Cal-Props - PATH N (CAP-00 - 12.2) Will there need to be one? N Optional? N W-29 Import/Export Y - sync only W-30 Transport protocol name (transport vs Y application layer) W-31 NOOP command? Y W-32 NOOP advisory only? Y W-33 Should DISCONNECT be called QUIT? U W-34 Format following error codes. Are Y they well defined? If not they need to be machine determinable. W-35 Move DNS and SLP to seperate draft? Y ------------------------------------------------------------------------------ The following are a list of action items for the CAP draft editors: Draft Action Item Who Done (Y/N) ----------------- --- ---------- C-1 Remove unused definitions N C-2 Fix up changes in authentication Alex N text as commented on the list Paul C-3 Text for 2.7 [Finding CAP Servers] Doug N C-4 VCAR examples Doug? N C-5 PUBLISH text C-6 REQUEST text C-7 REPLY text C-8 ADD text C-9 CANCEL text C-10 REFRESH text C-11 COUNTER text C-12 DECLINECOUNTER Text C-13 Post CAP-00.txt Y C-14 Redo state diagram to include STARTTLS and IDENTIFY command. C-15 Document the 'CALMASTER' calendar property C-16 (2.11) Query Schema I'll send this out next week. C-17 (7.2.1.5) MOVE Method More text needed - Who? C-18 (12.1) Calendar Store Properties Editors note. (Per W-27) C-19 (12.2) SCHEDULABLE-HOURS Format? Text needs to be written. C-20 (13.) Security Considerations See editors note - more text. ------------------------------------------------------------------------------ The following are a list of action items for the iCalendar-2 draft: Draft Action Item Who Done (Y/N) ----------------- --- ---------- I-1 MIME alternate/related Frank ? MUST be supported. I-2 Remove ordering of properties and Frank ? parameters in draft. I-3 S/MIME and RFC1847. U [CAP] 2.2.3 ------------------------------------------------------------------------------ Updates should be sent to mailto:ietf-calendar@imc.org or to myself mailto:Doug.Royer@Software.COM -------------------------------------------------------------------------- Work: Doug.Royer@Software.com Home 801 Woodside Rd #14-244 530 E. Montecito St. Office: Redwood City, CA 94061 Santa Barbara, CA 93103 805-957-1790 x541 Personal Email: Doug@Royer.com From owner-ietf-calendar@imc.org Sun Feb 27 14:08:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10429 for ; Sun, 27 Feb 2000 14:08:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA15852 for ietf-calendar-bks; Sun, 27 Feb 2000 10:53:31 -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 KAA15848 for ; Sun, 27 Feb 2000 10:53:30 -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 KAA20962; Sun, 27 Feb 2000 10:53:14 -0800 (PST) Message-ID: <38B9729A.A29AEB8F@home.royer.com> Date: Sun, 27 Feb 2000 10:53:14 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Richard Shusterman CC: pregen@egenconsulting.com, Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: UPN + GROUP + UPNEXPAND question. References: <38B441CC.120DFA7D@netscape.com> Content-Type: multipart/mixed; boundary="------------552B1587607A481F60CD95DD" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------552B1587607A481F60CD95DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Within the context of groups, when do you get MULTIPLE UPNs? There was talk that you MUST do a UPNEXPAND each time you authenticate? Seems a silly to have an extra round trip. Why not do it as part of the authentication reply? Then I still do NOT know what you do with them. At what point does the CUA ever pass them back to the CS? If never, then what's the point? Perhaps those of you that understand UPN's can send some text or email describing when you get them? The current CAP draft and the text from Paul (I think it was from Paul) does not seem to say. I think Bruce says they comeback as part of the authentication reply? Yet no one that proposed any new text has replied to that question. And I can't find any text that says that. There was no proposed changes to the ABNF or any text, or any example in CAP-draft that shows when you get them, other than UPNEXPAND. As I understoon groups of calendars, it was meant to be something like: If you happen (at run time) to be part of group-A, and there is a calendar that has modify permission to cal-group-a, then you can modify that calendar. So why does the CUA ever need to know the UPN of group-A ? 'user' has or does not have permission to modify cal-group-a. Why does the CUA care what the value of the UPN property is that allowd that? Why can't it just work, or you get permission denied? I still don't get it :-) Would it be something like: C: AUTHENTICATE S: 2.0 S: . S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: PRODID:-//ACME/CAPserver//EN S: VERSION:2.1 S: CAPVERSION=1.0 S: ITIPVERSION=1.0 S: AUTH=KERBEROS_V4 S: AUTH=DIGEST_MD5 S: CAR=CAR-FULL-1 S: MINDATE=19700101T000000Z S: MAXDATE=20370201T000000Z ? S: UPN=user ? S: UPN=group-A S: END:VCALENDAR S: . --------------552B1587607A481F60CD95DD Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------552B1587607A481F60CD95DD-- From owner-ietf-calendar@imc.org Sun Feb 27 14:14:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10455 for ; Sun, 27 Feb 2000 14:14:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15927 for ietf-calendar-bks; Sun, 27 Feb 2000 11:02:46 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15923 for ; Sun, 27 Feb 2000 11:02:45 -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 LAA20974; Sun, 27 Feb 2000 11:02:32 -0800 (PST) Message-ID: <38B974C8.7330AFAF@home.royer.com> Date: Sun, 27 Feb 2000 11:02:32 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Richard Shusterman CC: Bruce_Kahn@iris.com, ietf-calendar@imc.org Subject: Re: Groups revisited References: <38B43E90.276880C4@netscape.com> Content-Type: multipart/mixed; boundary="------------6174F82C93BE6E71A1BAEAEE" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6174F82C93BE6E71A1BAEAEE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >> The CS _really_ should keep all the UPNs that are spat out for VCAR >> comparison, etc. That way, if there is a VCAR on a paricular event >> in the calendar that has a VCAR that only allows >> CAPEditors@calsched.apps.ietf.org to read or edit it then Frank should >> be able to access that entry. Just because Franks "primary" (ugh, for lack >> of a better description so do not take literally) UPN is >> Frank_Dawson@lotus.com does not mean that he has to do nasty things >> like switching identities to be able to access an entry that does have >> CAPEditors@calsched.apps.ietf.org on the VCAR. The CS should do >> this equivalence for him! > I agree. That's why we also agreed in Boston to remove the IDENTIFY > command (which somehow still lives in the CAP draft - I will ask the > editors to remove it) since it's not needed. I have seen NO meeting notes that suggest this. And I have not seen this topic discussed on this WG. IDENTIFY is still in the CAP draft. How do you act on behaif of someone? That was the purpose of IDENTIFY. I had said in the past that you set the SEND-BY paramater in the ORGANIZER property. Is that how you do it? I understand the text for which you replied, but IDENTIFY had another purpose. And that was (I am Doug, doing this for Steve). So are you saying, I login as Doug and get back UPN:Doug and UPN:Steve? What if I want to access Steve's calendar, whois UPN do I use? How do I specifiy it at run time? If I use UPN:Doug then there would be an VCAR that allows UPN:Doug some access. If I use UPN:Steve then how would it know that I was not Steve and grant me more permission than Steve wanted? If I do not use UPN:Steve, then why do I get it back? -Doug --------------6174F82C93BE6E71A1BAEAEE Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------6174F82C93BE6E71A1BAEAEE-- From owner-ietf-calendar@imc.org Sun Feb 27 14:31:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10544 for ; Sun, 27 Feb 2000 14:31:01 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA16044 for ietf-calendar-bks; Sun, 27 Feb 2000 11:18:30 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16040 for ; Sun, 27 Feb 2000 11:18:29 -0800 (PST) Received: from home.royer.com (home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id LAA20986; Sun, 27 Feb 2000 11:18:19 -0800 (PST) Message-ID: <38B9787A.D57BFF52@home.royer.com> Date: Sun, 27 Feb 2000 11:18:18 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: David.Madeo@msdw.com CC: IETF CALSCH WG Subject: Re: Latest in-process draft References: <38B03BEE.73496282@home.royer.com> <38B18E70.B4992814@netscape.com> <38B1AB9E.E8BEC3F3@home.royer.com> <38B2C341.C6BA253D@msdw.com> Content-Type: multipart/mixed; boundary="------------39DD7C88C9101426849C9D6C" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------39DD7C88C9101426849C9D6C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Madeo wrote: > > Doug Royer wrote: > > > > Richard Shusterman wrote: > > > > > > Doug, > > > > > > I quickly scanned this draft and did not see any of the text that was generated > > > at the Boston meeting and sent to this list included in this latest draft. Can > > > you please update this draft with that text. I realize there are some discussions > > > that still need to be made around some of this text but a number of us did spend > > > 2 full days working on this text AND I didn't see any major objections to it's > > > inclusion. If you need me to point you to emails with the relevant text, I can do > > > that. > > > > As steve pointed out it is in the works. > > > > Also, I still do not understand some of the text as I still have unanswered > > questions that I have posted. In summary (with respect to trying to generate > > a VCAR for an anonymous UPN): > > > > Anonymous - looked ambiguous in the text. What is an anonymous UPN? > > Anonymous from any domain or any @specifc-domain. I could not tell which. > > A totally anonymous UPN is "@". It may be possible to authenticate > using a SASL method, but obtain the "domain anonymous" UPN such as > "@example.com". This means you can be identified as someone from > example.com, but we're not sure which person. How does a CAP CUA 'obtain' it over the wire? > It's important to distinguish between UPN's and ACL pattern matches. > ACL's currently require a UPN. We've also discussed putting pattern > matches into ACL rules as well as definitive UPN's. So I may choose to > let "@" see my freebusy time, "@example.com" see certain types of data > and "mybestfriend@example.com" see everything. This translates to > anyone can see my freebusy. Anyone who can authenticate at example.com > can see certain types of data and that specific UPN can see everything. I would be for that. > A simple example: > Using SASL, I can authenticate as me and get my normal UPN > "dmadeo@example.com". Or I could authenticate as me and ask for another > UPN. How does a CAP CUR ask for 'another UPN'? > Whichever authentication method I use can look up to see if I'm > allowed to ask for that particular UPN and either allow or disallow it. With UPNEXPAND I can expand one UPN into multiple. How does a CAP CUA ask to use a particularly UPN? How does a CS or a CAP CUA allow or disallow it (I assume you mean access to use the selected UPN)? > The CU trusts the SASL methods to only give it UPN's that are properly > authorized. I assume 'it' is the CU? Is this via UPNEXPAND? Or as part of the AUTHENTICATE reply? > I ask to see the calendar calid://example.com/a9dfhj23jf > which has an ACL which says "dmadeo@example.com" is an owner. I can > modify the calendar as much as I'd like. I then ask to see > calid://example.com/89jadf77adf which has an ACL saying "@example.com" > has full read access. Because my UPN is "dmadeo@example.com", and the > ACL says "@example.com", I should then have full read access. Okay so that's how you could do wild card matches. How do you use/select another UPN? -Doug --------------39DD7C88C9101426849C9D6C Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------39DD7C88C9101426849C9D6C-- From owner-ietf-calendar@imc.org Sun Feb 27 15:02:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10805 for ; Sun, 27 Feb 2000 15:02:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA16268 for ietf-calendar-bks; Sun, 27 Feb 2000 11:49:47 -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 LAA16264 for ; Sun, 27 Feb 2000 11:49:46 -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 LAA21050; Sun, 27 Feb 2000 11:49:29 -0800 (PST) Message-ID: <38B97FC9.913877C8@home.royer.com> Date: Sun, 27 Feb 2000 11:49:29 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?P=E4r=20Lanner=F6?= CC: ietf-calendar@imc.org, Frank Dawson Subject: Re: GEO question References: Content-Type: multipart/mixed; boundary="------------C9BB767C4E7F955057CDED36" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C9BB767C4E7F955057CDED36 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable P=E4r Lanner=F6 wrote: > = > Hello! > = > We would like to get some more information concerning the GEO > property. In order for us to be able to use the GEO coordinates in a > GIS application we need to know what coordinate system to use. Ie. > what geographic datum, hemisphere, offset etc. The information seems > to be missing in RFC2445 (perhaps it's in the "Federal Information > Processing Standard 70-1, but where do I get _that_?). We need to fix this. FiPS 70-1 is not longer valid. It was withdrawn in 1994. = See: http://www.itl.nist.gov/fipspubs/withdraw.htm http://www.itl.nist.gov/fipspubs/index.htm We need to fix this in iCal-2. --------------C9BB767C4E7F955057CDED36 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------C9BB767C4E7F955057CDED36-- From owner-ietf-calendar@imc.org Sun Feb 27 15:35:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11511 for ; Sun, 27 Feb 2000 15:35:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16416 for ietf-calendar-bks; Sun, 27 Feb 2000 12:13:02 -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 MAA16411 for ; Sun, 27 Feb 2000 12:13:01 -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 MAA21072; Sun, 27 Feb 2000 12:12:49 -0800 (PST) Message-ID: <38B98541.848041AD@home.royer.com> Date: Sun, 27 Feb 2000 12:12:49 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bruce_Kahn@iris.com CC: CalSched IETF Subject: Re: W-19 - open item - can we defer it? References: Content-Type: multipart/mixed; boundary="------------C7A483BF8CD508CB57F9ABFB" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------C7A483BF8CD508CB57F9ABFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >> 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. > If we do not have a very very common feature of current MUAs and non-RFC > 2445 PIMs like groups then we can close up shop and head home. There > would be no acceptance by our end users if we say "Hey, guess what?! We > have this great new standard for Interpersonal C&S but we decided you > cannot have any groups like you do now in your current products." How > many medium and large customers would buy a product like that?? I still think the text as provided does not cose the loops. It just creates more issues. --------------C7A483BF8CD508CB57F9ABFB Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------C7A483BF8CD508CB57F9ABFB-- From owner-ietf-calendar@imc.org Sun Feb 27 15:44:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11552 for ; Sun, 27 Feb 2000 15:44:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16509 for ietf-calendar-bks; Sun, 27 Feb 2000 12:24:15 -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 MAA16505 for ; Sun, 27 Feb 2000 12:24:13 -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 MAA21079; Sun, 27 Feb 2000 12:23:06 -0800 (PST) Message-ID: <38B987A9.49758728@home.royer.com> Date: Sun, 27 Feb 2000 12:23:05 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour CC: Frank Dawson , ietf-calendar@imc.org Subject: Re: POLICY definitions: your input needed References: <389B03AB.4826ABFE@home.royer.com> <389C8BD9.BFB8D0EF@netscape.com> Content-Type: multipart/mixed; boundary="------------0B892FFC393D3776C9ED2A36" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------0B892FFC393D3776C9ED2A36 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI I just removed POLICY from CAP and replaced them with VCAR's. Except: I removed ACTONBEHALF as it had no definition and I did not replace it with a VCAR. And I removed OWNER policy as it had not difference to assigning them as an OWNER and I did not replace it with a VCAR. We can add them back later if we get text. -Doug Steve Mansour wrote: > > Frank (and others), > > We need some clarity on the Policy specification. The only "specification" > I've seen is Doug's earlier message "POLICY in general." > > I don't think there's general concensus on what each of the policies means. > Since we started working on iTIP, I've talked with many folks in this working > group about "policies", and I know we all have slightly different ideas about > certain things. For example, exactly what it means for one user to act on > behalf of another differs a bit between products. > > The choices we have to resolve this, as I see them, are: > > 1. We give each policy a name and define precisely what it means with VCARs > 2. We define a set of policy names and allow clients to query for the VCARs > that describe what they mean > 3. We remove policies completely > > If there's no feedback within a week or two, we'll just remove policies from > the draft. We can add them back if/when we get definitions. > > -Steve > > Doug Royer wrote: > > > Frank_Dawson@lotus.com wrote: > > > > > > Yes, we are in agreement. > > > > > > - C&S VCAR Policy specification by the CU is in the CAP. > > > > As far as POLICY goes. They are -not- really in CAP yet. > > > > Frank - as you are the one that put 'POLICY' in CAP. Do you think > > the VCAR definitions sent out are correct? If not could you please > > explain what those POLICYs mean? > > > > If not - I would suggest we remove them from CAP as as they are currently > > undefined and it would be impossible to create an interoperable CUA or CS > > that knew what to do with them. We could put them back in once they > > have been defined. > > > > Any objections? > > > > -Doug --------------0B892FFC393D3776C9ED2A36 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------0B892FFC393D3776C9ED2A36-- From owner-ietf-calendar@imc.org Sun Feb 27 15:45:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11566 for ; Sun, 27 Feb 2000 15:45:31 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16597 for ietf-calendar-bks; Sun, 27 Feb 2000 12:34:36 -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 MAA16593 for ; Sun, 27 Feb 2000 12:34:35 -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 MAA21109; Sun, 27 Feb 2000 12:34:26 -0800 (PST) Message-ID: <38B98A51.C6C8D3A2@home.royer.com> Date: Sun, 27 Feb 2000 12:34:25 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Doug Royer CC: ietf-calendar@imc.org Subject: Re: CAP draft notes References: <200002031924.LAA05398@royer.com> Content-Type: multipart/mixed; boundary="------------8770FB194EE4BF4C9932C75E" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8770FB194EE4BF4C9932C75E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Two things we need to fix in the CAP draft. > > 1) We have 2 ways to do wildcard '*' and 'all'. As in UPN=all and > OBJECT=* > > I would suggest we use * everywhere to mean all. Any objections? > > 2) 'rightsparam' is never defined, but used to define 'GRANT' and 'DENY' ABNF. > > I'll fix this to point to the correct ABNF already in CAP. Done - will go out today or tomorrow. --------------8770FB194EE4BF4C9932C75E Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------8770FB194EE4BF4C9932C75E-- From owner-ietf-calendar@imc.org Sun Feb 27 15:52:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11625 for ; Sun, 27 Feb 2000 15:52:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16642 for ietf-calendar-bks; Sun, 27 Feb 2000 12:41:32 -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 MAA16638 for ; Sun, 27 Feb 2000 12:41:31 -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 MAA21126 for ; Sun, 27 Feb 2000 12:41:24 -0800 (PST) Message-ID: <38B98BF3.C273CE49@home.royer.com> Date: Sun, 27 Feb 2000 12:41:23 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: Small typo in UPN text? Content-Type: multipart/mixed; boundary="------------04D578829CD6A3DCF12F2B7E" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------04D578829CD6A3DCF12F2B7E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In: 2.5.1. UPNs and Certificates Note: If a server is validating data received via iMIP, if the "ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe Random :juser@example.com" then the "juser@example.com" part should be checked against the altSubjectName field of the certificate, and the "Joe Random User" part should be checked against the CN component of the altSubjectName DN. This is so the "ATTENDEE" property couldn't be munged to something misleading like "ATTENDEE;CN=Joe Rictus juser@example.com" and have it pass validation. This validation will also defeat other attempts at confusion. Had the ATTENDEE line had "User:" in the ATTENDEE lines: "ATTENDEE;CN=Joe Random:User:juser@example.com" "User:Joe Random User" As "User:" is not part of ATTENDEE, I assumed that was a typo and I removed "User:". -Doug --------------04D578829CD6A3DCF12F2B7E Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------04D578829CD6A3DCF12F2B7E-- From owner-ietf-calendar@imc.org Sun Feb 27 16:01:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11742 for ; Sun, 27 Feb 2000 16:01:47 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16711 for ietf-calendar-bks; Sun, 27 Feb 2000 12:48:36 -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 MAA16707 for ; Sun, 27 Feb 2000 12:48:36 -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 MAA17327 for ; Sun, 27 Feb 2000 12:48:24 -0800 (PST) Received: from 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 UAA24999 for ; Sun, 27 Feb 2000 20:48:23 GMT Message-ID: <38B98D97.265B5546@sun.com> Date: Sun, 27 Feb 2000 20:48:23 +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: RFC 2445: "=" char is delimiter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All, There are few quotation from RFC 2445: >4.1 Content Lines ... > contentline = name *(";" param ) ":" value CRLF ... > param = param-name "=" param-value ... > param-value = paramtext / quoted-string > paramtext = *SAFE-CHAR ... > SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E > / NON-US-ASCII > ; Any character except CTLs, DQUOTE, ";", ":", "," As far as I can see, the "=" (%x3D) used as a delimiter in 'param' rule and included in 'SAFE-CHAR' list at the same time. Does it sound strange to anybody here except me? Michael -- --------------------------------------------------------------- Michael Krivoruchko CDE Group, Sun Microsystems Bool House, East Point Business Park, Dublin 3, Ireland Ph: +353 1 819 9272 E-mail: misha@sun.com --------------------------------------------------------------- From owner-ietf-calendar@imc.org Sun Feb 27 16:51:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12100 for ; Sun, 27 Feb 2000 16:51:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA17125 for ietf-calendar-bks; Sun, 27 Feb 2000 13:38:20 -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 NAA17121 for ; Sun, 27 Feb 2000 13:38:19 -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 NAA21167; Sun, 27 Feb 2000 13:38:09 -0800 (PST) Message-ID: <38B99941.EE24115@home.royer.com> Date: Sun, 27 Feb 2000 13:38:09 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michael Krivoruchko CC: ietf-calendar@imc.org Subject: Re: RFC 2445: "=" char is delimiter References: <38B98D97.265B5546@sun.com> Content-Type: multipart/mixed; boundary="------------68EBAA3745BC4567F55FFBF6" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------68EBAA3745BC4567F55FFBF6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Krivoruchko wrote: > > Hi All, > > There are few quotation from RFC 2445: > > >4.1 Content Lines > ... > > contentline = name *(";" param ) ":" value CRLF > ... > > param = param-name "=" param-value > ... > > param-value = paramtext / quoted-string > > paramtext = *SAFE-CHAR > ... > > SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E > > / NON-US-ASCII > > ; Any character except CTLs, DQUOTE, ";", ":", "," > > As far as I can see, the "=" (%x3D) used as a delimiter in 'param' > rule and included in 'SAFE-CHAR' list at the same time. > > Does it sound strange to anybody here except me? DTSTART;x-foo-param=key=value;VALUE=DATE;TZID=US/Eastern:19950603 Why not? -Doug --------------68EBAA3745BC4567F55FFBF6 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------68EBAA3745BC4567F55FFBF6-- From owner-ietf-calendar@imc.org Sun Feb 27 17:09:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12224 for ; Sun, 27 Feb 2000 17:09:13 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA17285 for ietf-calendar-bks; Sun, 27 Feb 2000 13:54:03 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17280 for ; Sun, 27 Feb 2000 13:54:01 -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 NAA21179 for ; Sun, 27 Feb 2000 13:53:54 -0800 (PST) Message-ID: <38B99CF2.677009B4@home.royer.com> Date: Sun, 27 Feb 2000 13:53:54 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: POLICY in general. References: <3890F6EE.D3D2363D@home.royer.com> Content-Type: multipart/mixed; boundary="------------1B6F178B0D267C8B57D7DE70" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1B6F178B0D267C8B57D7DE70 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just put this in CAP + a tweak or two the the ABNF to make it work. Doug Royer wrote: > > Originally the discussions surrounding POLICY it was started when some said > they wanted a simplified access rules for thinner CS's. > > Now we can have a compatibility problem if we do not map from > one model into another. So if we keep POLICY, it is time now > to define them, or drop them and only use VCARs. And I think > we can drop them and specify a minimum set of VCARs that > a CS MUST support. And report that set with CAPABILITY. > > Will call this minimum set 'CAR-MIN'. > > Can a CS support POLICY only? Not from reading the cap-draft-text. > It does not state that anywhere and the ABNF implies both MUST be > supported. It looks like all CS's must support POLICY and > non-POLICY VCAR's. However from hallway conversations, I think > others will have strong opinions on this ... > > ... if so SPEAK UP NOW! > > (1) READBUSYTIMEINFO - Specifies rights for reading busy time data. > > As I have pointed out in previous email, I think we can eliminate > this entirely. (See CAPABILITY below also). > > Example: > > replace: > BEGIN:VCAR > CARID:name > GRANT:UPN=<...>;POLICY=READBUSYTIMEINFO > END:VCAR > > With: > > BEGIN:VCAR > CARID:READBUSYTIMEINFO > GRANT:UPN=<...>;OBJECT=VFREEBUSY;ACTION=READ > DENY:UPN=<...>;OBJECT=VFREEBUSY;ACTION=READ > END:VCAR > > (or OBJECT=VFREEBUSY,DTSTART,DTEND,DURATION if the WG > wants READBUSYTIMEINFO to mean that). > > (2) REQUESTONLY - Specifies rights for creating new event invitations, to-do > assignments and journal entries. > > As we are going to have to define what this means, then we can > simply define in in terms of a VCAR and eliminate this as a POLICY. > > It could be (assuming I understand what the intent was): > > BEGIN:VCAR > CARID:REQUESTONLY > GRANT:UPN=<...>;OBJECT=ALL;ACTION=CREATE; > END:VCAR > > (3) ACTONBEHALFOF - Specifies rights for any CAP function taken on > PUBLIC or PRIVATE calendar components. However, no CAP function > can be taken on CONFIDENTIAL classified calendar components. > > As we are going to have to define what this means, then we can > simply define in in terms of a VCAR and eliminate this as a POLICY. > > Perhaps: > > BEGIN:VCAR > CARID:ACTONBEHALFOF > GRANT:UPN=<...> > ;OBJECT=ORGANIZER;VALUE= > ;OBJECT=SENT-BY;VALUE=SELF > ;OBJECT=CLASS;VALUE=PUBLIC,PRIVATE > ;ACTION=ALL > END:VCAR > > ++In addition, 'self' probably would have to have CREATE, MODIFY, DELETE, > permission in the target calendar. > > (4) UPDATEPARTSTATUS - Specifies rights for modifying ones own > participation status. > > Perhaps: > > BEGIN:VCAR > CARID:UPDATESTATUS > GRANT:UPN=<...> > ;OBJECT=PARTSTAT;VALUE=ALL > ;OBJECT=ATTENDEE;VALUE=SELF > ;ACTION=MODIFY > END:VCAR > > (5) OWNER - Specifies the same rights given to the owner of the calendar > store or calendar. > > Make them an OWNER by adding their OWNER property to the calendar properly > list. > And then: > > BEGIN:VCAR > CARID:OWNER > GRANT:UPN=OWNER;OBJECT=ALL;VALUE=ALL;ACTION=ALL > END:VCAR > > (6) CAPABILITY reply. > > In the current CAP draft in the ABNF it has CAR0, CAR1, CAR2, and CAR3. > This needs to be changed to CAR-MIN, and CAR-FULL-1 > > Define CAR-MIN as the above definitions (Or what ever tweaks the > WG makes to the above definitions). > > If CAR-MIN is returned by CAPABILITY, then ONLY the ones defined above > are supported. They can be hard coded into a CS (plus storage for > which UPNs they apply to), or parsed. Ether way I think this would > solve both problems (thin CS's and a complete IF supported VCAR). > > If CAR-FULL-1 is returned by CAPABILITY, then all of the VCAR support > MUST be supported. > > Only one of CAR-MIN or CAR-FULL-1 can be returned by CAPABILITY. --------------1B6F178B0D267C8B57D7DE70 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------1B6F178B0D267C8B57D7DE70-- From owner-ietf-calendar@imc.org Sun Feb 27 17:36:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12407 for ; Sun, 27 Feb 2000 17:36:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17618 for ietf-calendar-bks; Sun, 27 Feb 2000 14:24:25 -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 OAA17614 for ; Sun, 27 Feb 2000 14:24:24 -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 OAA25299; Sun, 27 Feb 2000 14:24:16 -0800 (PST) Received: from 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 WAA00654; Sun, 27 Feb 2000 22:24:15 GMT Message-ID: <38B9A40F.61D7A807@sun.com> Date: Sun, 27 Feb 2000 22:24:15 +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: Doug@royer.com CC: ietf-calendar@imc.org Subject: Re: RFC 2445: "=" char is delimiter References: <38B98D97.265B5546@sun.com> <38B99941.EE24115@home.royer.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > > There are few quotation from RFC 2445: > > > > >4.1 Content Lines > > ... > > > contentline = name *(";" param ) ":" value CRLF > > ... > > > param = param-name "=" param-value > > ... > > > param-value = paramtext / quoted-string > > > paramtext = *SAFE-CHAR > > ... > > > SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E > > > / NON-US-ASCII > > > ; Any character except CTLs, DQUOTE, ";", ":", "," > > > > As far as I can see, the "=" (%x3D) used as a delimiter in 'param' > > rule and included in 'SAFE-CHAR' list at the same time. > > > > Does it sound strange to anybody here except me? > > DTSTART;x-foo-param=key=value;VALUE=DATE;TZID=US/Eastern:19950603 > > Why not? > I did not say: It is impossible to imagine "=" within a parameter value. I agree. It _is_ possible. But I think the parameter value which contains "=" (as one of the delimiters) has to appear in the 'quoted-string': DTSTART;x-foo-param="key=value";VALUE=DATE;TZID=US/Eastern:19950603 It is, actually, implementation issue, but in the example above the lexer need not "to know" the context of parsing. Michael -- --------------------------------------------------------------- Michael Krivoruchko CDE Group, Sun Microsystems Bool House, East Point Business Park, Dublin 3, Ireland Ph: +353 1 819 9272 E-mail: misha@sun.com --------------------------------------------------------------- From owner-ietf-calendar@imc.org Sun Feb 27 17:41:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12433 for ; Sun, 27 Feb 2000 17:41:05 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17675 for ietf-calendar-bks; Sun, 27 Feb 2000 14:29:19 -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 OAA17671 for ; Sun, 27 Feb 2000 14:29:18 -0800 (PST) Received: from home.royer.com (home.royer.com [63.195.80.50]) by royer.com (8.9.1/8.9.1) with SMTP id OAA23267; Sun, 27 Feb 2000 14:29:07 -0800 (PST) Message-Id: <200002272229.OAA23267@royer.com> Date: Sun, 27 Feb 2000 14:29:07 -0800 (PST) From: Doug Royer Reply-To: Doug Royer Subject: Re: RFC 2445: "=" char is delimiter To: Doug@royer.com, misha@Sun.COM Cc: ietf-calendar@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JgJR2beJLiBAaCxuDH2wKA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Date: Sun, 27 Feb 2000 22:24:15 +0000 > From: Michael Krivoruchko > > > > As far as I can see, the "=" (%x3D) used as a delimiter in 'param' > > > rule and included in 'SAFE-CHAR' list at the same time. > > > > > > Does it sound strange to anybody here except me? > > > > DTSTART;x-foo-param=key=value;VALUE=DATE;TZID=US/Eastern:19950603 > > > > Why not? > > > I did not say: It is impossible to imagine "=" within a parameter > value. I agree. It _is_ possible. But I think the parameter value > which contains "=" (as one of the delimiters) has to appear in > the 'quoted-string': No need unless there is a ':' or ';' in the string. > DTSTART;x-foo-param="key=value";VALUE=DATE;TZID=US/Eastern:19950603 > > It is, actually, implementation issue, but in the example above the > lexer need not "to know" the context of parsing. It ends when a ':' or ';' is found. If you wrap it with a "", then you just have to do more work. Its determinable both ways. -Doug ------------------------------------------------------------------- Doug@Royer.COM http://royer.com/People/Doug Text Pager: pager@Royer.com 801 W. El Camino #131 Mountain View, CA 94040 Ham Radio: N6AAW, Aviation: PP-ASEL From owner-ietf-calendar@imc.org Sun Feb 27 18:53:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12917 for ; Sun, 27 Feb 2000 18:53:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA18381 for ietf-calendar-bks; Sun, 27 Feb 2000 15:36:11 -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 PAA18377 for ; Sun, 27 Feb 2000 15:36:10 -0800 (PST) Received: from home.royer.com (home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id PAA21265 for ; Sun, 27 Feb 2000 15:36:02 -0800 (PST) Message-ID: <38B9B4E2.B2A40864@home.royer.com> Date: Sun, 27 Feb 2000 15:36:02 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: DEFAULT_VCAR Content-Type: multipart/mixed; boundary="------------4B92055DE256A90C2338F6C8" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4B92055DE256A90C2338F6C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The DEFAULT_VCAR Calendar Property (12.2) only allows for one VCAR. Unless there are objects, I'll change it be multi value. As it can be impossible to specify a single VCAR for all needs. I am going to change the name from DEFAULT_VAR to DEFAULT_VCARS. I have also added what I think are the minimum VCARs needed (CAR-MIN): Predefined calendar access CARIDs that MUST be implemented (CAR-MIN) are below. What they contain is up to an implementation or administrator. CARID:READBUSYTIMEINFO - Specifies rights for reading VFREEBUSY components by anonymous and known users. Suggested VCAR to allow all users to read VFREEBUSY components: BEGIN:VCAR CARID:READBUSYTIMEINFO GRANT:UPN=*;ACTION=READ;OBJECTS=VFREEBUSY;VALUE=* END:VCAR CARID:REQUESTONLY - Specifies rights for creating new event invitations (REQUEST), to-do assignments and journal entries by users other than the owner of the calendar. Suggested VCAR to allow access by nonowners to submit REQUESTs: BEGIN:VCAR CARID:REQUESTONLY GRANT:UPN=NONOWNER;ACTION=CREATE;OBJECT=* ;OBJECT=METHOD;VALUE=REQUEST END:VCAR CARID:UPDATEPARTSTATUS - Specifies rights for a user to modify their participation status in a calendar they do not own. Suggested VCAR to allow users to update their own participation status: BEGIN:VCAR CARID:UPDATEPARTSTATUS GRANT:UPN=*;ACTION=MODIFY ;OBECT=PARTSTAT:VALUE=* ;OBJECT=ATTENDEE;VALUE=SELF END:VCAR CARID:DEFAULTOWNER - Specifies the default access for any owner of a calendar. Suggested VCAR to all owners access to their own calendars: BEGIN:VCAR CARID:DEFAULTOWNER GRANT:UPN=OWNER;ACTION=*;OBJECT=*;VALUE=*; END:VCAR --------------4B92055DE256A90C2338F6C8 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------4B92055DE256A90C2338F6C8-- From owner-ietf-calendar@imc.org Sun Feb 27 19:40:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13301 for ; Sun, 27 Feb 2000 19:40:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18997 for ietf-calendar-bks; Sun, 27 Feb 2000 16:29:25 -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 QAA18993 for ; Sun, 27 Feb 2000 16:29:24 -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 QAA21330 for ; Sun, 27 Feb 2000 16:29:13 -0800 (PST) Message-ID: <38B9C159.A3AA9685@home.royer.com> Date: Sun, 27 Feb 2000 16:29:13 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: 2.10. VCalendar Access Rights (VCARs) Content-Type: multipart/mixed; boundary="------------F3CCECF764D74E721B9427C2" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F3CCECF764D74E721B9427C2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit When section "2.10. VCalendar Access Rights (VCARs)" Says: VCAR principals can be CU or UG UPNs. Whenever VCARs are evaluated, all referenced User Groups MUST be evaluated as an expanded list. I am confused. They should be evaluated as both a group UPN, then a expanded list - correct? Otherwise group-UPNs will never work in VCARs as the non-expanded group name would not be evaluated. -Doug --------------F3CCECF764D74E721B9427C2 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------F3CCECF764D74E721B9427C2-- From owner-ietf-calendar@imc.org Sun Feb 27 20:01:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13651 for ; Sun, 27 Feb 2000 20:01:24 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA19125 for ietf-calendar-bks; Sun, 27 Feb 2000 16:41:58 -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 QAA19121 for ; Sun, 27 Feb 2000 16:41:57 -0800 (PST) Received: from home.royer.com (home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id QAA21340 for ; Sun, 27 Feb 2000 16:41:46 -0800 (PST) Message-ID: <38B9C44A.C42AF833@home.royer.com> Date: Sun, 27 Feb 2000 16:41:46 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: 5.1. Searching and Filtering Content-Type: multipart/mixed; boundary="------------79AFF75E576DA68770E98429" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------79AFF75E576DA68770E98429 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In "5.1. Searching and Filtering" it says: Examples needed: Grant someone access to June events Grant someone access to events during the month of June. (i.e., based on the current system date, if it's prior to June or after June you don't have access) There have not been any such requirements for VCAR by date range. I think they could be added. Unless someone objects, I am going to remove this note. -Doug --------------79AFF75E576DA68770E98429 Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------79AFF75E576DA68770E98429-- From owner-ietf-calendar@imc.org Sun Feb 27 20:09:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13926 for ; Sun, 27 Feb 2000 20:09:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA19307 for ietf-calendar-bks; Sun, 27 Feb 2000 16:54:06 -0800 (PST) Received: from home.royer.com (adsl-63-195-80-50.dsl.snfc21.pacbell.net [63.195.80.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19303 for ; Sun, 27 Feb 2000 16:54:04 -0800 (PST) Received: from home.royer.com (home.royer.com [192.168.168.10]) by home.royer.com (8.9.1/8.9.1) with ESMTP id QAA21350 for ; Sun, 27 Feb 2000 16:53:58 -0800 (PST) Message-ID: <38B9C725.396A3F2@home.royer.com> Date: Sun, 27 Feb 2000 16:53:57 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: Confusing Content-Type: multipart/mixed; boundary="------------2DC56877B5199DC92532B83C" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------2DC56877B5199DC92532B83C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 4.3. Response Format Server responses consist of a response code and any parameters: [response args] [; debug text ; more text] . [] . In section "7. Commands and Responses": Responses to commands have the following general form: responseCode [sep transportDescr sep [applicationDescr]] CRLF "." CRLF -Doug --------------2DC56877B5199DC92532B83C Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------2DC56877B5199DC92532B83C-- From owner-ietf-calendar@imc.org Sun Feb 27 20:36:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14589 for ; Sun, 27 Feb 2000 20:36:52 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19614 for ietf-calendar-bks; Sun, 27 Feb 2000 17:23:37 -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 RAA19607 for ; Sun, 27 Feb 2000 17:23:36 -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 RAA21380 for ; Sun, 27 Feb 2000 17:23:29 -0800 (PST) Message-ID: <38B9CE11.B6635321@home.royer.com> Date: Sun, 27 Feb 2000 17:23:29 -0800 From: Doug Royer Reply-To: Doug@royer.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: AUTH method and MUST's Content-Type: multipart/mixed; boundary="------------F793F120FD9DE70D1AF1414F" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F793F120FD9DE70D1AF1414F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 7.1.3. AUTHENTICATE Command is a registered SASL authentication mechanism. (Refer to [SASL] for information on obtaining a list of currently registered mechanisms.) CS Supported authentication mechanisms can be discovered using the CAPABILITY command. All implementations MUST support Digest-MD5 authentication using DES and 3DES, as well as DES-56 for link level encryption. Implementations MUST support the SASL Anonymous mechanism, although this may be disabled in installations. Implementations SHOULD implement the External SASL mechanism and the command STARTTLS. 1) Is DES-56 the TLS encryption? If yes - why is it a MUST and STARTTLS a SHOULD? I would think they both are SHOULDs? 2) What ANONYMOUS SASL mechanism? I thought it expired? If there is one, lets state what it is in CAP. -Doug --------------F793F120FD9DE70D1AF1414F Content-Type: text/x-vcard; charset=us-ascii; name="doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:650-274-8960 or pager@Royer.com tel;cell:650-274-8960 tel;home:650-274-8960 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug version:2.1 email;internet:doug@home.royer.com adr;quoted-printable:;;801 Woodside Rd. #14=0D=0ASuite 244;Redwood City;CA;94061;USA x-mozilla-cpt:;0 fn:Doug Royer end:vcard --------------F793F120FD9DE70D1AF1414F-- From owner-ietf-calendar@imc.org Sun Feb 27 23:31:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17762 for ; Sun, 27 Feb 2000 23:31:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA29698 for ietf-calendar-bks; Sun, 27 Feb 2000 20:01:40 -0800 (PST) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA29694 for ; Sun, 27 Feb 2000 20:01:38 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id XAA04659; Sun, 27 Feb 2000 23:01:18 -0500 (EST) Date: Sun, 27 Feb 2000 23:01:18 -0500 (EST) Message-Id: <200002280401.XAA04659@smtp1.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: IETF CALSCH WG Cc: Doug@royer.com In-reply-to: <38B9CE11.B6635321@home.royer.com> Subject: Re: AUTH method and MUST's References: <38B9CE11.B6635321@home.royer.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is speaking as someone who has participated in implementing multiple SASL mechanisms, but I'm not familiar with any calendar work. (In fact, I haven't even read the draft except for what is being quoted.) 7.1.3. AUTHENTICATE Command is a registered SASL authentication mechanism. (Refer to [SASL] for information on obtaining a list of currently registered mechanisms.) CS Supported authentication mechanisms can be discovered using the CAPABILITY command. All implementations MUST support Digest-MD5 authentication using DES and 3DES, as well as DES-56 for link level encryption. Implementations MUST support the SASL Anonymous mechanism, although this may be disabled in installations. Implementations SHOULD implement the External SASL mechanism and the command STARTTLS. The sentence "All implementations MUST support Digest-MD5 authentication using DES and 3DES" makes no sense; DIGEST-MD5 uses MD5 for its authentication security, not DES. It's possible to implement DIGEST-MD5 without any DES implementation---in fact, the Cyrus SASL library can be compiled without any encryption support. 1) Is DES-56 the TLS encryption? If yes - why is it a MUST and STARTTLS a SHOULD? I would think they both are SHOULDs? DIGEST-MD5 supports both integrity and privacy SASL layers. This operates at a different level from TLS. The base DIGEST spec supports DES, 3DES, and three different modes of RC4. It would be possible for a connection to run STARTTLS, and then do a DIGEST authentication and negotiate _another_ encryption layer (though it would be somewhat silly, and a server could disallow it). Implementing DIGEST-MD5 with encryption layer support is somewhat easier (and more lightweight) than implementing the public key operations required by STARTTLS, thus the rational for requiring DIGEST-MD5 encryption support but not STARTTLS support. 2) What ANONYMOUS SASL mechanism? I thought it expired? RFC 2245, C. Newman, Innosoft. Larry From owner-ietf-calendar@imc.org Mon Feb 28 00:13:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18085 for ; Mon, 28 Feb 2000 00:13:27 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA02424 for ietf-calendar-bks; Sun, 27 Feb 2000 20:54:46 -0800 (PST) Received: from egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA02419; Sun, 27 Feb 2000 20:54:43 -0800 (PST) From: pregen@egenconsulting.com To: Lawrence Greenfield Cc: Doug@royer.com, ietf-calendar@imc.org, owner-ietf-calendar@imc.org Subject: Re: AUTH method and MUST's X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-ID: Date: Sun, 27 Feb 2000 23:54:34 -0500 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.1a|August 17, 1999) at 02/27/2000 11:54:37 PM, Serialize complete at 02/27/2000 11:54:37 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 001AD5BE85256893_=" Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 001AD5BE85256893_= Content-Type: text/plain; charset="us-ascii" This may sound like a dumb question, but is DES-MD5 (which I believe is also called CRAM-MD5??) in use in corporations and companies. I know that Kerberos is an issue and is not in wide a use as we may like. Does this security requirement ensure that we will have softtware companies who can build tools that can interoperate. Does it ensure we will have corporations and companies capable of running those productgs. I know security is key - being a former administrator and Director of security, it's what I look at first. It seems like this security piece could end up being a show-stopper. Am I wrong? Can someone make me comfortable that if we set this security rule, we will have companies implement this draft?? ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Lawrence Greenfield Sent by: owner-ietf-calendar@imc.org 02/27/00 11:01 PM To: IETF CALSCH WG cc: Doug@royer.com Subject: Re: AUTH method and MUST's This is speaking as someone who has participated in implementing multiple SASL mechanisms, but I'm not familiar with any calendar work. (In fact, I haven't even read the draft except for what is being quoted.) 7.1.3. AUTHENTICATE Command is a registered SASL authentication mechanism. (Refer to [SASL] for information on obtaining a list of currently registered mechanisms.) CS Supported authentication mechanisms can be discovered using the CAPABILITY command. All implementations MUST support Digest-MD5 authentication using DES and 3DES, as well as DES-56 for link level encryption. Implementations MUST support the SASL Anonymous mechanism, although this may be disabled in installations. Implementations SHOULD implement the External SASL mechanism and the command STARTTLS. The sentence "All implementations MUST support Digest-MD5 authentication using DES and 3DES" makes no sense; DIGEST-MD5 uses MD5 for its authentication security, not DES. It's possible to implement DIGEST-MD5 without any DES implementation---in fact, the Cyrus SASL library can be compiled without any encryption support. 1) Is DES-56 the TLS encryption? If yes - why is it a MUST and STARTTLS a SHOULD? I would think they both are SHOULDs? DIGEST-MD5 supports both integrity and privacy SASL layers. This operates at a different level from TLS. The base DIGEST spec supports DES, 3DES, and three different modes of RC4. It would be possible for a connection to run STARTTLS, and then do a DIGEST authentication and negotiate _another_ encryption layer (though it would be somewhat silly, and a server could disallow it). Implementing DIGEST-MD5 with encryption layer support is somewhat easier (and more lightweight) than implementing the public key operations required by STARTTLS, thus the rational for requiring DIGEST-MD5 encryption support but not STARTTLS support. 2) What ANONYMOUS SASL mechanism? I thought it expired? RFC 2245, C. Newman, Innosoft. Larry --=_alternative 001AD5BE85256893_= Content-Type: text/html; charset="us-ascii"
This may sound like a dumb question, but is DES-MD5 (which I believe is also called CRAM-MD5??) in use in corporations and companies.  I know that Kerberos is an issue and is not in wide a use as we may like.  Does this security requirement ensure that we will have softtware companies who can build tools that can interoperate.  Does it ensure we will have corporations and companies capable of running those productgs.  I know security is key - being a former administrator and Director of security, it's what I look at first.  It seems like this security piece could end up being a show-stopper.  Am I wrong? Can someone make me comfortable that if we set this security rule, we will have companies implement this draft??
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Lawrence Greenfield <leg+@andrew.cmu.edu>
Sent by: owner-ietf-calendar@imc.org

02/27/00 11:01 PM

       
        To:        IETF CALSCH WG <ietf-calendar@imc.org>
        cc:        Doug@royer.com
        Subject:        Re: AUTH method and MUST's


This is speaking as someone who has participated in implementing
multiple SASL mechanisms, but I'm not familiar with any calendar
work.  (In fact, I haven't even read the draft except for what is
being quoted.)

  7.1.3.  AUTHENTICATE Command

     <SASL mechanism name> is a registered SASL authentication mechanism.
     (Refer to [SASL] for information on obtaining a list of currently
     registered mechanisms.) CS Supported authentication mechanisms can be
     discovered using the CAPABILITY command. All implementations MUST
     support Digest-MD5 authentication using DES and 3DES, as well as DES-56
     for link level encryption. Implementations MUST support the SASL
     Anonymous mechanism, although this may be disabled in installations.
     Implementations SHOULD implement the External SASL mechanism and the
     command STARTTLS.

The sentence "All implementations MUST support Digest-MD5
authentication using DES and 3DES" makes no sense; DIGEST-MD5 uses MD5
for its authentication security, not DES.  It's possible to implement
DIGEST-MD5 without any DES implementation---in fact, the Cyrus SASL
library can be compiled without any encryption support.

  1) Is DES-56 the TLS encryption?

     If yes - why is it a MUST and STARTTLS a SHOULD? I would think
     they both are SHOULDs?

DIGEST-MD5 supports both integrity and privacy SASL layers.  This
operates at a different level from TLS.  The base DIGEST spec supports
DES, 3DES, and three different modes of RC4.  It would be possible for
a connection to run STARTTLS, and then do a DIGEST authentication and
negotiate _another_ encryption layer (though it would be somewhat
silly, and a server could disallow it).

Implementing DIGEST-MD5 with encryption layer support is somewhat
easier (and more lightweight) than implementing the public key
operations required by STARTTLS, thus the rational for requiring
DIGEST-MD5 encryption support but not STARTTLS support.

  2) What ANONYMOUS SASL mechanism? I thought it expired?

RFC 2245, C. Newman, Innosoft.

Larry

--=_alternative 001AD5BE85256893_=-- From owner-ietf-calendar@imc.org Mon Feb 28 11:12:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13006 for ; Mon, 28 Feb 2000 11:12:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA14636 for ietf-calendar-bks; Mon, 28 Feb 2000 07:49:09 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14632 for ; Mon, 28 Feb 2000 07:49:08 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA09350 for ; Mon, 28 Feb 2000 10:49:44 -0500 Message-ID: <38BA9916.2A198013@ecal.com> Date: Mon, 28 Feb 2000 10:49:43 -0500 From: John Stracke X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: Re: AUTH method and MUST's References: <38B9CE11.B6635321@home.royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > 7.1.3. AUTHENTICATE Command > [...] > Implementations MUST support the SASL > Anonymous mechanism, although this may be disabled in installations. I'm not comfortable with this requirement. The purpose of a standard is to ensure interop. From the interop point of view, there is no difference between a disabled feature and an unimplemented one; if it's safe to disable it, it's safe not to implement it. Safer, in fact, because the only guaranteed bug-free feature is the one you don't implement. :-) -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |No matter how tempting the prospect of unlimited| |francis@ecal.com|power, I will not consume any energy field | | |bigger than my head. | \=================================================================/ From owner-ietf-calendar@imc.org Mon Feb 28 12:07:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14815 for ; Mon, 28 Feb 2000 12:07:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16345 for ietf-calendar-bks; Mon, 28 Feb 2000 08:47:38 -0800 (PST) Received: from pivsbh1.ms.com (pivsbh1.ms.com [199.89.64.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16341 for ; Mon, 28 Feb 2000 08:47:37 -0800 (PST) Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/fw v1.30) id LAA18822; Mon, 28 Feb 2000 11:47:25 -0500 (EST) Received: from localhost(127.0.0.1) by pivsbh1 via smap (4.1) id sma.9517564291.018469; Mon, 28 Feb 00 11:47:09 -0500 Received: (from uucp@localhost) by pivsbh1.ms.com (8.9.3/8.9.3(vs)) id LAA18442; Mon, 28 Feb 2000 11:47:09 -0500 (EST) X-Authentication-Warning: pivsbh1.ms.com: Processed from queue /var/spool/mqueue-vs X-Authentication-Warning: pivsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf Received: from sasmh4.ms.com(144.14.193.5) by pivsbh1 via smap (4.1) id sma.9517564221.018131; Mon, 28 Feb 00 11:47:02 -0500 Received: from msdw.com (vector.morgan.com [144.14.16.149]) by sasmh4.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id LAA17177; Mon, 28 Feb 2000 11:47:02 -0500 (EST) Message-ID: <38BAA686.C0FA6A8A@msdw.com> Date: Mon, 28 Feb 2000 11:47:02 -0500 From: David Madeo Reply-To: David.Madeo@msdw.com Organization: Morgan Stanley Dean Witter & Co. X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: IETF CALSCH WG Subject: Re: AUTH method and MUST's References: <38B9CE11.B6635321@home.royer.com> <38BA9916.2A198013@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > > > 7.1.3. AUTHENTICATE Command > > [...] > > Implementations MUST support the SASL > > Anonymous mechanism, although this may be disabled in installations. > > I'm not comfortable with this requirement. The purpose of a standard is to > ensure interop. From the interop point of view, there is no difference > between a disabled feature and an unimplemented one; if it's safe to disable > it, it's safe not to implement it. Safer, in fact, because the only > guaranteed bug-free feature is the one you don't implement. :-) I read this to mean "The programmer must implement this, but they may choose to let the administrator of an installed system disable it in a config file." If I choose not to allow anonymous access on the server that I purchase, then I don't care which client I use to connect, I don't want to allow it. On the other hand, if I do allow anonymous access, then again, I don't care which client I use, I want it supported. Perhaps it would be better to write this as.... > > 7.1.3. AUTHENTICATE Command > > [...] > > Implementations MUST support the SASL > > Anonymous mechanism, although individual installations may choose either > > to not allow anonymous connections or to not grant any rights to the > > anonymous UPN's. dmadeo From owner-ietf-calendar@imc.org Mon Feb 28 12:19:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15166 for ; Mon, 28 Feb 2000 12:19:21 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16606 for ietf-calendar-bks; Mon, 28 Feb 2000 08:59:47 -0800 (PST) Received: from localhost.localdomain ([216.52.68.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16601 for ; Mon, 28 Feb 2000 08:59:45 -0800 (PST) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id MAA09563 for ; Mon, 28 Feb 2000 12:00:20 -0500 Message-ID: <38BAA9A3.CD82AD95@ecal.com> Date: Mon, 28 Feb 2000 12:00:19 -0500 From: John Stracke X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: IETF CALSCH WG Subject: Re: AUTH method and MUST's References: <38B9CE11.B6635321@home.royer.com> <38BA9916.2A198013@ecal.com> <38BAA686.C0FA6A8A@msdw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit David Madeo wrote: > I read this to mean > > "The programmer must implement this, but they may choose to let the > administrator of an installed system disable it in a config file." Yes, that's how I read it, too. This is a difference in opinion, not a misunderstanding: I maintain that this is an improper requirement to put in an interop spec. I do agree with you that clients MUST support anonymity. The problem is on the server side. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |"Hastur was paranoid, which was simply a | |francis@ecal.com|sensible...well-adjusted reaction to living in| | |Hell." --_Good Omens_ | \===============================================================/ From owner-ietf-calendar@imc.org Mon Feb 28 23:19:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28860 for ; Mon, 28 Feb 2000 23:19:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA05549 for ietf-calendar-bks; Mon, 28 Feb 2000 20:01:09 -0800 (PST) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA05544 for ; Mon, 28 Feb 2000 20:01:08 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id XAA01813; Mon, 28 Feb 2000 23:01:04 -0500 (EST) Date: Mon, 28 Feb 2000 23:01:04 -0500 (EST) Message-Id: <200002290401.XAA01813@smtp1.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org In-reply-to: Subject: Re: AUTH method and MUST's References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: pregen@egenconsulting.com This may sound like a dumb question, but is DES-MD5 (which I believe is also called CRAM-MD5??) in use in corporations and companies. I know that Kerberos is an issue and is not in wide a use as we may like. Does this security requirement ensure that we will have softtware companies who can build tools that can interoperate. Does it ensure we will have corporations and companies capable of running those productgs. I know security is key - being a former administrator and Director of security, it's what I look at first. It seems like this security piece could end up being a show-stopper. Am I wrong? Can someone make me comfortable that if we set this security rule, we will have companies implement this draft?? I've never heard "CRAM-MD5" called "DES-MD5". CRAM-MD5 can be fully implemented without any implementation of DES. From a Unix point of view, CRAM-MD5 and DIGEST-MD5 both suffer from needing the plaintext password to transition users to them. They also suffer from scalability problems that Kerberos doesn't; every service that uses CRAM-MD5 or DIGEST-MD5 must be able to access a copy of their secrets. They are only slightly harder to implement than plaintext passwords, so I don't see an interoperability problem, if that's what you're asking. Larry From owner-ietf-calendar@imc.org Tue Feb 29 19:40:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05804 for ; Tue, 29 Feb 2000 19:40:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA22238 for ietf-calendar-bks; Tue, 29 Feb 2000 16:16:37 -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 QAA22233 for ; Tue, 29 Feb 2000 16:16:35 -0800 (PST) Received: (from sman@localhost) by home.royer.com (8.9.1/8.9.1) id QAA23410 for ietf-calendar@imc.org; Tue, 29 Feb 2000 16:16:36 -0800 (PST) Date: Tue, 29 Feb 2000 16:16:36 -0800 (PST) From: ietf-calendar@imc.org Message-Id: <200003010016.QAA23410@home.royer.com> To: ietf-calendar@imc.org Subject: CAP draft update Sender: owner-ietf-calendar@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The CAP draft files have been updated on: ftp://royer.com/pub/CALSCH The current cap drafit is: ftp://royer.com/pub/CALSCH/cap.txt.gz Nroff and other source files including cap.txt: ftp://royer.com/pub/CALSCH/sources.tar.gz