From owner-ietf-calendar@mail.imc.org Tue Feb 4 12:12:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28941 for ; Tue, 4 Feb 2003 12:12:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14Gvr019024 for ietf-calendar-bks; Tue, 4 Feb 2003 08:57:53 -0800 (PST) Received: from firewall.itweb.com.mx (na-148-223-179-248.na.avantel.net.mx [148.243.179.248] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14Gvod19020 for ; Tue, 4 Feb 2003 08:57:51 -0800 (PST) Received: by firewall.itweb.com.mx (Postfix on SuSE Linux 7.2 (i386), from userid 10) id CB051587ED; Tue, 4 Feb 2003 11:10:05 -0600 (CST) Received: from UNKNOWN(192.168.0.1), claiming to be "IT.itweb.com.mx" via SMTP by firewall, id smtpdN3vafe; Tue Feb 4 11:10:04 2003 Received: by IT with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Feb 2003 10:59:02 -0600 Message-ID: <35B9141F53BED511BD9200508BEA5DD75FAE5B@IT> From: Prometeo Sandino Roman Corral To: ietf-calendar@imc.org Subject: RFC Digest Date: Tue, 4 Feb 2003 10:59:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I know this is a very basic question, but... Is there a document that explains the RFC 2445 but to a higher level? I mean, something like what "versit" did with vCalendar. It is because I've been trying to understand all of the implicit standards at the same time, and still could'nt. Any help will be very appreciated. Regards. Sandino From owner-ietf-calendar@mail.imc.org Tue Feb 4 13:58:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01367 for ; Tue, 4 Feb 2003 13:58:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14IjPR22111 for ietf-calendar-bks; Tue, 4 Feb 2003 10:45:25 -0800 (PST) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14IjOd22107 for ; Tue, 4 Feb 2003 10:45:25 -0800 (PST) Received: from mead5.u.washington.edu (mead5.u.washington.edu [140.142.12.140]) by mxout5.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h14IjQFR021320 for ; Tue, 4 Feb 2003 10:45:26 -0800 Received: from localhost (gsbarnes@localhost) by mead5.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h14IjPF2033414 for ; Tue, 4 Feb 2003 10:45:25 -0800 Date: Tue, 4 Feb 2003 10:45:25 -0800 (PST) From: "G. Barnes" To: ietf-calendar@imc.org Subject: trouble subscribing In-Reply-To: <35B9141F53BED511BD9200508BEA5DD75FAE5B@IT> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Apologies for sending this to the list, but as you can see I can't think of an alternative. A colleague of mine is having trouble getting subscribed to this list. He requested to subscribe on December 17, and got the standard 'your request has been forwarded to the owner of the "ietf-calendar" list for approval.' message. Since then, he's gotten nothing. He's since sent mail to the obvious followup addresses (ietf-calendar-approval@imc.org, majordomo@imc.org, majordomo-owner@imc.org) and has gotten no response there, either. Does anyone have any suggestions as to how I can help him get subscribed? Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 From owner-ietf-calendar@mail.imc.org Tue Feb 4 14:29:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02294 for ; Tue, 4 Feb 2003 14:29:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14JN5l24233 for ietf-calendar-bks; Tue, 4 Feb 2003 11:23:05 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14JN4d24224 for ; Tue, 4 Feb 2003 11:23:04 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h14JMwhB013846 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 4 Feb 2003 11:23:01 -0800 Message-ID: <3E40130D.1000507@Royer.com> Date: Tue, 04 Feb 2003 12:22:53 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: RFC Digest References: <35B9141F53BED511BD9200508BEA5DD75FAE5B@IT> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020407040800040305060501" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020407040800040305060501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Have you tried RFC-3283 ? Prometeo Sandino Roman Corral wrote: > I know this is a very basic question, but... > > Is there a document that explains the RFC 2445 but to a higher > level? > I mean, something like what "versit" did with vCalendar. > > It is because I've been trying to understand all of the implicit standards > at the same time, > and still could'nt. > > Any help will be very appreciated. > Regards. > > Sandino -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020407040800040305060501 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMDQxOTIyNTNaMCMGCSqGSIb3DQEJBDEWBBQP XTTby2FJCTSNdnI8zTDC0pbKEjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAsotb9c2U/3qJ h6h8QtTU3QVudp9PgW/7Lh06DbxT9VDwqjOItIuzUbwjIOOl7owktQr2BlryqRJ2n0X44BOp FRZ8Pwi9jXloBOvAl0piZNbLrSNMr5ufnj66cDSHl963BKXyIXjf/HXACcbqAxmgGfZWG5cb Ap4X+rQWoHQonU/38/2SJUs9Rm9pOwdzCIucd/P9bpIUZtspzPx2p1IHOskH4A/dibGiASWE ZDua+HiwPOH/kkrpzuaJQsmRuAwJf0aIkVAE1Ag9BnPtzJ69l0uh4FSnDjDERWkD/5B6ywiA ITFjZcfi68jqkiujykjSIQ06XM19fyTSJY8+L1G8cQAAAAAAAA== --------------ms020407040800040305060501-- From owner-ietf-calendar@mail.imc.org Tue Feb 4 15:10:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03085 for ; Tue, 4 Feb 2003 15:10:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14K4Q425730 for ietf-calendar-bks; Tue, 4 Feb 2003 12:04:26 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14K4Od25726 for ; Tue, 4 Feb 2003 12:04:24 -0800 (PST) Subject: Re: RFC Digest To: "ietf-calendar@imc.org" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 4 Feb 2003 15:04:27 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 02/04/2003 03:04:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hey Doug. I sent him a note with the same comment - i forgot to copy the list. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 From owner-ietf-calendar@mail.imc.org Tue Feb 4 15:11:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03120 for ; Tue, 4 Feb 2003 15:11:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14K5hI25767 for ietf-calendar-bks; Tue, 4 Feb 2003 12:05:43 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14K5fd25763 for ; Tue, 4 Feb 2003 12:05:41 -0800 (PST) Subject: Re: RFC Digest To: ietf-calendar@imc.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Tue, 4 Feb 2003 15:05:43 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 02/04/2003 03:05:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I forgot to copy the list on my reply back to Prometeo. Other people probably would like to know this as well. ----- Forwarded by Pat R Egen/Egen Consulting/01 on 02/04/03 03:02 PM ----- Pat R Egen To: Prometeo Sandino Roman Corral 02/04/03 12:19 PM cc: Subject: Re: RFC Digest(Document link: Pat Egen Mail) You might try reading the Guide To Internet Calendaring - this is RFC3283 . I've attached a link to this document. It may not anwer all your questions, but it might be a good start. http://www.ietf.org/rfc/rfc3283.txt Prometeo Sandino Roman Corral Sent by: owner-ietf-calendar@mail.imc.org 02/04/2003 11:59 To: ietf-calendar@imc.org cc: Subject: RFC Digest I know this is a very basic question, but... Is there a document that explains the RFC 2445 but to a higher level? I mean, something like what "versit" did with vCalendar. It is because I've been trying to understand all of the implicit standards at the same time, and still could'nt. Any help will be very appreciated. Regards. Sandino From owner-ietf-calendar@mail.imc.org Tue Feb 4 16:08:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04406 for ; Tue, 4 Feb 2003 16:08:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14L2l927366 for ietf-calendar-bks; Tue, 4 Feb 2003 13:02:47 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14L2jd27362 for ; Tue, 4 Feb 2003 13:02:46 -0800 (PST) In-Reply-To: <20030130101654.GF81678@inet.it> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 4 Feb 2003 15:57:23 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/04/2003 04:02:31 PM, Serialize complete at 02/04/2003 04:02:31 PM Content-Type: multipart/alternative; boundary="=_alternative 0072AB9485256CC3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072AB9485256CC3_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 01/30/2003 05:16:54 AM: > > o finish sending complete replies to any outstanding "MSG" messages > > it has received on that channel, and ensure that the final frames > > of those replies have been successfully delivered, i.e., > > > > which tells me that the CS wont accept the session close attempt until it > > finishes dealing w/the unbounded query; there may be outstanding response > > messages to send back still as the command progresses!. Im still no BEEP > > guru so Ill defer to them when Im slapped and corrected otherwise. > > This is implementation independent really. Nothing here says you have > to complete processing the query, you only need to send a failure > ANS or RPY to each outstanding command for the channel, before accepting > the shutdown request. > > Do you agree or do I have to get into more details? I think that the bit about not actually having to complete the command is a bit suspect but Ill leave that to other BEEP savy folks to comment on. Besides the case in question is not a failure, its where the CS is told just keep processing while the CUA waits. On the bright side, Im finally able to put a better spin on the question I raised about unbounded commands now that Ive had a weekend to chew on it. As Larry noted (but I didnt absorb until I was home), the current peer protocols (IMAP, POP3, etc) use a mode where ALL calls are unbounded and the requestor MUST wait for them to complete (or the net to disconnect, etc.) As such those UAs have no real recourse but to just drop the network connection when the user clicks on Cancel or takes some action. This is implicit in their designs and implementations. In CAP we have taken the philosophy that commands are generally timed so that the CUA can be more interactive w/controlling the CS. As such I had totally blanked out the need for an unbounded command and I think that PDAs are not related to that discussion as some suggested. Ok, so now I grok the scenario for it (ie: I built a CUA that acts like older UAs and only does unbounded commands) but Im not sure that preserving that behaviour is a necessary/cool idea. If we plan to keep unbounded commands in then we really should devise a way to issue a CANCEL command so we dont have to basically drop everything else that is going on on other sessions and reconnect, reauthenticate, etc. The command can be pretty simple, have it take the channel and CMDID as inputs and then it just cancels the current command on that channel (presumably the unbounded one instead of one that is bounded and thus easily ABORTable). Also, given that we allow unbounded commands and bounded commands I think a couple lines in the draft to the effect of "If you use unbounded commands then you either MUST wait for them to complete or you have to do ... " would be nice. At a minimum we should probably have a suggestion about the benefits of bounded vs unbounded and why... (After all there have to be other folks out there who step in it just like I did...) Given that we are building entirely new UAs and a new protocol here, does anyone see a pressing need to have unbounded commands? If we made all commands unbounded then that would remove the need for an explicit cancel mechanism and some prose in the draft. Im flexible either way now but applying the KISS mantra makes me lean towards no unbounded commands in CAP... Others?? > I can understand your points, I can't really question their validity, > however no matter what you do, you will still have to deal with > interactive CUAs which need to deal with a user. A CU might decide > to cancel a command before the latency expires, so we still need a > mechanism for that, right? I would expect that a CUA would NOT set timeouts so high as to be essentially unbounded. I would also expect them to not be too low so as to generate lots of excessive traffic (CONTINUE;LATENCY=1 is a BAD idea...). Since (nearly?) all of the responses so far have been "Well I may want to cancel the command because the user pressed Esc or clicked on Cancel or..." I think that nearly all of us view the SOP as being bounded commands. With current peer protocols like POP3 or IMAP the UA simply terminates the connection and considers the task done. This is still an option but not as gentle as a CANCEL command. If you think we need a CANCEL command even for bounded commands Id at least be open to hearing more on that... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0072AB9485256CC3_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 01/30/2003 05:16:54 AM:
> >    o  finish sending complete replies to any outstanding "MSG" messages
> >       it has received on that channel, and ensure that the final frames
> >       of those replies have been successfully delivered, i.e.,
> >
> > which tells me that the CS wont accept the session close attempt until it
> > finishes dealing w/the unbounded query; there may be outstanding response
> > messages to send back still as the command progresses!.  Im still no BEEP
> > guru so Ill defer to them when Im slapped and corrected otherwise.
>
> This is implementation independent really. Nothing here says you have
> to complete processing the query, you only need to send a failure
> ANS or RPY to each outstanding command for the channel, before accepting
> the shutdown request.
>
> Do you agree or do I have to get into more details?
I think that the bit about not actually having to complete the command is a bit suspect but Ill leave that to other BEEP savy folks to comment on.

Besides the case in question is not a failure, its where the CS is told just keep processing while the CUA waits.

On the bright side, Im finally able to put a better spin on the question I raised about unbounded commands now that Ive had a weekend to chew on it.  

As Larry noted (but I didnt absorb until I was home), the current peer protocols (IMAP, POP3, etc) use a mode where ALL calls are unbounded and the requestor MUST wait for them to complete (or the net to disconnect, etc.)  As such those UAs have no real recourse but to just drop the network connection when the user clicks on Cancel or takes some action.  This is implicit in their designs and implementations.  In CAP we have taken the philosophy that commands are generally timed so that the CUA can be more interactive w/controlling the CS.  As such I had totally blanked out the need for an unbounded command and I think that PDAs are not related to that discussion as some suggested.

Ok, so now I grok the scenario for it (ie: I built a CUA that acts like older UAs and only does unbounded commands) but Im not sure that preserving that behaviour is a necessary/cool idea.  If we plan to keep unbounded commands in then we really should devise a way to issue a CANCEL command so we dont have to basically drop everything else that is going on on other sessions and reconnect, reauthenticate, etc.  The command can be pretty simple, have it take the channel and CMDID as inputs and then it just cancels the current command on that channel (presumably the unbounded one instead of one that is bounded and thus easily ABORTable).  Also, given that we allow unbounded commands and bounded commands I think a couple lines in the draft to the effect of "If you use unbounded commands then you either MUST wait for them to complete or you have to do ... " would be nice.  At a minimum we should probably have a suggestion about the benefits of bounded vs unbounded and why...  (After all there have to be other folks out there who step in it just like I did...)

Given that we are building entirely new UAs and a new protocol here, does anyone see a pressing need to have unbounded commands?  If we made all commands unbounded then that would remove the need for an explicit cancel mechanism and some prose in the draft.  Im flexible either way now but applying the KISS mantra makes me lean towards no unbounded commands in CAP...  Others??

> I can understand your points, I can't really question their validity,
> however no matter what you do, you will still have to deal with
> interactive CUAs which need to deal with a user. A CU might decide
> to cancel a command before the latency expires, so we still need a
> mechanism for that, right?

I would expect that a CUA would NOT set timeouts so high as to be essentially unbounded.  I would also expect them to not be too low so as to generate lots of excessive traffic (CONTINUE;LATENCY=1 is a BAD idea...).   Since (nearly?) all of the responses so far have been "Well I may want to cancel the command because the user pressed Esc or clicked on Cancel or..." I think that nearly all of us view the SOP as being bounded commands.    With current peer protocols like POP3 or IMAP the UA simply terminates the connection and considers the task done.  This is still an option but not as gentle as a CANCEL command.

If you think we need a CANCEL command even for bounded commands Id at least be open to hearing more on that...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0072AB9485256CC3_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 4 16:43:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05180 for ; Tue, 4 Feb 2003 16:43:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14LZvD28048 for ietf-calendar-bks; Tue, 4 Feb 2003 13:35:57 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14LZud28044 for ; Tue, 4 Feb 2003 13:35:56 -0800 (PST) In-Reply-To: <200301302056.h0UKubQ9002466@smtp6.andrew.cmu.edu> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 4 Feb 2003 16:30:41 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/04/2003 04:35:59 PM, Serialize complete at 02/04/2003 04:35:59 PM Content-Type: multipart/alternative; boundary="=_alternative 007604CC85256CC3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007604CC85256CC3_= Content-Type: text/plain; charset="US-ASCII" Larry wrote on 01/30/2003 03:56:37 PM: First Id like to say thanks for your POP3/IMAP/LDAP reply last week. It took a day to sink in but I finally got it and partly answered my own question in a different thread. > It simplifies implementations. (You do want people to implement this, > right?) What happens if you submit a bounded command (3 seconds, > say), wait 3 seconds, and the server doesn't come back? What if it > doesn't come back in 30 seconds? This is something the draft needs to cover (plus its not related to unbounded commands). Thanks for raising it. > What if you submit an unbounded command, wait 1 second, submit a > CANCEL, and the server still hasn't replied in 30 seconds? This assumes that we have some CANCEL command. Currently we do not nor has one been actually be proposed for inclusion yet. ANY command could fail to get a response so whatever solution we devise for your 1st question needs to cover them all. > What if the network is down or tremendously slow? Or the CS is under very heavy load... Or the command triggered some kind of housecleaning or fixup action on a particular TARGET... I don't think we've considered the case of a CS actually being clustered and thus load balanced, etc. but that too plays into this in the ever growing Enterprise and hosted environments. > [...] > Still, why invent more stuff if unbounded commands do not make sense given > our current model?... Or if we are going to keep unbounded commands then > we really should expreslly codify the way that a CUA terminates them so we > have consistant behaviour among all implementations. > > How am I, as a client, suppose to know how long something is going to > take the server? Maybe the server is really loaded. Maybe it affects a > lot of data on the server. The intent of the latency value is for the CUA to express to the CS "This is how long Im willing to wait to get back my results. Check back with me then if you are not done and see if I want to CONTINUE or not." If the CS is heavily loaded then of course its possible that it does not respond exactly at the specified time with a CONTINUE command. Also the CUA must factor in that the clock for latency does NOT start when the command is put on the wire to the CS (at least in my mind) so using a local timer to say "Hey, that stupid CS didnt complete the command in 5 seconds and I dont see a CONTINUE command that I would therefore expect; something must be wrong!" is not a good design. Its also why I objected to the current draft text that mandates "If a CS can both start sending the reply to a command and guarantee that all of the results can be sent from a command..." since this kind of requirement is impossible to accurately do. > The last thing I want, as a server, is for clients to try an operation > for 5 seconds, then try it for 10, then 20, etc., until it's done. Thats exactly what LATENCY is for; so the CUA can "give the server a little more time to complete the command". Do you think that we need to have some kind of minimum latency values that CS's will accept so that they can tell CUAs "I dont care if you want results within 5 seconds, Im only going to guarantee a minimum response time of 30 seconds"? Or perhaps you are thinking that bounded latency is too much to do and that it should be optional entirely (ie: All CAP commands follow the existing POP3/IMAP/LDAP/etc model of 'Its done when its done and if you dont want to wait then leave.")?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007604CC85256CC3_= Content-Type: text/html; charset="US-ASCII"
Larry wrote on 01/30/2003 03:56:37 PM:
First Id like to say thanks for your POP3/IMAP/LDAP reply last week.  It took a day to sink in but I finally got it and partly answered my own question in a different thread.

> It simplifies implementations. (You do want people to implement this,
> right?) What happens if you submit a bounded command (3 seconds,
> say), wait 3 seconds, and the server doesn't come back? What if it
> doesn't come back in 30 seconds?
This is something the draft needs to cover (plus its not related to unbounded commands).  Thanks for raising it.

> What if you submit an unbounded command, wait 1 second, submit a
> CANCEL, and the server still hasn't replied in 30 seconds?
This assumes that we have some CANCEL command.  Currently we do not nor has one been actually be proposed for inclusion yet.

ANY command could fail to get a response so whatever solution we devise for your 1st question needs to cover them all.

> What if the network is down or tremendously slow?
Or the CS is under very heavy load... Or the command triggered some kind of housecleaning or fixup action on a particular TARGET...

I don't think we've considered the case of a CS actually being clustered and thus load balanced, etc. but that too plays into this in the ever growing Enterprise and hosted environments.

> [...]
>    Still, why invent more stuff if unbounded commands do not make sense given
>    our current model?...  Or if we are going to keep unbounded commands then
>    we really should expreslly codify the way that a CUA terminates them so we
>    have consistant behaviour among all implementations.
>
> How am I, as a client, suppose to know how long something is going to
> take the server? Maybe the server is really loaded. Maybe it affects a
> lot of data on the server.
The intent of the latency value is for the CUA to express to the CS "This is how long Im willing to wait to get back my results.  Check back with me then if you are not done and see if I want to CONTINUE or not."  If the CS is heavily loaded then of course its possible that it does not respond exactly at the specified time with a CONTINUE command.  

Also the CUA must factor in that the clock for latency does NOT start when the command is put on the wire to the CS (at least in my mind) so using a local timer to say "Hey, that stupid CS didnt complete the command in 5 seconds and I dont see a CONTINUE command that I would therefore expect; something must be wrong!" is not a good design.  Its also why I objected to the current draft text that mandates "If a CS can both start sending the reply to a command and guarantee that all of the results can be sent from a command..." since this kind of requirement is impossible to accurately do.

> The last thing I want, as a server, is for clients to try an operation
> for 5 seconds, then try it for 10, then 20, etc., until it's done.
Thats exactly what LATENCY is for; so the CUA can "give the server a little more time to complete the command".

Do you think that we need to have some kind of minimum latency values that CS's will accept so that they can tell CUAs "I dont care if you want results within 5 seconds, Im only going to guarantee a minimum response time of 30 seconds"?  Or perhaps you are thinking that bounded latency is too much to do and that it should be optional entirely (ie: All CAP commands follow the existing POP3/IMAP/LDAP/etc model of 'Its done when its done and if you dont want to wait then leave.")??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007604CC85256CC3_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 4 17:08:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06153 for ; Tue, 4 Feb 2003 17:08:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14Llqi28295 for ietf-calendar-bks; Tue, 4 Feb 2003 13:47:52 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14Llpd28291 for ; Tue, 4 Feb 2003 13:47:51 -0800 (PST) In-Reply-To: <3E3963AD.5030209@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP 10: alarm-seq MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 4 Feb 2003 16:47:48 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/04/2003 04:47:53 PM, Serialize complete at 02/04/2003 04:47:53 PM Content-Type: multipart/alternative; boundary="=_alternative 0077961585256CC3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0077961585256CC3_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 01/30/2003 12:41:01 PM: > Please re-search the archives Bruce. This is over a YEAR old > and was in several previous drafts. It is in the archives. Hmm, my FT archives cant seem to find any discussion why the alarm-seq MUST be different from sequence in iCalendar in that it begins at 0 and not 1. After all to be consistant the first time I create the VALARM the SEQUENCE on it would be 0... I fully grok why we dont want it to be negative but why cant it start at 0? What am I missing? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0077961585256CC3_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 01/30/2003 12:41:01 PM:
> Please re-search the archives Bruce. This is over a YEAR old
> and was in several previous drafts. It is in the archives.
Hmm, my FT archives cant seem to find any discussion why the alarm-seq MUST be different from sequence in iCalendar in that it begins at 0 and not 1.  After all to be consistant the first time I create the VALARM the SEQUENCE on it would be 0...

I fully grok why we dont want it to be negative but why cant it start at 0?  What am I missing?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0077961585256CC3_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 4 17:28:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06580 for ; Tue, 4 Feb 2003 17:28:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14MFU129094 for ietf-calendar-bks; Tue, 4 Feb 2003 14:15:30 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14MFSd29090 for ; Tue, 4 Feb 2003 14:15:28 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h14MFQhB015168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Feb 2003 14:15:30 -0800 Message-ID: <3E403B79.3060203@Royer.com> Date: Tue, 04 Feb 2003 15:15:21 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020502050305010000050203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020502050305010000050203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > in it just like I did...) > > Given that we are building entirely new UAs and a new protocol here, > does anyone see a pressing need to have unbounded commands? If we made > all commands unbounded then that would remove the need for an explicit > cancel mechanism and some prose in the draft. Im flexible either way > now but applying the KISS mantra makes me lean towards no unbounded > commands in CAP... Others?? Yes. That was my argument the PDA is just an example. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020502050305010000050203 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMDQyMjE1MjFaMCMGCSqGSIb3DQEJBDEWBBQv 1r2xBAwTFThOYknOhFq79d7XdzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAUhXn51NlfEei W7a3yOwWA6aalTKr55vVcwsgRIT2xh/x418eyL7+z2mbPc4wWi9YJZjnsNMTeBM0B4xqyY9B Lv6APS/+EW0xgQCx9mo2dwH5QGv0eigAlQbqNZxVKpia0N9lAVEf+U58zP1JgbvkmrS2S/VQ VGnCM7jjZrAaBQfxArwg4eJCxtM2TfqPQeWU+VUZdKml9nOq1Q94q6LriDWFWwB8ggOJieJd l+TkeO24S9TUe8eG8MiWhZPdAbj2vv895Mapp5L3eJ5RaECdimneCJ6HhsN3lPl30W41lNvA RQzP8r8NYyqCz+P0LiOuFf3lETkJPEvwzWstLywlNQAAAAAAAA== --------------ms020502050305010000050203-- From owner-ietf-calendar@mail.imc.org Tue Feb 4 17:30:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06620 for ; Tue, 4 Feb 2003 17:30:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14MPDE29373 for ietf-calendar-bks; Tue, 4 Feb 2003 14:25:13 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14MPBd29369 for ; Tue, 4 Feb 2003 14:25:11 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h14MPBhB015257 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 4 Feb 2003 14:25:13 -0800 Message-ID: <3E403DC1.4070207@Royer.com> Date: Tue, 04 Feb 2003 15:25:05 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050608050407080509000402" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050608050407080509000402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Larry wrote on 01/30/2003 03:56:37 PM: > > First Id like to say thanks for your POP3/IMAP/LDAP reply last week. It > took a day to sink in but I finally got it and partly answered my own > question in a different thread. > > > It simplifies implementations. (You do want people to implement this, > > right?) What happens if you submit a bounded command (3 seconds, > > say), wait 3 seconds, and the server doesn't come back? What if it > > doesn't come back in 30 seconds? > > This is something the draft needs to cover (plus its not related to > unbounded commands). Thanks for raising it. > > > What if you submit an unbounded command, wait 1 second, submit a > > CANCEL, and the server still hasn't replied in 30 seconds? > > This assumes that we have some CANCEL command. Currently we do not nor > has one been actually be proposed for inclusion yet. CMD: ABORT Purpose: The "ABORT" command is sent to request that the named or only in process command be aborted. Latency MUST not be supplied with the "ABORT" command. Use ABORT as it has no restriction that it can only be sent after a timeout. > > Do you think that we need to have some kind of minimum latency values > that CS's will accept so that they can tell CUAs "I dont care if you > want results within 5 seconds, Im only going to guarantee a minimum > response time of 30 seconds"? Minimum latency - no. 20 years ago 56K direct internet was screaming fast. In 10 years 5 seconds may be too long. The CS can always send an error back when it can not handle the command. > Or perhaps you are thinking that bounded > latency is too much to do and that it should be optional entirely (ie: > All CAP commands follow the existing POP3/IMAP/LDAP/etc model of 'Its > done when its done and if you dont want to wait then leave.")?? Adding latency is optional. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050608050407080509000402 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMDQyMjI1MDZaMCMGCSqGSIb3DQEJBDEWBBS/ +Pj0igIkitTXeCvs/EsMKfgpijBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAvHzqUHsN3+FK Q3lfuK0Ajab27QB8keeRNClSnib9y7FhCy+nMxKQYbFyx4yjWKfJA7hBCrU0yB9nuOhHYyds MWp+D2iZQYlXgDN404JQ8m41zJjxUzVEAbPO/97yB39PL/uzL29WnJcUKCeBZvzZrUdUKCnO AOMzCuGSVavugMvttO1wsa3hxwY5qwIlML14YhCbR/FLj/rAH7KhN+MPvx3HcQGp7zkUZINy ff+6TLFYei6++hRFK2OTXyiUiKEb/cR4DfbpxCv5HOERw3uW4ygJGTlQOOBRjP8EF2Ww4GIr KJ8aEBkdZDSPFmSx3fOOBe5lzUOSFUu8qaq33WOxuwAAAAAAAA== --------------ms050608050407080509000402-- From owner-ietf-calendar@mail.imc.org Tue Feb 4 17:37:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06833 for ; Tue, 4 Feb 2003 17:37:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14MQBv29401 for ietf-calendar-bks; Tue, 4 Feb 2003 14:26:11 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h14MQAd29397 for ; Tue, 4 Feb 2003 14:26:11 -0800 (PST) In-Reply-To: <3E39643D.8010009@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: 7.2. LOCAL Parameter MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 4 Feb 2003 17:26:06 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/04/2003 05:26:11 PM, Serialize complete at 02/04/2003 05:26:11 PM Content-Type: multipart/alternative; boundary="=_alternative 007B17A485256CC3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B17A485256CC3_= Content-Type: text/plain; charset="US-ASCII" Doug claimed on 01/30/2003 12:43:25 PM: > > At one point in the text it is referred to as "the "LOCAL" property" but > > not in all cases. Any reason we cannot make LOCAL a new VALARM property > > instead of just a property parameter? > > This was discussed months ago. Many months ago it was mentioned but no actual real WG discussion that I can find. My FT index reveals that it was covered by you in reply to Steve waaaay back on 03/25/2002 09:53:18 AM MST under the subject "Re: CAP draft 07 issues - sections 3 and 4" where you wrote: There was (and i ~think~ generally accepted) debate about how to tag VALARMs as LOCAL and non-LOCAL, which included adding SEQUENCE to VALARMS in order to make them unique. I'll look for the post and forward it to you. but of the referenced posting I can find no copy in my FT archives nor was there any related followup to the list. Ugh, I really have to revise my opinion of the new IBM FT engine downwards; it seems that because I was using uppercase for the entire phrase ALARM it only matched that phrase exactly in any case and thus failed to find VALARM! %^| I find a wandering discussion under the subject "Modifying VALARM" back in mid January 2002 and another related one under the subject "(#1) synchronization part 2, and identifying a components VALARM" where Mark Paterson proposed the use of LOCAL as a parameter (based on your text from Dec 2001 where you suggested a scoping parameter on SEQUENCE originally) Doug and Mark discussed the scoping of ENABLE but no real WG discussion as to the proper form for the value on the VALARM. In any case really think that since LOCAL is describing the VALARM as being 'locally created and owned' that it definitely does NOT belong as a property parameter on SEQUENCE; it should be its own property in VALARMs. Im NOT against adding it, just adding it in the incorrect form. Perhaps if I could find some text that described how the attribute of the VALARM belongs as a property to a parameter rather than being a property itself I would let it slide but I see the current design as inconsistant the roles of properties vs property parameters. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007B17A485256CC3_= Content-Type: text/html; charset="US-ASCII"
Doug claimed on 01/30/2003 12:43:25 PM:
> > At one point in the text it is referred to as "the "LOCAL" property" but
> > not in all cases.  Any reason we cannot make LOCAL a new VALARM property
> > instead of just a property parameter?
>
> This was discussed months ago.
Many months ago it was mentioned but no actual real WG discussion that I can find.  My FT index reveals that it was covered by you in reply to Steve waaaay back on 03/25/2002 09:53:18 AM MST under the subject "Re: CAP draft 07 issues - sections 3 and 4" where you wrote:

There was (and i ~think~ generally accepted) debate about how to
tag VALARMs as LOCAL and non-LOCAL, which included adding SEQUENCE
to VALARMS in order to make them unique. I'll look for the post and
forward it to you.

but of the referenced posting I can find no copy in my FT archives nor was there any related followup to the list.  

Ugh, I really have to revise my opinion of the new IBM FT engine downwards; it seems that because I was using uppercase for the entire phrase ALARM it only matched that phrase exactly in any case and thus failed to find VALARM! %^|  

I find a wandering discussion under the subject "Modifying VALARM"  back in mid January 2002 and another related one under the subject "(#1) synchronization part 2, and identifying a components VALARM" where Mark Paterson proposed the use of LOCAL as a parameter (based on your text from Dec 2001 where you suggested a scoping parameter on SEQUENCE originally)  Doug and Mark discussed the scoping of ENABLE but no real WG discussion as to the proper form for the value on the VALARM.

In any case really think that since LOCAL is describing the VALARM as being 'locally created and owned' that it definitely does NOT belong as a property parameter on SEQUENCE; it should be its own property in VALARMs.  Im NOT against adding it, just adding it in the incorrect form.  Perhaps if I could find some text that described how the attribute of the VALARM belongs as a property to a parameter rather than being a property itself I would let it slide but I see the current design as inconsistant the roles of properties vs property parameters.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007B17A485256CC3_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 5 11:06:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29617 for ; Wed, 5 Feb 2003 11:06:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15Fsr315509 for ietf-calendar-bks; Wed, 5 Feb 2003 07:54:53 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15Fsqd15505 for ; Wed, 5 Feb 2003 07:54:52 -0800 (PST) In-Reply-To: <3E403DC1.4070207@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 5 Feb 2003 10:54:50 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Build V601_01162003NP|January 16, 2003) at 02/05/2003 10:54:53 AM, Serialize complete at 02/05/2003 10:54:53 AM Content-Type: multipart/alternative; boundary="=_alternative 005740F685256CC4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005740F685256CC4_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 02/04/2003 05:25:05 PM: > CMD: ABORT > > Purpose: The "ABORT" command is sent to request that the named or > only in process command be aborted. Latency MUST not be supplied > with the "ABORT" command. > > Use ABORT as it has no restriction that it can only be sent after > a timeout. Hmmm. From Section 10.1.1 Bounded Latency: If the command is unable to be completed in the specified amount of time (as specified by the "LATENCY" parameter value), then a "TIMEOUT" command MUST BE sent on the same channel to which there MUST BE a an "ABORT" or a "CONTINUE" command reply. If the CUA initiated the original command, then the CS would issue the "TIMEOUT" command and the CUA would then have to issue an "ABORT" or "CONTINUE" command. [Snip] Upon receiving an "ABORT" command, the command must then be terminated. The first bit implys (correctly or not) that the ABORT command is sent in response to the TIMEOUT command. Also since the ABORT command only applys to the channel it is sent on, and the CS is already busy with an unbounded command, I dont see that the ABORT will effect the unbounded command that the CS is processing. I dont find any requirement that the CS process pipelined commands out of order or concurrently. That is, if the SEARCH is unbounded and then the sends an ABORT on the same channel, I see no text/requirement that the ABORT command get acted on until the SEARCH is done. Catch-22, the ABORT command wont be seen (since no TIMEOUT command was sent by the CS and then waited for) until after the unbounded command is done thus negating the need for ABORT.. I see that in Section 10.1.2 it says: Purpose: The "ABORT" command is sent to request that the named or only in process command be aborted. so Im wondering if "only in process command" is meant to refer to the current command on that channel or to a command that has no ID (or both?)?... Also, it talks of "the named...command" so checking ABNF shows: abortparam = *( ; the following are optional, ; but MUST NOT occur more than once id-param / localize-param ; the following is optional, ; and MAY occur more than once / other-params ) However, the definition of id-param is: id-param = ";" "ID" "=" unique-id ; The text value supplied is a unique value ; shared between the CUA and CS to uniquely ; identify the instance of command in the ; the current CUA session. The value has ; no meaning to other CUAs or other sessions. Its intended use is to sync up replys to commands (mainly in the event of multiple commands at the same time but not even for single command cases too). In the ABORT case it is NOT identifying the ABORT command but rather the other command that the sender is trying to abort. Some prose to this effect should be added to the ABORT command so that its clear that CMD;ID="FizBin1":ABORT is trying to indicate "Terminate the command named FizBin1 on this channel" rather than identifying the ABORT command so that a response can be matched up to it. This though is overloading id-param and prevents the sender from being able to match up the proper XXX-reply to the command.. After all, its possible that the unbounded command FizBin1 completes before the ABORT command is received. So then the ABORT sender has to decipher the responses: BEGIN:VCALENDAR TARGET:relcalid CMD;ID=FizBin1:REPLY VERSION:2.0 PRODID:-//someone's prodid BEGIN:VREPLY BEGIN:VEVENT REQUEST-STATUS:4.1;Im sorry Dave\, I cant do that... END:VEVENT END:VREPLY END:VCALENDAR from BEGIN:VCALENDAR VERSION:2.0 PRODID:-//someone's prodid TARGET:relcalid CMD;ID=FizBin1:REPLY BEGIN:VREPLY REQUEST-STATUS:2.0.3;I did as you requested. X-IBM-WIDGET:Command was processed by CS1 within 10 seconds. END:VREPLY END:VCALENDAR as belonging to the ABORT command or the command that was asked to be aborted or to the command itself. Can you match them up quickly and correctly? > Minimum latency - no. 20 years ago 56K direct internet was screaming fast. > In 10 years 5 seconds may be too long. The CS can always send an > error back when it can not handle the command. Larrys case is not an issue with the CS not being able to handle the command; its a desire to avoid having clients just keep pecking at it with tiny CONTINUE values resulting in the CS spending more time doing more TIMEOUT/ABORT/CONTINUE handling than actual CREATE/SEARCH/etc command handling. As the CS has to scale up to handle thousands of users concurrently (ie: Enterprise sites) then having CUAs all do CAP commands with tiny expected response times becomes a burden to the CS. There is only so far that relying on very very beefy MP boxes to efficiently handle lots of threads can take us. I was merely asking Larry if he thought that the needed to be some way for the CS have some say in the process instead of letting the CUA be the sole source of control when deciding acceptable latency values. I could see this as a useful GET-CAPABILITY response. For example, under light loads the CS would send back "I should be able to process commands with a latency value of 2 seconds just fine." but under peak loads it would send back"I should be able to process commands with a latency value of 40 seconds just fine." That way the requesting CUA can at least indicate to the CU that operations may take longer or even better, adjust their "Continue for 10 seconds", "Continue for 30 seconds", "Continue for 60 seconds" algorithms that Larry mentioned to accomoate the CS's load. All this is not unreasonable to consider, especially if we plan to implement this on larger scale systems... I am merely asking Larry if he thinks its something CAP needs. > > Or perhaps you are thinking that bounded > > latency is too much to do and that it should be optional entirely (ie: > > All CAP commands follow the existing POP3/IMAP/LDAP/etc model of 'Its > > done when its done and if you dont want to wait then leave.")?? > > Adding latency is optional. Yes it is and if the CS is busy processing the unbounded command then its not going to be able to process the ABORT command (see above). Thats why the peer protocols cited have no ABORT analogs, they simply drop the link and reestablish it. FMI: Can ABORT be used to cancel commands that have no id-param? For example, if the CREATE command in Section 10.1.4 has no LATENCY or ID property parameters: BEGIN:VCALENDAR PRODID:-//someone's prodid VERSION:2.0 CMD:CREATE TARGET:cal.example.com BEGIN:VAGENDA CALID:relcalz1 NAME;LANGUAGE=en_US:Bill's Soccer Team OWNER:bill CALMASTER:mailto:bill@example.com TZID:US/Pacific END:VAGENDA BEGIN:VAGENDA CALID:relcalz2 NAME;LANGUAGE=EN-us:Mary's personal calendar OWNER:mary CALMASTER:mailto:mary@example.com TZID:US/Pacific END:VAGENDA END:VCALENDAR Just how would my CUA ABORT it? CMD:ABORT on the same channel? Without requireing some form of command concurrent processing or pipelining in the CS, this isnt doable. The only simple solution is the one used in peer protocols (Disconnect/reconnect/reauthenticate)... Bruce PS: In answer to my examples: The former response is the CS's response to the unbounded command and then latter response is the response to the ABORT command; both were taken from draft 10 12Jan2003 examples with just minor tweaks... ========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005740F685256CC4_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 02/04/2003 05:25:05 PM:
>     CMD: ABORT
>
>     Purpose: The "ABORT" command is sent to request that the named or
>     only in process command be aborted.  Latency MUST not be supplied
>     with the "ABORT" command.
>
> Use ABORT as it has no restriction that it can only be sent after
> a timeout.
Hmmm.  From Section 10.1.1 Bounded Latency:

If the command is unable to be completed in the specified amount of time (as specified by the "LATENCY" parameter value), then a "TIMEOUT" command MUST BE sent on the same channel to which there MUST BE a an "ABORT" or a "CONTINUE" command reply. If the CUA initiated the original command, then the CS would issue the "TIMEOUT" command and the CUA would then have to issue an "ABORT" or "CONTINUE" command. [Snip]

Upon receiving an "ABORT" command, the command must then be terminated.

The first bit implys (correctly or not) that the ABORT command is sent in response to the TIMEOUT command.  

Also since the ABORT command only applys to the channel it is sent on, and the CS is already busy with an unbounded command, I dont see that the ABORT will effect the unbounded command that the CS is processing.  I dont find any requirement that the CS process pipelined commands out of order or concurrently.  That is, if the SEARCH is unbounded and then the sends an ABORT on the same channel, I see no text/requirement that the ABORT command get acted on until the SEARCH is done.  Catch-22, the ABORT command wont be seen (since no TIMEOUT command was sent by the CS and then waited for) until after the unbounded command is done thus negating the need for ABORT..

I see that in Section 10.1.2 it says:

Purpose: The "ABORT" command is sent to request that the named or only in process command be aborted.

so Im wondering if "only in process command" is meant to refer to the current command on that channel or to a command that has no ID (or both?)?...  

Also, it talks of "the named...command" so checking ABNF shows:

abortparam   = *(
                     ; the following are optional,
                     ; but MUST NOT occur more than once

                       id-param
                     / localize-param

                     ; the following is optional,
                     ; and MAY occur more than once

                     / other-params
                     )
However, the definition of id-param is:

id-param         = ";" "ID" "=" unique-id
                ; The text value supplied is a unique value
                ; shared between the CUA and CS to uniquely
                ; identify the instance of command in the
                ; the current CUA session. The value has
                ; no meaning to other CUAs or other sessions.
Its intended use is to sync up replys to commands (mainly in the event of multiple commands at the same time but not even for single command cases too).  In the ABORT case it is NOT identifying the ABORT command but rather the other command that the sender is trying to abort.

Some prose to this effect should be added to the ABORT command so that its clear that CMD;ID="FizBin1":ABORT is trying to indicate "Terminate the command named FizBin1 on this channel" rather than identifying the ABORT command so that a response can be matched up to it.  This though is overloading id-param and prevents the sender from being able to match up the proper XXX-reply to the command..  

After all, its possible that the unbounded command FizBin1 completes before the ABORT command is received.  So then the ABORT sender has to decipher the responses:

BEGIN:VCALENDAR
TARGET:relcalid
CMD;ID=FizBin1:REPLY
VERSION:2.0
PRODID:-//someone's prodid
BEGIN:VREPLY
BEGIN:VEVENT
REQUEST-STATUS:4.1;Im sorry Dave\, I cant do that...
END:VEVENT
END:VREPLY
END:VCALENDAR
from

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//someone's prodid
TARGET:relcalid
CMD;ID=FizBin1:REPLY
BEGIN:VREPLY
REQUEST-STATUS:2.0.3;I did as you requested.
X-IBM-WIDGET:Command was processed by CS1 within 10 seconds.
END:VREPLY
END:VCALENDAR
as belonging to the ABORT command or the command that was asked to be aborted or to the command itself.  Can you match them up quickly and correctly?

> Minimum latency - no. 20 years ago 56K direct internet was screaming fast.
> In 10 years 5 seconds may be too long. The CS can always send an
> error back when it can not handle the command.
Larrys case is not an issue with the CS not being able to handle the command; its a desire to avoid having clients just keep pecking at it with tiny CONTINUE values resulting in the CS spending more time doing more TIMEOUT/ABORT/CONTINUE handling than actual CREATE/SEARCH/etc command handling.  

As the CS has to scale up to handle thousands of users concurrently (ie: Enterprise sites) then having CUAs all do CAP commands with tiny expected response times becomes a burden to the CS.  There is only so far that relying on very very beefy MP boxes to efficiently handle lots of threads can take us.  

I was merely asking Larry if he thought that the needed to be some way for the CS have some say in the process instead of letting the CUA be the sole source of control when deciding acceptable latency values.  I could see this as a useful GET-CAPABILITY response.  

For example, under light loads the CS would send back "I should be able to process commands with a latency value of 2 seconds just fine." but under peak loads it would send back"I should be able to process commands with a latency value of 40 seconds just fine."  That way the requesting CUA can at least indicate to the CU that operations may take longer or even better, adjust their "Continue for 10 seconds", "Continue for 30 seconds", "Continue for 60 seconds" algorithms that Larry mentioned to accomoate the CS's load.

All this is not unreasonable to consider, especially if we plan to implement this on larger scale systems...  I am merely asking Larry if he thinks its something CAP needs.

> > Or perhaps you are thinking that bounded
> > latency is too much to do and that it should be optional entirely (ie:
> > All CAP commands follow the existing POP3/IMAP/LDAP/etc model of 'Its
> > done when its done and if you dont want to wait then leave.")??
>
> Adding latency is optional.
Yes it is and if the CS is busy processing the unbounded command then its not going to be able to process the ABORT command (see above).  Thats why the peer protocols cited have no ABORT analogs, they simply drop the link and reestablish it.

FMI: Can ABORT be used to cancel commands that have no id-param?   For example, if the CREATE command in Section 10.1.4 has no LATENCY or ID property parameters:

BEGIN:VCALENDAR
PRODID:-//someone's prodid
VERSION:2.0
CMD:CREATE
TARGET:cal.example.com
BEGIN:VAGENDA
CALID:relcalz1
NAME;LANGUAGE=en_US:Bill's Soccer Team
OWNER:bill
CALMASTER:mailto:bill@example.com
TZID:US/Pacific
END:VAGENDA
BEGIN:VAGENDA
CALID:relcalz2
NAME;LANGUAGE=EN-us:Mary's personal calendar
OWNER:mary
CALMASTER:mailto:mary@example.com
TZID:US/Pacific
END:VAGENDA
END:VCALENDAR
Just how would my CUA ABORT it?  CMD:ABORT on the same channel?  Without requireing some form of command concurrent processing or pipelining in the CS, this isnt doable.  The only simple solution is the one used in peer protocols (Disconnect/reconnect/reauthenticate)...

Bruce
PS: In answer to my examples: The former response is the CS's response to the unbounded command and then latter response is the response to the ABORT command; both were taken from draft 10 12Jan2003 examples with just minor tweaks...
==========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005740F685256CC4_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 7 14:52:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19602 for ; Fri, 7 Feb 2003 14:52:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17JbnW21043 for ietf-calendar-bks; Fri, 7 Feb 2003 11:37:49 -0800 (PST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17Jbmd21039 for ; Fri, 7 Feb 2003 11:37:48 -0800 (PST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h17JboI13732 for ; Fri, 7 Feb 2003 11:37:50 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Feb 2003 11:37:49 -0800 Received: from apple.com ([17.112.76.137]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h17Jbnf14457 for ; Fri, 7 Feb 2003 11:37:49 -0800 (PST) Date: Fri, 7 Feb 2003 20:37:48 +0100 Subject: Re: Interop Planning time again Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Olivier Gutknecht To: ietf-calendar@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, On Thursday, Jan 23, 2003, at 15:52 Europe/Paris, pregen@egenconsulting.com wrote: > At this point, we are trying to decide when to do the next Virtual > interop (which can be put together in about a week) or when to do the > onsite interop (which will take a bit longer). We are interested in participating in CALConnect, virtual and/or onsite. Ol. -- Apple Computer, Inc. From owner-ietf-calendar@mail.imc.org Sat Feb 8 19:11:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04090 for ; Sat, 8 Feb 2003 19:11:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h18NwlC14398 for ietf-calendar-bks; Sat, 8 Feb 2003 15:58:47 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h18Nwjd14393 for ; Sat, 8 Feb 2003 15:58:46 -0800 (PST) To: ietf-calendar@imc.org Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Sat, 8 Feb 2003 18:58:47 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 02/08/2003 06:58:49 PM, Serialize complete at 02/08/2003 06:58:49 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI ----- Forwarded by Pat R Egen/Egen Consulting/01 on 02/08/2003 18:58 ----- Internet-Drafts Administrator Sent by: owner-ietf-announce@ietf.org 02/03/2003 07:08 To: IETF-Announce: ; cc: Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003) NOTE: There are two (2) Internet-Draft Cutoff dates February 24th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, February 24th, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, February 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of February 24th will NOT be accepted. March 3rd: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, March 3rd, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_56.html From owner-ietf-calendar@mail.imc.org Wed Feb 12 12:15:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09206 for ; Wed, 12 Feb 2003 12:15:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CGpF024638 for ietf-calendar-bks; Wed, 12 Feb 2003 08:51:15 -0800 (PST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CGpDd24633 for ; Wed, 12 Feb 2003 08:51:13 -0800 (PST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h1CGpFI11692 for ; Wed, 12 Feb 2003 08:51:15 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Feb 2003 08:51:02 -0800 Received: from apple.com ([17.68.41.12]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h1CGp0Q19783 for ; Wed, 12 Feb 2003 08:51:01 -0800 (PST) Date: Wed, 12 Feb 2003 17:51:06 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Relative URI in 2445 ? From: Olivier Gutknecht To: ietf-calendar@imc.org Content-Transfer-Encoding: 7bit Message-Id: <2E1698E7-3EAA-11D7-BA4C-003065EF8304@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Do we accept relative links in URI values in RFC 2445, for instance in ATTACH ? The specification says: Purpose: This value type is used to identify values that contain a uniform resource identifier (URI) type of reference to the property value. Formal Definition: The data type is defined by the following notation: uri = Description: This data type might be used to reference binary information, for values that are large, or otherwise undesirable to include directly in the iCalendar object. The URI value formats in RFC 1738, RFC 2111 and any other IETF registered value format can be specified. Any IANA registered URI format can be used. These include, but are not limited to, those defined in RFC 1738 and RFC 2111. 1738 only covers relative links with the following definition: "In some cases, URLs are used to locate resources that contain pointers to other resources. In some cases, those pointers are represented as relative links where the expression of the location of the second resource is in terms of "in the same place as this one except with the following relative path". Relative links are not described in this document. However, the use of relative links depends on the original URL containing a hierarchical structure against which the relative link is based. Some URL schemes (such as the ftp, http, and file schemes) contain names that can be considered hierarchical; the components of the hierarchy are separated by "/". " My question is: -if- the iCalendar data is stored and referenced through a scheme which is compatible with relative linking (i.e. an ics file on a filesystem file:/home/olg/mycal/ol.ics, or accessed through a http://foobar.com/cals/ol.ics or ftp url, is it correct iCalendar to use a relative URI in an attach property ? A simple scenario could be a ics file with an external attachment expressed as a file: URI then transferred (with the attachment) to a FTP server. Using a relative link here could keep the resource accessible without modification of the original iCalendar data. The problem is that we don't have an explicit notion of a base URI in iCalendar. so that's probably invalid or left to the interpretation of the CUA ? Ol. From owner-ietf-calendar@mail.imc.org Wed Feb 12 13:04:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10428 for ; Wed, 12 Feb 2003 13:04:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CHjFp29510 for ietf-calendar-bks; Wed, 12 Feb 2003 09:45:15 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1CHjEd29506 for ; Wed, 12 Feb 2003 09:45:14 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003021212465924981 for ; Wed, 12 Feb 2003 12:46:59 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Feb 2003 12:42:56 -0500 Message-ID: <3E4A87A0.4000901@centive.com> Date: Wed, 12 Feb 2003 12:42:56 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Relative URI in 2445 ? References: <2E1698E7-3EAA-11D7-BA4C-003065EF8304@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2003 17:42:56.0757 (UTC) FILETIME=[2D6D9250:01C2D2BE] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Olivier Gutknecht wrote: > A simple scenario could be a ics file with an external attachment > expressed as a file: URI then transferred (with the attachment) to a > FTP server. Using a relative link here could keep the resource > accessible without modification of the original iCalendar data. The > problem is that we don't have an explicit notion of a base URI in > iCalendar. so that's probably invalid or left to the interpretation of > the CUA ? I would think so. It's analogous to the case of HTML: HTML permits relative links, but you have to be careful with them when transferring data around. If you mail somebody a page that you see via an http: URL, relative links in the HTML will be invalid unless your MUA either rewrites them or (more commonly) adds a tag. Similarly, a CUA that composes iCalendar with relative URLs has to rewrite those URLs when it sends the iCalendar to any other CUA. As a rule of thumb, I would say that relative URLs are highly unlikely to work in most iCalendar scenarios. They work on a local drive; but very few applications store iCalendar in local files (the only exception I know of is Evolution). They work on an HTTP server; but the only app I know of that stores iCalendar via HTTP is Outlook/Exchange, and that's a private HTTP server whose URLs are not likely to be visible to the iCalendar recipient. If you have a scenario where it's useful to store iCalendar in a local file (despite the performance problems of searching such a store), I'd say you need to assume that URLs to anything outside the iCalendar store will break when you send the iCalendar to anybody else. Personally, I don't think I'd care for a CUA that stored attachments via file: URLs pointing to random places on my hard drive; it reminds me strongly of Eudora, which used to (still does?) strip attachments off of incoming messages and dump them in J. Random Folder. That was always a pain; I much prefer more modern MUAs, which leave the attachments in the messages and parse them out at render time. -- /===========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===========================================================| |"What we have here is a failure to assimilate." --Cool Hand| |Locutius | \===========================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 14 17:56:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08400 for ; Fri, 14 Feb 2003 17:56:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EMmDY24849 for ietf-calendar-bks; Fri, 14 Feb 2003 14:48:13 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EMmCd24845 for ; Fri, 14 Feb 2003 14:48:12 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id h1EMkrH2003984 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 14 Feb 2003 14:47:05 -0800 Message-ID: <3E4D71D8.2090701@Royer.com> Date: Fri, 14 Feb 2003 15:46:48 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Next CAP version soon. Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080408090701030502070609" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080408090701030502070609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have been doing more edits and I had hoped to send a version out today. However my office is moving so it will go out early next week. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080408090701030502070609 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMTQyMjQ2NDhaMCMGCSqGSIb3DQEJBDEWBBRb tZf38vUxkqivXrKu8FL78xNubzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAAyIYf+943pJl Sg+STrjD55ii4caPYIRCHyYwBqpmXrCCv3/1YVtsIT5uUBMoYCW7cw7w63C37asF6JoGNs2i hfUxuXSAiJtGx35Em/ERFwMaQ29geGu/+95uw3nE/ejVKUq2CQfyTI85XlCqKigb+wRv+UPB oIMr5jHCcFUvWjfwJAX0PdL+t0UySXKskYBxHtj+stbq/h61pq0+ju3OKQdwbDnC3CUER67D YWSO4hDJ8oQ8fTZmM6s2/mYy7VNvK4TkTymWU2eTNZ9/LhMmuIQ6/x5L+YJ8ftX5g+YK5c1h ZgLLR6VSForkqXjDgf6QuC42zITKDwP+GsJxtslYaAAAAAAAAA== --------------ms080408090701030502070609-- From owner-ietf-calendar@mail.imc.org Fri Feb 14 18:23:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09097 for ; Fri, 14 Feb 2003 18:23:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ENHwl25570 for ietf-calendar-bks; Fri, 14 Feb 2003 15:17:58 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1ENHvd25565 for ; Fri, 14 Feb 2003 15:17:57 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003021418195328851 for ; Fri, 14 Feb 2003 18:19:53 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Feb 2003 18:15:50 -0500 Message-ID: <3E4D78A6.2020200@centive.com> Date: Fri, 14 Feb 2003 18:15:50 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Next CAP version soon. References: <3E4D71D8.2090701@Royer.com> <3E4D787B.6040304@centive.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2003 23:15:50.0914 (UTC) FILETIME=[03C78E20:01C2D47F] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > Doug Royer wrote: > >> my office is moving > > > I didn't realize you were in California. ;-) > (Didn't mean to send that to the list; I forgot to check the Reply-To:.) -- /===========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===========================================================| |"What we have here is a failure to assimilate." --Cool Hand| |Locutius | \===========================================================/ From owner-ietf-calendar@mail.imc.org Fri Feb 14 18:24:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09144 for ; Fri, 14 Feb 2003 18:24:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ENHOk25552 for ietf-calendar-bks; Fri, 14 Feb 2003 15:17:24 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1ENHNd25548 for ; Fri, 14 Feb 2003 15:17:23 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003021418190919635 for ; Fri, 14 Feb 2003 18:19:10 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Feb 2003 18:15:07 -0500 Message-ID: <3E4D787B.6040304@centive.com> Date: Fri, 14 Feb 2003 18:15:07 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Next CAP version soon. References: <3E4D71D8.2090701@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Feb 2003 23:15:07.0709 (UTC) FILETIME=[EA06FED0:01C2D47E] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > my office is moving I didn't realize you were in California. ;-) -- /===========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===========================================================| |"What we have here is a failure to assimilate." --Cool Hand| |Locutius | \===========================================================/ From owner-ietf-calendar@mail.imc.org Mon Feb 17 20:40:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05742 for ; Mon, 17 Feb 2003 20:40:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1I1VBd15261 for ietf-calendar-bks; Mon, 17 Feb 2003 17:31:11 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1I1VAd15257 for ; Mon, 17 Feb 2003 17:31:10 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1I1UXH2024769 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 Feb 2003 17:31:01 -0800 Message-ID: <3E518CB3.4080006@Royer.com> Date: Mon, 17 Feb 2003 18:30:27 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP 17-FEB-2003 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030708030802060904020200" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030708030802060904020200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The latest edits: http://INET-Consutling.com/cap-17-FEB-2003.txt http://INET-Consutling.com/cap-17-FEB-2003.html http://INET-Consutling.com/cap-17-FEB-2003.diff http://INET-Consutling.com/cap-17-FEB-2003.xml -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030708030802060904020200 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMTgwMTMwMjdaMCMGCSqGSIb3DQEJBDEWBBT5 959K8aaX3vDO4+mILkknafDJaTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAMUJuyQBpr9Le mFVSvMNX6tWDZGSlyluoEr/UOE9GDZ2JNOP6Z7IKPtY3SHfx9HJyX6DdK4n993H3Td5qtTsn 5qlQsu/10HSNBtwH7xzg5Oq7sVZn/bPkDrnKwtBGTbzN2r9IWqEMSITyfpMX7R5po3AoIyPw tl4wD886lu0v0baCtDjEm1vYd+BVNdy4DKaPJmukYFXsuGJqg866O7ZDVbXP5HFwhkAhIogN ihydF/o/y44Ectfr8jMDnLqe//PBrI4uu0MEkU/eLCDDALaAOlrcFkPk/YvgRs46sA7cUazu 3bHgBEOoNOqk7AQDe7xbuSuanI4xPUpfU6yLXdZeRQAAAAAAAA== --------------ms030708030802060904020200-- From owner-ietf-calendar@mail.imc.org Mon Feb 17 20:41:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05771 for ; Mon, 17 Feb 2003 20:41:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1I1XOC15324 for ietf-calendar-bks; Mon, 17 Feb 2003 17:33:24 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1I1XNd15320 for ; Mon, 17 Feb 2003 17:33:23 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1I1X0H2024782 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 Feb 2003 17:33:17 -0800 Message-ID: <3E518D46.50502@Royer.com> Date: Mon, 17 Feb 2003 18:32:54 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [ERROR - resend Fwd: CAP 17-FEB-2003] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040102090108060901070905" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040102090108060901070905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The latest edits: http://INET-Consulting.com/cap-17-FEB-2003.txt http://INET-Consulting.com/cap-17-FEB-2003.html http://INET-Consulting.com/cap-17-FEB-2003.diff http://INET-Consulting.com/cap-17-FEB-2003.xml -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040102090108060901070905 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMTgwMTMyNTVaMCMGCSqGSIb3DQEJBDEWBBQd WAnzrZbEGEKpqBHKqLIuM9xCGjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAE4H3zggHrr/J 6Flj2pzWjYi1u948x71itvVr4FPfd7OH5dTDhXxMX64d0G6KVITwUvc/v8i8SFLhYEXaTmgA xn9qeFP7BGqVPDzft4iEP+VliVVN808hKPhaHM7ODdmt9OyHFaRzpQ/2WSZDR3TQR5a0PMVy sg2ygHIHUi4tvvN8IDtUvpcGy4F9slvm9E0rrNCjMWWXEezSBumyWH9YpnvIPE0zXNoLtnpG tBUN4iBnHNSpQA1Mgt8s1LEdqk9DdC6AJxCzPj06078qz8SL3EaJZkUetzUkWjJLu3XpYuA6 cNWnnSMt+DPzwQmQwAvq+aiteVvB+od21uRZmTXukwAAAAAAAA== --------------ms040102090108060901070905-- From owner-ietf-calendar@mail.imc.org Tue Feb 18 17:52:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10593 for ; Tue, 18 Feb 2003 17:52:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IMh9k18159 for ietf-calendar-bks; Tue, 18 Feb 2003 14:43:09 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IMh8d18155 for ; Tue, 18 Feb 2003 14:43:08 -0800 (PST) In-Reply-To: <20030131080258.GA44085@inet.it> To: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 18 Feb 2003 17:43:05 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/18/2003 05:43:11 PM, Serialize complete at 02/18/2003 05:43:11 PM Content-Type: multipart/alternative; boundary="=_alternative 007C8D7B85256CD1_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007C8D7B85256CD1_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 01/31/2003 03:02:58 AM: Sorry, I was out w/the flu all last week so Im playing catchup again... > This is the text I have in mind: > > 5. When multiple "QUERY" properties are supplied in a single > "VQUERY" component, the results returned are the same as the > results returned for multiple "VQUERY" components having each a > single "QUERY" property and the results are return in the same > order as the "VQUERY" properties were specified in the original > command. I like this. The ordering mandate from the original text was unhelpful IMHO. After all, for the modified example: BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE RECURRENCE-ID >= '20000801T000000Z' AND RECURRENCE-ID <= '20000831T235959Z' AND STATE() = 'BOOKED' QUERY:SELECT * FROM TODO WHERE RECURRENCE-ID >= '20000801T000000Z' AND RECURRENCE-ID <= '20000831T235959Z' AND STATE() = 'BOOKED' END:VQUERY just what good is it really to the CUA? As long as all the VEVENTs and VTODOs are returned, no matter the order, then life is good. > Right now, I have no idea what: > > the results returned are the same as the > results returned for multiple "VQUERY" components having each a > single "QUERY" property > > because we haven't defined that yet (or agreed upon it, for that matter). This simply means (to me at least) that the delete-replys for: BEGIN:VQUERY QUERY:SELECT * FROM VTODO WHERE UID = 'uid123' QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' END:VQUERY would match the delete-replys for: BEGIN:VQUERY QUERY:SELECT * FROM VTODO WHERE UID = 'uid123' END:VQUERY BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' END:VQUERY and for: BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' END:VQUERY BEGIN:VQUERY QUERY:SELECT * FROM VTODO WHERE UID = 'uid123' END:VQUERY Im NOT saying that they would be a octet for octet match; they would be a logical match in that the ordering could be different. Sound correct? > My reading of it was that it added a requirement for keeping results for > different QUERY separater (otherwise how could you possibly order them?) The short citation you included has no mention of ordering so that would not be true. "The results returned" are the delete-reply(s) in the ABNF. So now Im questioning the usefulness of this "either or" design philosphy. From Section 6.1.1: 5: When multiple "QUERY" properties are supplied in a single "VQUERY" component, the results returned are the same as the results returned for multiple "VQUERY" components having each a single "QUERY" property and the results are return in the same order as the "VQUERY" properties were specified in the original command. Since a VQUERY can have multiple QUERYs in it and I can have multiple VQUERYs as well, why do we need to have both?? Why cant we just have 1 VQUERY that has multiple QUERY properties in it and call that good? This would simplify the design. Hmm, perhaps there is just a reason that we need to have both forms that Im just forgetting... > And there's still a mention to ordering, which I'd like to get removed. Agreed. > Uhm yes sorry I overlooked that (maybe because SEARCH doesn't behave like > that: all commands return one match per VREPLY, apart from SEARCH where > it's not clear); but I think I got it right in the code ;-) Please point out the unclearness in the draft so we can fix that! Clarity good, uncertainty bad!! > I think we agree then. So what about we change the text I quoted to: > > 5. When multiple "QUERY" properties are supplied in a single > "VQUERY" component, the results are returned just like they > were matches for a single "VQUERY" component having a single > "QUERY" property. > When multiple "VQUERY" componentns are supplied, the results > are returned just like they were matches for a single "VQUERY" > component having a single "QUERY" property. > > Is that fine with you? I agree. Before we go on Id like an answer to my question above. If we do not need to have both multiple VQUERYs (with single or multiple QUERY properties) AND single VQUERYs with single or multiple QUERY properties then lets simplify the design even more. > > > Now what happens if the query matched the same component? Do we > > > return it in both replies or in one (which one)? > > > > IMHO: The responses should (MUST?) be per unique matching entity. > [...] > > My preference is that we get back 1 XXX-reply per unique affected > > component so 1 delete-vreply per UID in the case of of the DELETE command > > no matter how many VQUERYs or QUERYs match it. > > > > I have a mild aversion to the idea of returning multiple delete-vreplys > > per matching entity because it serves no purpose to tell the CUA "I > > deleted the VEVENT with UID:EVENT1. Oh yeah, I deleted the VEVENT with > > UID:EVENT1 (again)." Does it serve any real purpose? You really cant > > doubly delete it can you? > > I agree. Now can you show me where in the text is that stated? There is no text to the effect I stated. I said "My preference...". Its yours too. So far I dont hear disagreement either so we should put in some explicit text to this effect so noone else has to assume/guess it. I propose inserting at the right place under Section 10. Commands and Responses (Doug's choice) something like: Responses for a given command MUST be per unique matching entity. That is, a command effects an entity only than once per command no matter the number of times the entity matches the QUERY properties in used to select the entity. For example, if a DELETE command used two separate QUERY properties to delete all VEVENTs for last week AND the VEVENT whose UID property was "12345678@fizbin.com" and that VEVENT occured last week then only one delete-reply for that VEVENT MUST be returned. Not all commands need such prose (ie: GENERATE-UID or GET-CAPABILITY), only those that use VQUERYs in them. I just didnt quite know how to best phrase that but Im sure Doug can fix that up. > So just to make sure we agree. From a high level point of view, we basically: > - for each TARGET: > - merge all results from all the QUERYs, keeping only 1 copy of each > - if CMD != SEARCH act on them > - send them back. SEARCH defines the order in which we need to send results > back, the other commands return results in undefined order. Yup, we agree pretty much. Im not sold on 1 tiny bit though: Why does SEARCH need to be special cased? If I do the EXACT same VQUERY for SEARCH that I do for DELETE (see prose above), I would expect to only get back 1 copy of the VEVENT in a XXX-reply. I dont see any need to isolate SEARCH from the rest; the results should always be unique and unordered... (Just how many times would you want to suck that 5M ZIP down over a dialup link if you matched 4 times on one SEARCH??) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007C8D7B85256CD1_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 01/31/2003 03:02:58 AM:
Sorry, I was out w/the flu all last week so Im playing catchup again...

> This is the text I have in mind:
>
>    5.  When multiple "QUERY" properties are supplied in a single
>        "VQUERY" component, the results returned are the same as the
>        results returned for multiple "VQUERY" components having each a
>        single "QUERY" property and the results are return in the same
>        order as the "VQUERY" properties were specified in the original
>        command.
I like this.  The ordering mandate from the original text was unhelpful IMHO.  After all, for the modified example:

BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT * FROM VEVENT
WHERE RECURRENCE-ID >= '20000801T000000Z'
AND RECURRENCE-ID <= '20000831T235959Z'
AND STATE() = 'BOOKED'
QUERY:SELECT * FROM TODO
WHERE RECURRENCE-ID >= '20000801T000000Z'
AND RECURRENCE-ID <= '20000831T235959Z'
AND STATE() = 'BOOKED'
END:VQUERY
just what good is it really to the CUA?  As long as all the VEVENTs and VTODOs are returned, no matter the order, then life is good.

> Right now, I have no idea what:
>
>                            the results returned are the same as the
>        results returned for multiple "VQUERY" components having each a
>        single "QUERY" property
>
> because we haven't defined that yet (or agreed upon it, for that matter).
This simply means (to me at least) that the delete-replys for:

BEGIN:VQUERY
QUERY:SELECT * FROM VTODO WHERE UID = 'uid123'
QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123'
END:VQUERY
would match the delete-replys for:

BEGIN:VQUERY
QUERY:SELECT * FROM VTODO WHERE UID = 'uid123'
END:VQUERY
BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123'
END:VQUERY
and for:

BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123'
END:VQUERY
BEGIN:VQUERY
QUERY:SELECT * FROM VTODO WHERE UID = 'uid123'
END:VQUERY
Im NOT saying that they would be a octet for octet match; they would be a logical match in that the ordering could be different. Sound correct?

> My reading of it was that it added a requirement for keeping results for
> different QUERY separater (otherwise how could you possibly order them?)
The short citation you included has no mention of ordering so that would not be true.   "The results returned" are the delete-reply(s) in the ABNF.

So now Im questioning the usefulness of this "either or" design philosphy.  From Section 6.1.1:

5: When multiple "QUERY" properties are supplied in a single "VQUERY" component, the results returned are the same as the results returned for multiple "VQUERY" components having each a single "QUERY" property and the results are return in the same order as the "VQUERY" properties were specified in the original command.

Since a VQUERY can have multiple QUERYs in it and I can have multiple VQUERYs as well, why do we need to have both??  Why cant we just have 1 VQUERY that has multiple QUERY properties in it and call that good?  

This would simplify the design.  Hmm, perhaps there is just a reason that we need to have both forms that Im just forgetting...

> And there's still a mention to ordering, which I'd like to get removed.
Agreed.

> Uhm yes sorry I overlooked that (maybe because SEARCH doesn't behave like
> that: all commands return one match per VREPLY, apart from SEARCH where
> it's not clear); but I think I got it right in the code ;-)
Please point out the unclearness in the draft so we can fix that!  Clarity good, uncertainty bad!!

> I think we agree then. So what about we change the text I quoted to:
>
>    5.  When multiple "QUERY" properties are supplied in a single
>        "VQUERY" component, the results are returned just like they
>        were matches for a single "VQUERY" component having a single
>        "QUERY" property.
>        When multiple "VQUERY" componentns are supplied, the results
>        are returned just like they were matches for a single "VQUERY"
>        component having a single "QUERY" property.
>
> Is that fine with you?
I agree.  

Before we go on Id like an answer to my question above.  If we do not need to have both multiple VQUERYs (with single or multiple QUERY properties) AND single VQUERYs with single or multiple QUERY properties then lets simplify the design even more.

> > > Now what happens if the query matched the same component? Do we
> > > return it in both replies or in one (which one)?
> >
> > IMHO: The responses should (MUST?) be per unique matching entity.
> [...]
> > My preference is that we get back 1 XXX-reply per unique affected
> > component so 1 delete-vreply per UID in the case of of the DELETE command
> > no matter how many VQUERYs or QUERYs match it.
> >
> > I have a mild aversion to the idea of returning multiple delete-vreplys
> > per matching entity because it serves no purpose to tell the CUA "I
> > deleted the VEVENT with UID:EVENT1.  Oh yeah, I deleted the VEVENT with
> > UID:EVENT1 (again)."  Does it serve any real purpose?  You really cant
> > doubly delete it can you?
>
> I agree. Now can you show me where in the text is that stated?
There is no text to the effect I stated.  I said "My preference...".  Its yours too.  So far I dont hear disagreement either so we should put in some explicit text to this effect so noone else has to assume/guess it.  

I propose inserting at the right place under Section 10. Commands and Responses (Doug's choice) something like:

    Responses for a given command MUST be per unique matching entity.  That is,
    a command effects an entity only than once per command no matter the number
    of times the entity matches the QUERY properties in used to select the
    entity.  For example, if a DELETE command used two separate QUERY properties
    to delete all VEVENTs for last week AND the VEVENT whose UID property was
    "12345678@fizbin.com" and that VEVENT occured last week then only one
    delete-reply for that VEVENT MUST be returned.

Not all commands need such prose (ie: GENERATE-UID or GET-CAPABILITY), only those that use VQUERYs in them.  I just didnt quite know how to best phrase that but Im sure Doug can fix that up.

> So just to make sure we agree. From a high level point of view, we basically:
>  - for each TARGET:
>    - merge all results from all the QUERYs, keeping only 1 copy of each
>    - if CMD != SEARCH act on them
>    - send them back. SEARCH defines the order in which we need to send results
>      back, the other commands return results in undefined order.
Yup, we agree pretty much.  

Im not sold on 1 tiny bit though: Why does SEARCH need to be special cased?  If I do the EXACT same VQUERY for SEARCH that I do for DELETE (see prose above), I would expect to only get back 1 copy of the VEVENT in a XXX-reply.  I dont see any need to isolate SEARCH from the rest; the results should always be unique and unordered...  (Just how many times would you want to suck that 5M ZIP down over a dialup link if you matched 4 times on one SEARCH??)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 007C8D7B85256CD1_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 18 18:10:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10946 for ; Tue, 18 Feb 2003 18:10:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IN3Je18723 for ietf-calendar-bks; Tue, 18 Feb 2003 15:03:19 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IN3Hd18716 for ; Tue, 18 Feb 2003 15:03:18 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 18 Feb 2003 18:03:14 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/18/2003 06:03:20 PM, Serialize complete at 02/18/2003 06:03:20 PM Content-Type: multipart/alternative; boundary="=_alternative 007E65E585256CD1_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007E65E585256CD1_= Content-Type: text/plain; charset="US-ASCII" Doug replied: > As we are not doing transactions there can not be more than > one match in your example provided. Once it is deleted by the 1st QUERY > it could not have existed for the 2nd QUERY to match. (no matter > which one of them you process 1st). As Andrea has pointed out, this is not actually stated in the text and so he inferred that it was possible. I think we all here agree but its just not clear in the draft. > For QUERYs that are not deletes I would say return each VREPLY > that matches the supplied QUERY value. Whats the use of this? If the VEVENT matches any QUERY then it should be sent back; do multiple copies give it any greater emphasis to the user? Would resending the same large ZIP ATTACHment result in anything more than just extra wasted bandwidth? The only justification I could see for sending mulitple XXX-replys was due to different SELECT clauses that may or may not overlap. That is, 1 VQUERY asks for ATTENDEEs and another asks for ATTACHments and VALARMs. However I have to question the Real World usage of this kind of overlapping selection. Yes, its legal to do in CAP (hence why Doug wants it?) BUT realistically speaking how many CUs are going to do a _single_ SEARCH command for "All EVENTs on my calendar for Today" AND "The EVENT whose UID is 12345@Frodo.failed" all the while asking for different sets of properties from each query?? Each of these are really much much more typical as separate actions on the CUs part. Id like to take a simplified approach here since I see no real benefit to over engineering this. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007E65E585256CD1_= Content-Type: text/html; charset="US-ASCII"
Doug replied:
> As we are not doing transactions there can not be more than
> one match in your example provided. Once it is deleted by the 1st QUERY
> it could not have existed for the 2nd QUERY to match. (no matter
> which one of them you process 1st).
As Andrea has pointed out, this is not actually stated in the text and so he inferred that it was possible.  I think we all here agree but its just not clear in the draft.

> For QUERYs that are not deletes I would say return each VREPLY
> that matches the supplied QUERY value.

Whats the use of this?  If the VEVENT matches any QUERY then it should be sent back; do multiple copies give it any greater emphasis to the user?  Would resending the same large ZIP ATTACHment result in anything more than just extra wasted bandwidth?

The only justification I could see for sending mulitple XXX-replys was due to different SELECT clauses that may or may not overlap.  That is, 1 VQUERY asks for ATTENDEEs and another asks for ATTACHments and VALARMs.  However I have to question the Real World usage of this kind of overlapping selection.  Yes, its legal to do in CAP (hence why Doug wants it?) BUT realistically speaking how many CUs are going to do a _single_ SEARCH command for "All EVENTs on my calendar for Today" AND "The EVENT whose UID is 12345@Frodo.failed" all the while asking for different sets of properties from each query??  Each of these are really much much more typical as separate actions on the CUs part.

Id like to take a simplified approach here since I see no real benefit to over engineering this.  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 007E65E585256CD1_=-- From owner-ietf-calendar@mail.imc.org Tue Feb 18 20:37:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14429 for ; Tue, 18 Feb 2003 20:37:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1J1SHM23343 for ietf-calendar-bks; Tue, 18 Feb 2003 17:28:17 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1J1SFd23339 for ; Tue, 18 Feb 2003 17:28:15 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1J1SEb2004283 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 18 Feb 2003 17:28:17 -0800 Message-ID: <3E52DDA9.8050709@Royer.com> Date: Tue, 18 Feb 2003 18:28:09 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: CREATE Command and ordering of responses. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070301030101080206060802" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070301030101080206060802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied: > > As we are not doing transactions there can not be more than > > one match in your example provided. Once it is deleted by the 1st QUERY > > it could not have existed for the 2nd QUERY to match. (no matter > > which one of them you process 1st). > > As Andrea has pointed out, this is not actually stated in the text and > so he inferred that it was possible. I think we all here agree but its > just not clear in the draft. Sure it is: 5. When multiple "QUERY" properties are supplied in a single "VQUERY" component, the results returned are the same as the results returned for multiple "VQUERY" components having each a single "QUERY" property and the results are return in the same order as the "VQUERY" properties were specified in the original command. Except for the fact we are removing 'ordering' (Sorry I missed its removal in this section), if you were to submit two VQUERIES each with a single QUERY the second would not be able to delete the object the 1st VQUERY had deleted. > > For QUERYs that are not deletes I would say return each VREPLY > > that matches the supplied QUERY value. > > Whats the use of this? If the VEVENT matches any QUERY then it should > be sent back; do multiple copies give it any greater emphasis to the > user? Would resending the same large ZIP ATTACHment result in anything > more than just extra wasted bandwidth? It had to do with if you were to submit two VQUERIES each with a single QUERY the second could return the same entries as the first. > The only justification I could see for sending mulitple XXX-replys was > due to different SELECT clauses that may or may not overlap. That is, 1 > VQUERY asks for ATTENDEEs and another asks for ATTACHments and VALARMs. > However I have to question the Real World usage of this kind of > overlapping selection. Yes, its legal to do in CAP (hence why Doug > wants it?) Please don't personalize the issues - this was put in after some objected to multiple QUERYs in a VQUERY. They did not want to be forced to do optimization in the CS. > BUT realistically speaking how many CUs are going to do a > _single_ SEARCH command for "All EVENTs on my calendar for Today" AND > "The EVENT whose UID is 12345@Frodo.failed" all the while asking for > different sets of properties from each query?? Each of these are really > much much more typical as separate actions on the CUs part. > > Id like to take a simplified approach here since I see no real benefit > to over engineering this. At no place in the draft are you required to put multiple QUERYs in a single VQUERY. The simple approach could be to issue multiple VQUERYs and that can also return the items multiple times. The reason multiple QUERYs were added was so that you could get all BOOKED entries for a date range and all UNPROCESSED entries in one round trip. ~Something~ like: QUERY:SELECT * FROM VAGENDA WHERE <...date range...> AND STATE() == 'BOOKED' QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED' It avoided two round trips for what was thought to be a common 1st query after authentication. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070301030101080206060802 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMTkwMTI4MDlaMCMGCSqGSIb3DQEJBDEWBBSl FMBGBC9eWtX2RLFdlgTtxSAtjzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEABNaHSU9kmb0t gZJ/KnviOZnk3Fqb5he6+Z5gVD0uEDE4O09foLFPKT5baA6nOqbPSaISZYiq/9GGBkODjnP6 Iy2GtZq0ZHHPpsKspMgL/Rkt0eQ5vIGyWcgu15Y3jwO8s3mlLw0m805YVISGBIjVBUWznkU0 O9KotWS/2FTdjDXlbdMCkt2uVgiE5TTussn88QgRtDJ2+aAiutFSpDoLwI/KNwC7F9QCgyP4 p0LBpc1poVnQ02fj66fJdUCvqPMntk+vjQBI85KRu6BIGmwdFSENvGA1ITgFwq2e7xFmI0Bg U54Oy40/eE69B9pULJn0qK+a39xc30ZANybv81RfrgAAAAAAAA== --------------ms070301030101080206060802-- From owner-ietf-calendar@mail.imc.org Thu Feb 20 13:41:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24874 for ; Thu, 20 Feb 2003 13:41:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KIP1f27529 for ietf-calendar-bks; Thu, 20 Feb 2003 10:25:01 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KIP0d27523 for ; Thu, 20 Feb 2003 10:25:00 -0800 (PST) In-Reply-To: <20030131082849.GB44085@inet.it> To: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 20 Feb 2003 13:24:58 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/20/2003 01:24:59 PM, Serialize complete at 02/20/2003 01:24:59 PM Content-Type: multipart/alternative; boundary="=_alternative 0065289785256CD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065289785256CD3_= Content-Type: text/plain; charset="US-ASCII" Andrea replied on 01/31/2003 03:28:49 AM: > Now, before I get carried away again: if the consensus is to have > no transactions for now, I'm fine. I think that the general concensus is no transactions. > If you are still interested, read through ;-) Rolling up my sleeves and forging ahead.... > > If ordering by TARGET is important to you then Id say that concurrent > > DELETEs on separate channels is the way you would probably want to go. Or > > am I missing the root of the concern here? > > It's not that which is worrying me, it's a matter of simplicity, > consistency and regression tests to cover all possible cases. If one > implementor gets one of the many cases wrong, we end up facing > hard times... Haha. Have you been trying to do iTIP with Outlook lately? As any long time lurker here can tell you Im a BIG fan of KISS. The more complex and obtuse something gets to do even the simplest tasks is just asking for failure. > > Not quite. I think that atomicity of the command varys with the command. > > For example, a DELETE of a VEVENT in 1 VAGENDA succeeds and a positive > > VREPLY is sent back. Then the attempted deletion of a different VEVENT > > fails. Why should this make the first success now a failure?? > > That's what I say: the CS has no way of kowing, the CUA has some more > hints. It is NOT a matter of hints nor is it the CS concern really. If the 1st VREPLY said I deleted a particluar VEVENT then _why_ would failing to delete a different VEVENT now cause that previous successful deletion to now become a failure? If you use an eraser to remove some text on paper but cannot erase a second block of text, does that mean you did not actually erase the first block of text? Of course not. The first erasure worked, the second did not; its that simple. Besides, what does the CUA need any hints for? It gets the VREPLY with the success or failure REQUEST-STATUS line(s) in it. > > Yeah, so? The 1st and 2nd VAGENDAs allow you write permission so you can > > CREATE the invitation. The 3rd does not (what a weenie for not wanting me > > to access their calendar!). So does that mean that you were unable to > > invite the first 2 people? Certainly not. Does that mean the entire > > CREATE command should be failed? Nope. > > You could argue that and you would be correct. At the same time my HR > manager who just wanted to book the meeting with the 3 guys would arguee > that he wanted to meet all 3 of them, not 2, so the computer failed; > and he'd be correct as well. :-P Its not an issue of "the computer failed", its an issue of how to design CUAs to deal with and represent success and failures in a manner that CUs will expect/want/need. The HR Manager should easily be able to take some corrective action depending on the reason for the failure. User3's calendar could be down for maintenance reasons (ie: compaction, etc.) or the attempt could have been blocked by VCARs or even the Manager somehow specified a TARGET that does not exist even. All are equally plausible reasons for the failure. So just what could/should happen?... The CUA could (should!) clearly indicate the failure in the UI and then let the manager decide what action to take (or take it automatically based on some CU preference/settings). The CU could decide to leave it be and retry User3 later (the first and third causes) or it could indicate a temporary failure in the UI and retry User3 again at some later point. Alternately the CUA could display a warning that the Manager is prohibited from accessing User3's calendar (middle cause) and let the CU decide what to do. If the Manger can invite User1 and User2 then they could just as easily cancel/uninvite them if the manager chose to do so. (I'm excluding the obvious case where a VCAR allows CREATEs where the METHOD != "CANCEL" only because even though its doable its stupid to do so IMNHO for obvious reasons.) The CS is not sentient so it cannot guess what any pariticular CU/CUA wants done in the case of failure like this one. Its something that can only be really accurately controlled by the CU (and by extension their CUA) so I think thats where the control should be; not in the CS but rather in the CUA. > Now seriously: if the CUA gets back the error, it must take corrective > actions. As a minimum it should change the VEVENT to show that the > invitation failed (how?). Thats a UI issue really. Also there is nothing to preclude the CUA from retrying again later (for those cases where failure is due to intermittant causes)... I would assume that most CUAs would have some kind of queue of "things to take care of" so that the CUA can work "off-line" so its logical to say that the CUA would toss User3's invitation back into that queue with some status tracking info for the CUAs use. I do not believe that failure for 1 TARGET is _automatic_ grounds for terminating the entire invitation process or putting it on the CUs own calendar for that matter. > Surely it should ask the CU what to do now. Sure (assuming there are no settings stored somewhere to indicate what kind of action to take already). > Also, as Doug mentioned, > there could be a bot on one of the attendees VAGENDA which could act > immediately on it etc. Thats why the CUA should really CREATE it on the Organizers calendar BEFORE it tries to send out invitations. > So no matter how you look at it, creating an event IS a transaction - > we just get to pick whether it's implemented on the server or on the > client. Creating an event on my calendar and sending an invitation to 3 other users are two separate actions; they SHOULD NOT be combined into 1 'transaction'. Creating invitations for 3 other users has yet to be shown to be necessarily 1 "all or nothing" action that a single command MUST do entirely or must fail entirely. See above. I think that a properly designed CUA should have no problems dealing with the case above; its a matter of making sure the CUA (or CAP) does not combine multiple actions into 1 command. The "Save and Send Invitations" UI button does NOT have to be a single CAP command. UI actions are not (nor should they be) mapped 1-to-1 onto CAP commands. "Retrieve Mail" is a single button/UI action but it translates into several POP3/IMAP4 commands. The same applys to CAP. > for instance, a CUA could first > of all verify that all TARGETs exist, ask the CS if it has access > to them etc. So that it could inform the CU even BEFORE she pressed > the Ok button. Oh boy, this gets into Local and Server directory stuff and thats something Im sure many here would classify as Adminstration. While I concur with you (Im used to Notes which do this) I think we'd be slapped if we go any farther down that path... > In that case, failure would be really an exception. The REQUEST-STATUS from each VREPLY is enough to distinguish intermittant from permanent, User Drain Bamage from Server side failure, etc. Thats what the 1st number in the REQUEST-STATUS was intended for. 2.x was for permanent success, 1.x was for preliminary success, etc. > But as things stand, even something as simple as a mistyped URI could > cause a sequence of CAP commands, failure, phone calls ("look, I'm > trying to accept your meeting proposal, but this darn program keeps > giving me an error message!") etc. How do you handle all this? If your CUA puts a bad address on the ORGANIZER property then its not my CUAs or CSs fault now is it!?! If I misentered the id in my CUA then I would not be able to send you the initial invitation so a REQUEST-STATUS:3.x;Unknown or invalid address;... would be the result my CUA would get back. The 3 value tells the CUA its problem with something it sent. See RFC 2445, Section 4.8.8.2 Request Status: | 3.xx | Client Error. This class of status code | | | indicates that the request was not successful.| | | The error is the result of either a syntax or | | | a semantic error in the client formatted | | | request. Request should not be retried until | | | the condition in the request is corrected. | The more specific values under 3.xx are in iTIP and there should be more in CAP (although I havent checked this bit). The REQUEST-STATUS code in the VREPLY should be crafted by the CS so that its accurate and that it conveys the proper status back to the CUA. This feels more like a discussion on better CUA design at this point though... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0065289785256CD3_= Content-Type: text/html; charset="US-ASCII"
Andrea replied on 01/31/2003 03:28:49 AM:
> Now, before I get carried away again: if the consensus is to have
> no transactions for now, I'm fine.

I think that the general concensus is no transactions.  

> If you are still interested, read through ;-)
Rolling up my sleeves and forging ahead....

> > If ordering by TARGET is important to you then Id say that concurrent
> > DELETEs on separate channels is the way you would probably want to go.  Or
> > am I missing the root of the concern here?
>
> It's not that which is worrying me, it's a matter of simplicity,
> consistency and regression tests to cover all possible cases. If one
> implementor gets one of the many cases wrong, we end up facing
> hard times...
Haha.  Have you been trying to do iTIP with Outlook lately?

As any long time lurker here can tell you Im a BIG fan of KISS.  The more complex and obtuse something gets to do even the simplest tasks is just asking for failure.

> > Not quite.  I think that atomicity of the command varys with the command.
> > For example, a DELETE of a VEVENT in 1 VAGENDA succeeds and a positive
> > VREPLY is sent back.  Then the attempted deletion of a different VEVENT
> > fails.  Why should this make the first success now a failure??
>
> That's what I say: the CS has no way of kowing, the CUA has some more
> hints.
It is NOT a matter of hints nor is it the CS concern really.  If the 1st VREPLY said I deleted a particluar VEVENT then _why_ would failing to delete a different VEVENT now cause that previous successful deletion to now become a failure?  If you use an eraser to remove some text on paper but cannot erase a second block of text, does that mean you did not actually erase the first block of text?  Of course not.  The first erasure worked, the second did not; its that simple.

Besides, what does the CUA need any hints for?  It gets the VREPLY with the success or failure REQUEST-STATUS line(s) in it.

> > Yeah, so?  The 1st and 2nd VAGENDAs allow you write permission so you can
> > CREATE the invitation.  The 3rd does not (what a weenie for not wanting me
> > to access their calendar!).  So does that mean that you were unable to
> > invite the first 2 people?  Certainly not.  Does that mean the entire
> > CREATE command should be failed?  Nope.
>
> You could argue that and you would be correct. At the same time my HR
> manager who just wanted to book the meeting with the 3 guys would arguee
> that he wanted to meet all 3 of them, not 2, so the computer failed;
> and he'd be correct as well. :-P
Its not an issue of "the computer failed", its an issue of how to design CUAs to deal with and represent success and failures in a manner that CUs will expect/want/need.

<Ok, covering this gets a bit into the GUI realm and outside of CAP but Ill continue on.>

The HR Manager should easily be able to take some corrective action depending on the reason for the failure.  User3's calendar could be down for maintenance reasons (ie: compaction, etc.) or the attempt could have been blocked by VCARs or even the Manager somehow specified a TARGET that does not exist even.  All are equally plausible reasons for the failure.  So just what could/should happen?...

The CUA could (should!) clearly indicate the failure in the UI and then let the manager decide what action to take (or take it automatically based on some CU preference/settings).  The CU could decide to leave it be and retry User3 later (the first and third causes) or it could indicate a temporary failure in the UI and retry User3 again at some later point.  Alternately the CUA could display a warning that the Manager is prohibited from accessing User3's calendar (middle cause) and let the CU decide what to do.  

If the Manger can invite User1 and User2 then they could just as easily cancel/uninvite them if the manager chose to do so.  (I'm excluding the obvious case where a VCAR allows CREATEs where the METHOD != "CANCEL" only because even though its doable its stupid to do so IMNHO for obvious reasons.)

The CS is not sentient so it cannot guess what any pariticular CU/CUA wants done in the case of failure like this one.  Its something that can only be really accurately controlled by the CU (and by extension their CUA) so I think thats where the control should be; not in the CS but rather in the CUA.

> Now seriously: if the CUA gets back the error, it must take corrective
> actions. As a minimum it should change the VEVENT to show that the
> invitation failed (how?).

Thats a UI issue really.  Also there is nothing to preclude the CUA from retrying again later (for those cases where failure is due to intermittant causes)...

I would assume that most CUAs would have some kind of queue of "things to take care of" so that the CUA can work "off-line" so its logical to say that the CUA would toss User3's invitation back into that queue with some status tracking info for the CUAs use.

I do not believe that failure for 1 TARGET is _automatic_ grounds for terminating the entire invitation process or putting it on the CUs own calendar for that matter.

>                             Surely it should ask the CU what to do now.
Sure (assuming there are no settings stored somewhere to indicate what kind of action to take already).

>                                                Also, as Doug mentioned,
> there could be a bot on one of the attendees VAGENDA which could act
> immediately on it etc.
Thats why the CUA should really CREATE it on the Organizers calendar BEFORE it tries to send out invitations.

> So no matter how you look at it, creating an event IS a transaction -
> we just get to pick whether it's implemented on the server or on the
> client.
Creating an event on my calendar and sending an invitation to 3 other users are two separate actions; they SHOULD NOT be combined into 1 'transaction'.

Creating invitations for 3 other users has yet to be shown to be necessarily 1 "all or nothing" action that a single command MUST do entirely or must fail entirely.  See above.

I think that a properly designed CUA should have no problems dealing with the case above; its a matter of making sure the CUA (or CAP) does not combine multiple actions into 1 command.  The "Save and Send Invitations" UI button does NOT have to be a single CAP command.  UI actions are not (nor should they be) mapped 1-to-1 onto CAP commands.  "Retrieve Mail" is a single button/UI action but it translates into several POP3/IMAP4 commands.  The same applys to CAP.

>                                     for instance, a CUA could first
> of all verify that all TARGETs exist, ask the CS if it has access
> to them etc. So that it could inform the CU even BEFORE she pressed
> the Ok button.

Oh boy, this gets into Local and Server directory stuff and thats something Im sure many here would classify as Adminstration.  While I concur with you (Im used to Notes which do this) I think we'd be slapped if we go any farther down that path...

>                 In that case, failure would be really an exception.
The REQUEST-STATUS from each VREPLY is enough to distinguish intermittant from permanent, User Drain Bamage from Server side failure, etc.  Thats what the 1st number in the REQUEST-STATUS was intended for.  2.x was for permanent success, 1.x was for preliminary success, etc.

> But as things stand, even something as simple as a mistyped URI could
> cause a sequence of CAP commands, failure, phone calls ("look, I'm
> trying to accept your meeting proposal, but this darn program keeps
> giving me an error message!") etc. How do you handle all this?
If your CUA puts a bad address on the ORGANIZER property then its not my CUAs or CSs fault now is it!?!

If I misentered the id in my CUA then I would not be able to send you the initial invitation so a REQUEST-STATUS:3.x;Unknown or invalid address;... would be the result my CUA would get back.  The 3 value tells the CUA its problem with something it sent.  See RFC 2445, Section 4.8.8.2 Request Status:

     |    3.xx      | Client Error. This class of status code       |
    |              | indicates that the request was not successful.|
    |              | The error is the result of either a syntax or |
    |              | a semantic error in the client formatted      |
    |              | request. Request should not be retried until  |
    |              | the condition in the request is corrected.    |

The more specific values under 3.xx are in iTIP and there should be more in CAP (although I havent checked this bit).

The REQUEST-STATUS code in the VREPLY should be crafted by the CS so that its accurate and that it conveys the proper status back to the CUA.  This feels more like a discussion on better CUA design at this point though...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0065289785256CD3_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 20 14:00:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25479 for ; Thu, 20 Feb 2003 14:00:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KIm2N28333 for ietf-calendar-bks; Thu, 20 Feb 2003 10:48:02 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KIm1d28329 for ; Thu, 20 Feb 2003 10:48:01 -0800 (PST) In-Reply-To: <20030131083903.GD44085@inet.it> To: ietf-calendar@imc.org Subject: Re: No partial success when it comes to deletion? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 20 Feb 2003 13:48:01 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/20/2003 01:47:58 PM, Serialize complete at 02/20/2003 01:47:58 PM Content-Type: multipart/alternative; boundary="=_alternative 0067435E85256CD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067435E85256CD3_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 01/31/2003 03:39:03 AM: > I just want to make sure we all realize avoiding transactions > doesn't avoid the complexity per se, it just moves it to the CUA. > Or, it allows you to write naive CUAs. Its not an issue of being naive; its a matter of good design. CUA designers should not expect to map a single UI action/button to just 1 CAP command. Your "Retrieve Mail" button in Outlook or Netscape Mail do NOT translate into 1 POP3 or IMAP4 command. The same goes for CAP. Perhaps we should add some Design Philosphy/Recomendations to the CAP draft so that CUA and CS designers do not expect 1 command to be the solution to every possible scenario there is or that may arise. As Doug and I already noted some actions should precede others and failure for a latter action does not require undoing previously done actions. > Ok, if this is the consensus I will agree. Sounds like concensus then. (We will of course revisit this in ~11 months when we forgot that we already covered it... ;^) ) > Then I will focus my effort on making sure nothing prevents the CS from > implementing transactions when they are added down the road. Also, I will > start working on a proposal for adding transactions later on. Ok? Id love to read any drafts you have. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0067435E85256CD3_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 01/31/2003 03:39:03 AM:
> I just want to make sure we all realize avoiding transactions
> doesn't avoid the complexity per se, it just moves it to the CUA.
> Or, it allows you to write naive CUAs.
Its not an issue of being naive; its a matter of good design.

CUA designers should not expect to map a single UI action/button to just 1 CAP command.  Your "Retrieve Mail" button in Outlook or Netscape Mail do NOT translate into 1 POP3 or IMAP4 command.  The same goes for CAP.

Perhaps we should add some Design Philosphy/Recomendations to the CAP draft so that CUA and CS designers do not expect 1 command to be the solution to every possible scenario there is or that may arise.  As Doug and I already noted some actions should precede others and failure for a latter action does not require undoing previously done actions.

> Ok, if this is the consensus I will agree.
Sounds like concensus then.  (We will of course revisit this in ~11 months when we forgot that we already covered it... ;^) )

> Then I will focus my effort on making sure nothing prevents the CS from
> implementing transactions when they are added down the road. Also, I will
> start working on a proposal for adding transactions later on. Ok?
Id love to read any drafts you have.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0067435E85256CD3_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 20 15:07:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27820 for ; Thu, 20 Feb 2003 15:07:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KJu7d01046 for ietf-calendar-bks; Thu, 20 Feb 2003 11:56:07 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KJu6d01042 for ; Thu, 20 Feb 2003 11:56:06 -0800 (PST) In-Reply-To: <3E4A87A0.4000901@centive.com> To: ietf-calendar@imc.org Subject: Re: Relative URI in 2445 ? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 20 Feb 2003 14:56:03 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/20/2003 02:56:01 PM, Serialize complete at 02/20/2003 02:56:01 PM Content-Type: multipart/alternative; boundary="=_alternative 006D7F4085256CD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D7F4085256CD3_= Content-Type: text/plain; charset="US-ASCII" John replied on 02/12/2003 12:42:56 PM: > As a rule of thumb, I would say that relative URLs are highly unlikely > to work in most iCalendar scenarios. I guess this also depends on how you contruct the iCalendar data stream. If you constructed the file as a multipart/related MIME message then you could include both the iCalendar object and the referenced ATTACHment data (using CID: URIs). Separating the iCalendar entry from the ATTACHment data is frought with peril; including it in the same data stream is much much safer. > If you have a scenario where it's useful to store iCalendar in a local > file (despite the performance problems of searching such a store), I'd > say you need to assume that URLs to anything outside the iCalendar store > will break when you send the iCalendar to anybody else. Not 100% true. See above. Separating entry from ATTACHment is a receipe for peril when you start to try and preserve linkages. Then again I guess you could make the ATTACHment inline (shudder, did I actually say that!?!?!) but doing so for a, say, big ZIP or MPEG is NOT something that inline ATTACHments were created for. It is legal but its against the intent of inlines... This just goes to show you that there are at least 2 alternatives that help prevent linkage breaks. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D7F4085256CD3_= Content-Type: text/html; charset="US-ASCII"
John replied on 02/12/2003 12:42:56 PM:
> As a rule of thumb, I would say that relative URLs are highly unlikely
> to work in most iCalendar scenarios.  

I guess this also depends on how you contruct the iCalendar data stream.  

If you constructed the file as a multipart/related MIME message then you could include both the iCalendar object and the referenced ATTACHment data (using CID: URIs).  Separating the iCalendar entry from the ATTACHment data is frought with peril; including it in the same data stream is much much safer.

> If you have a scenario where it's useful to store iCalendar in a local
> file (despite the performance problems of searching such a store), I'd
> say you need to assume that URLs to anything outside the iCalendar store
> will break when you send the iCalendar to anybody else.
Not 100% true.  See above.

Separating entry from ATTACHment is a receipe for peril when you start to try and preserve linkages.

Then again I guess you could make the ATTACHment inline (shudder, did I actually say that!?!?!) but doing so for a, say, big ZIP or MPEG is NOT something that inline ATTACHments were created for.  It is legal but its against the intent of inlines...  This just goes to show you that there are at least 2 alternatives that help prevent linkage breaks.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006D7F4085256CD3_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 20 15:37:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28820 for ; Thu, 20 Feb 2003 15:37:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKYKo03117 for ietf-calendar-bks; Thu, 20 Feb 2003 12:34:20 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1KKYJd03113 for ; Thu, 20 Feb 2003 12:34:19 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022015370327849 for ; Thu, 20 Feb 2003 15:37:03 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Feb 2003 15:32:02 -0500 Message-ID: <3E553B42.2050701@centive.com> Date: Thu, 20 Feb 2003 15:32:02 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Relative URI in 2445 ? References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2003 20:32:02.0755 (UTC) FILETIME=[20380130:01C2D91F] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > If you constructed the file as a multipart/related MIME message then > you could include both the iCalendar object and the referenced > ATTACHment data (using CID: URIs). I suppose. But the original question was about file: and http: URLs. -- /==========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |==========================================================| |A man's concepts should exceed his vocabulary, or what's a| |metaphor? | \==========================================================/ From owner-ietf-calendar@mail.imc.org Thu Feb 20 16:03:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29433 for ; Thu, 20 Feb 2003 16:03:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKrKj04569 for ietf-calendar-bks; Thu, 20 Feb 2003 12:53:20 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKrJd04561 for ; Thu, 20 Feb 2003 12:53:19 -0800 (PST) In-Reply-To: <3E518CB3.4080006@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP 17-FEB-2003 MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 20 Feb 2003 15:53:13 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/20/2003 03:53:11 PM, Serialize complete at 02/20/2003 03:53:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0072BB0885256CD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072BB0885256CD3_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 02/17/2003 08:30:27 PM: > The latest edits: > > http://INET-Consutling.com/cap-17-FEB-2003.txt > http://INET-Consutling.com/cap-17-FEB-2003.html > http://INET-Consutling.com/cap-17-FEB-2003.diff > http://INET-Consutling.com/cap-17-FEB-2003.xml 2 quickies: 1: Can we get these mirrored onto the WG site???? 2: Can you please update the other drafts folks may still link to ( http://inet-consulting.com/cap-12-JAN-2003.html) with some text that tells them @ the top "This has been replaced by a newer draft: http://INET-Consutling.com/cap-17-FEB-2003.html"? That way when I use my bookmarks I can see that Im clearly behind the curve and go catch up... Thanks! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0072BB0885256CD3_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 02/17/2003 08:30:27 PM:
> The latest edits:
>
>    http://INET-Consutling.com/cap-17-FEB-2003.txt
>    http://INET-Consutling.com/cap-17-FEB-2003.html
>    http://INET-Consutling.com/cap-17-FEB-2003.diff
>    http://INET-Consutling.com/cap-17-FEB-2003.xml
2 quickies:

1: Can we get these mirrored onto the WG site????
2: Can you please update the other drafts folks may still link to (http://inet-consulting.com/cap-12-JAN-2003.html) with some text that tells them @ the top "This has been replaced by a newer draft: http://INET-Consutling.com/cap-17-FEB-2003.html"?  That way when I use my bookmarks I can see that Im clearly behind the curve and go catch up...

Thanks!

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0072BB0885256CD3_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 20 18:18:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03084 for ; Thu, 20 Feb 2003 18:18:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KNBbQ08145 for ietf-calendar-bks; Thu, 20 Feb 2003 15:11:37 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KNBad08140 for ; Thu, 20 Feb 2003 15:11:37 -0800 (PST) In-Reply-To: <3E52DDA9.8050709@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 20 Feb 2003 17:56:20 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/20/2003 06:11:22 PM, Serialize complete at 02/20/2003 06:11:22 PM Content-Type: multipart/alternative; boundary="=_alternative 007E008E85256CD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007E008E85256CD3_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 02/18/2003 08:28:09 PM: > > > As we are not doing transactions there can not be more than > > > one match in your example provided. Once it is deleted by the 1st QUERY > > > it could not have existed for the 2nd QUERY to match. (no matter > > > which one of them you process 1st). > > > > As Andrea has pointed out, this is not actually stated in the text and > > so he inferred that it was possible. I think we all here agree but its > > just not clear in the draft. > > Sure it is: > > 5. When multiple "QUERY" properties are supplied in a single > "VQUERY" component, the results returned are the same as the > results returned for multiple "VQUERY" components having each a > single "QUERY" property and the results are return in the same > order as the "VQUERY" properties were specified in the original > command. Hmm, sorry but I dont see any prose in the paragraph above that matches what you said in the 1st quoted block above. The paragraph strictly above talks about "the same" results being returned no matter the order of VQUERY/QUERY pairings used. There is nothing saying that results are unique per match that I see... Put another way, that paragraph does not cover the case where the VQUERY/QUERYs overlap in their data sets. What Andrea and I (and you I think) expect is that results are unique per matching entry, not mulitple per any VQUERY/QUERY combinations. > Except for the fact we are removing 'ordering' (Sorry I missed its removal > in this section), if you were to submit two VQUERIES each with a single > QUERY the second would not be able to delete the object the 1st VQUERY > had deleted. Common sense would dictate this but in the past Ive seen some folks a bit less than full of it when interpreting the RFCs. Its not clear in any text Ive seen that the actions based on mulitple VQUERY/QUERYs occur in any particular order or as an amalgum in one big operation. If I were to combine the "All VEVENTs on my calendar for last week" and "VEVENT with UID:12345@qwerty" in a single DELETE command then it is not clear what kind of response(s) would get back when the results form an overlapping case. (That is, UID:12345@qwerty occurred last week.) For example, if the "All VEVENTS" were deleted first with the proper VREPLYs sent back then one _could_ assume that the "VEVENT with UID:12345@qwerty" would return a failure VREPLY. However since there would already have been a success VREPLY for the first QUERY bit the CUA gets mixed messages. If however the CS performs the "VEVENT with UID:12345@qwerty" deletion first and sends back a success VREPLY and then it performs the "All VEVENTS" deletion then no such conflicting VREPLY would be sent back as the entry would have already been removed from consideration. So ordering of the actions seems to have some implicit effect on the expectations. This is why Andrea and I think that a unique response per entry is the proper course to take and the draft should expressly, not implicitly, define this. If that means that we have prose that says "Only a single VREPLY MAY be sent per command per unique entity; mulitple VREPLYs per unique entity MUST NOT be sent per each individual command." then so be it. Perhaps we need to put in some prose to the effect: "No matter the number or combination of VQUERYs and QUERYs, the entire combined result set is acted upon by the command as a whole." so that the proper net effect is acheived and its up to implementors to do it their own private ways. > > > For QUERYs that are not deletes I would say return each VREPLY > > > that matches the supplied QUERY value. > > > > Whats the use of this? If the VEVENT matches any QUERY then it should > > be sent back; do multiple copies give it any greater emphasis to the > > user? Would resending the same large ZIP ATTACHment result in anything > > more than just extra wasted bandwidth? > > It had to do with if you were to submit two VQUERIES each with a single > QUERY the second could return the same entries as the first. Not what I was trying to ask. Put another way: If my first QUERY SELECTed a different or overlapping set of properties to return than my second QUERY would/should I send back 2 different copies of the same entity? Use the 2 QUERYs from above but add different and possibly partially or non-overlapping cap-val values. Is it reasonable to actually send back 2 copies of the same VEVENT (thus possibly wasting the bandwidth) or should the CS send back one amalgumated VEVENT with all the matching requested properties and parameters? I tend to prefer the latter over the former. This may be the approach that would happen if we adopt the "Pool all the matching entries in the QUERYs into 1 result pool and then send back 1 entry per uniqueue entry.", just that the CS would have to merge the SELECTed properties in this case. > Please don't personalize the issues - this was put in after > some objected to multiple QUERYs in a VQUERY. Sorry, not trying to get nasty or anything. > They did not want > to be forced to do optimization in the CS. Not sure I follow a bit here. There is no optimization being done (or mandated) at all if the CS is expected to treat multiple VQUERY/QUERYs in any combination as all identical. The only possible optimization I see is the "return in the same order" clause that we want removed. The current text would allow a CS to just process queries on a first come, first processed basis thus allowing someone to craft a very simple CS quite quickly. It however does not benefit anyone really as the results of this are NOT identical if the ordering of the queries is changed (see above DELETE example). I dont view making the proposed changes Andrea/I made as forcing folks to optimize their CS; I view it as good design. Since some folks here are gung-ho to build their CS on robust RDBMS systems then our changes should make no great burden on them. Even my "pool the result set" idea above is no great burden for them... > > Id like to take a simplified approach here since I see no real benefit > > to over engineering this. > > At no place in the draft are you required to put multiple QUERYs in > a single VQUERY. The simple approach could be to issue multiple > VQUERYs and that can also return the items multiple times. How is having 2 VQUERYs with 1 QUERY each simpler than 1 VQUERY with 2 QUERYs in it? Is it any more efficient to do so? Its certainly more octets on the wire to achieve the _exact_ same results. > The reason multiple QUERYs were added was so that you could get all BOOKED > entries for a date range and all UNPROCESSED entries in one round trip. > ~Something~ like: > > QUERY:SELECT * FROM VAGENDA WHERE <...date range...> > AND STATE() == 'BOOKED' > QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED' > > It avoided two round trips for what was thought to be > a common 1st query after authentication. If I can craft the EXACT same logical query using: BEGIN:VQUERY QUERY:SELECT * FROM VAGENDA WHERE <...date range...> AND STATE() == 'BOOKED' END:VQUERY BEGIN:VQUERY QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED' END:VQUERY with no apparent justification for this then I call this overengineering it. Lets simplify the design to avoid "Well I did it this way only since the spec says I can. I dont care if you only designed your product to do it only another way! kinds of discussions we will eventually run into otherwise. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007E008E85256CD3_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 02/18/2003 08:28:09 PM:
> >  > As we are not doing transactions there can not be more than
> >  > one match in your example provided. Once it is deleted by the 1st QUERY
> >  > it could not have existed for the 2nd QUERY to match. (no matter
> >  > which one of them you process 1st).
> >
> > As Andrea has pointed out, this is not actually stated in the text and
> > so he inferred that it was possible.  I think we all here agree but its
> > just not clear in the draft.
>
> Sure it is:
>
>     5.  When multiple "QUERY" properties are supplied in a single
>         "VQUERY" component, the results returned are the same as the
>         results returned for multiple "VQUERY" components having each a
>         single "QUERY" property and the results are return in the same
>         order as the "VQUERY" properties were specified in the original
>         command.
Hmm, sorry but I dont see any prose in the paragraph above that matches what you said in the 1st quoted block above.  The paragraph strictly above talks about "the same" results being returned no matter the order of VQUERY/QUERY pairings used.  There is nothing saying that results are unique per match that I see...

Put another way, that paragraph does not cover the case where the VQUERY/QUERYs overlap in their data sets.  What Andrea and I (and you I think) expect is that results are unique per matching entry, not mulitple per any VQUERY/QUERY combinations.

> Except for the fact we are removing 'ordering' (Sorry I missed its removal
> in this section), if you were to submit two VQUERIES each with a single
> QUERY the second would not be able to delete the object the 1st VQUERY
> had deleted.
Common sense would dictate this but in the past Ive seen some folks a bit less than full of it when interpreting the RFCs.  

Its not clear in any text Ive seen that the actions based on mulitple VQUERY/QUERYs occur in any particular order or as an amalgum in one big operation.  If I were to combine the "All VEVENTs on my calendar for last week" and "VEVENT with UID:12345@qwerty" in a single DELETE command then it is not clear what kind of response(s) would get back when the results form an overlapping case.  (That is, UID:12345@qwerty occurred last week.)

For example, if the "All VEVENTS" were deleted first with the proper VREPLYs sent back then one _could_ assume that the "VEVENT with UID:12345@qwerty" would return a failure VREPLY.  However since there would already have been a success VREPLY for the first QUERY bit the CUA gets mixed messages.  

If however the CS performs the "VEVENT with UID:12345@qwerty" deletion first and sends back a success VREPLY and then it performs the "All VEVENTS" deletion then no such conflicting VREPLY would be sent back as the entry would have already been removed from consideration.

So ordering of the actions seems to have some implicit effect on the expectations.  This is why Andrea and I think that a unique response per entry is the proper course to take and the draft should expressly, not implicitly, define this.  If that means that we have prose that says "Only a single VREPLY MAY be sent per command per unique entity; mulitple VREPLYs per unique entity MUST NOT be sent per each individual command." then so be it.  Perhaps we need to put in some prose to the effect: "No matter the number or combination of VQUERYs and QUERYs, the entire combined result set is acted upon by the command as a whole." so that the proper net effect is acheived and its up to implementors to do it their own private ways.

> >  > For QUERYs that are not deletes I would say return each VREPLY
> >  > that matches the supplied QUERY value.
> >
> > Whats the use of this?  If the VEVENT matches any QUERY then it should
> > be sent back; do multiple copies give it any greater emphasis to the
> > user?  Would resending the same large ZIP ATTACHment result in anything
> > more than just extra wasted bandwidth?
>
> It had to do with if you were to submit two VQUERIES each with a single
> QUERY the second could return the same entries as the first.
Not what I was trying to ask.  Put another way: If my first QUERY SELECTed a different or overlapping set of properties to return than my second QUERY would/should I send back 2 different copies of the same entity?  Use the 2 QUERYs from above but add different and possibly partially or non-overlapping cap-val values.

Is it reasonable to actually send back 2 copies of the same VEVENT (thus possibly wasting the bandwidth) or should the CS send back one amalgumated VEVENT with all the matching requested properties and parameters?  I tend to prefer the latter over the former.  This may be the approach that would happen if we adopt the "Pool all the matching entries in the QUERYs into 1 result pool and then send back 1 entry per uniqueue entry.", just that the CS would have to merge the SELECTed properties in this case.

> Please don't personalize the issues - this was put in after
> some objected to multiple QUERYs in a VQUERY.

Sorry, not trying to get nasty or anything.

>                                                They did not want
> to be forced to do optimization in the CS.
Not sure I follow a bit here.  

There is no optimization being done (or mandated) at all if the CS is expected to treat multiple VQUERY/QUERYs in any combination as all identical.  The only possible optimization I see is the "return in the same order" clause that we want removed.  The current text would allow a CS to just process queries on a first come, first processed basis thus allowing someone to craft a very simple CS quite quickly.  It however does not benefit anyone really as the results of this are NOT identical if the ordering of the queries is changed (see above DELETE example).  

I dont view making the proposed changes Andrea/I made as forcing folks to optimize their CS; I view it as good design.  Since some folks here are gung-ho to build their CS on robust RDBMS systems then our changes should make no great burden on them.  Even my "pool the result set" idea above is no great burden for them...

> > Id like to take a simplified approach here since I see no real benefit
> > to over engineering this.  
>
> At no place in the draft are you required to put multiple QUERYs in
> a single VQUERY. The simple approach could be to issue multiple
> VQUERYs and that can also return the items multiple times.
How is having 2 VQUERYs with 1 QUERY each simpler than 1 VQUERY with 2 QUERYs in it?  Is it any more efficient to do so?  Its certainly more octets on the wire to achieve the _exact_ same results.

> The reason multiple QUERYs were added was so that you could get all BOOKED
> entries for a date range and all UNPROCESSED entries in one round trip.
>   ~Something~ like:
>
>    QUERY:SELECT * FROM VAGENDA WHERE <...date range...>
>           AND STATE() == 'BOOKED'
>    QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'
>
> It avoided two round trips for what was thought to be
> a common 1st query after authentication.
If I can craft the EXACT same logical query using:

BEGIN:VQUERY
QUERY:SELECT * FROM VAGENDA WHERE <...date range...> AND STATE() == 'BOOKED'
END:VQUERY
BEGIN:VQUERY
QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'
END:VQUERY

with no apparent justification for this then I call this overengineering it.   Lets simplify the design to avoid "Well I did it this way only since the spec says I can.  I dont care if you only designed your product to do it only another way! kinds of discussions we will eventually run into otherwise.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 007E008E85256CD3_=-- From owner-ietf-calendar@mail.imc.org Thu Feb 20 18:19:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03106 for ; Thu, 20 Feb 2003 18:19:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KNBc008149 for ietf-calendar-bks; Thu, 20 Feb 2003 15:11:38 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KNBbd08142 for ; Thu, 20 Feb 2003 15:11:37 -0800 (PST) To: ietf-calendar@imc.org Subject: CAP 10-17FEB03: Stored VAGENDAs? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 20 Feb 2003 18:05:53 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/20/2003 06:11:23 PM, Serialize complete at 02/20/2003 06:11:23 PM Content-Type: multipart/alternative; boundary="=_alternative 007EDF1885256CD3_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007EDF1885256CD3_= Content-Type: text/plain; charset="US-ASCII" I thought we reached WG agreement last month to remove the concept of stored VAGENDAs in CAP 1.0. In the latest draft I still see them in the text: 3.2. Calendar Store Object Model [iCAL] describes components such as events, todos, alarms, and timezones. [CAP] requires additional object infrastructure. In particular, detailed definitions of the containers for events and todos (calendars), access control objects, and a query language. The conceptual model for a calendar store is shown below. The calendar store (VCALSTORE - section 9.2) contains "VCAR"s, "VQUERY"s, "VTIMEZONE"s, "VAGENDA"s and calendar store properties. Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar properties. [Snip] Calendar Store VCALSTORE | +-- properties +-- VCARs +-- VQUERYs +-- VTIMEZONEs +-- VAGENDA | | | +--properties | +--VEVENTs | | | | | +--VALARMs | +--VTODOs | | | | | +--VALARMs | +--VJOURNALs | +--VCARs | +--VTIMEZONEs | +--VQUERYs Please chalk removing this up for the next draft. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007EDF1885256CD3_= Content-Type: text/html; charset="US-ASCII"
I thought we reached WG agreement last month to remove the concept of stored VAGENDAs in CAP 1.0.  In the latest draft I still see them in the text:

3.2.  Calendar Store Object Model

[iCAL] describes components such as events, todos, alarms, and timezones. [CAP] requires additional object infrastructure. In particular, detailed definitions of the containers for events and todos (calendars), access control objects, and a query language.

The conceptual model for a calendar store is shown below. The calendar store (VCALSTORE - section 9.2) contains "VCAR"s, "VQUERY"s, "VTIMEZONE"s, "VAGENDA"s and calendar store properties.

Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar properties.

[Snip]

Calendar Store

VCALSTORE
|
+-- properties
+-- VCARs
+-- VQUERYs
+-- VTIMEZONEs
+-- VAGENDA
|     |
|     +--properties
|     +--VEVENTs
|     |    |
|     |    +--VALARMs
|     +--VTODOs
|     |    |
|     |    +--VALARMs
|     +--VJOURNALs
|     +--VCARs
|     +--VTIMEZONEs
|     +--VQUERYs
Please chalk removing this up for the next draft.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007EDF1885256CD3_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 21 10:33:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03671 for ; Fri, 21 Feb 2003 10:33:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LFN8Q06832 for ietf-calendar-bks; Fri, 21 Feb 2003 07:23:08 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LFN7d06826 for ; Fri, 21 Feb 2003 07:23:07 -0800 (PST) In-Reply-To: <3E553B42.2050701@centive.com> To: ietf-calendar@imc.org Subject: Re: Relative URI in 2445 ? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 21 Feb 2003 10:23:07 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/21/2003 10:22:58 AM, Serialize complete at 02/21/2003 10:22:58 AM Content-Type: multipart/alternative; boundary="=_alternative 00547D2785256CD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00547D2785256CD4_= Content-Type: text/plain; charset="US-ASCII" John responded on 02/20/2003 03:32:02 PM: > I suppose. But the original question was about file: and http: URLs. The original question was about relative URIs (ie: not fully qualified URIs) and not about just file: or http: (or ftp:...) URIs. CIDs are somewhat realtive in that they point to other parts of the same data stream; kind of like a permanently relative URI (if ya squint a bit). In any case, since its possible to craft a .mht file as a file I was merely pointing out that there is NO requirement that the sole data in that file be JUST iCalendar. It is legal and possible to craft the file to be mutltipart internally and thus preserve linkage. (I have sample .mht files from web sites if someone wants to check it out...) Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00547D2785256CD4_= Content-Type: text/html; charset="US-ASCII"
John responded on 02/20/2003 03:32:02 PM:
> I suppose.  But the original question was about file: and http: URLs.
The original question was about relative URIs (ie: not fully qualified URIs) and not about just file: or http: (or ftp:...) URIs.  CIDs are somewhat realtive in that they point to other parts of the same data stream; kind of like a permanently relative URI (if ya squint a bit).

In any case, since its possible to craft a .mht file as a file I was merely pointing out that there is NO requirement that the sole data in that file be JUST iCalendar.  It is legal and possible to craft the file to be mutltipart internally and thus preserve linkage.  (I have sample .mht files from web sites if someone wants to check it out...)

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00547D2785256CD4_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 21 11:56:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06741 for ; Fri, 21 Feb 2003 11:55:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LGnFw10969 for ietf-calendar-bks; Fri, 21 Feb 2003 08:49:15 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LGnDd10955 for ; Fri, 21 Feb 2003 08:49:13 -0800 (PST) To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: CAP 10-17FEB03: Stored VAGENDAs? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 21 Feb 2003 11:49:13 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 02/21/2003 11:49:15 AM, Serialize complete at 02/21/2003 11:49:15 AM Content-Type: multipart/alternative; boundary="=_alternative 005C672685256CD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C672685256CD4_= Content-Type: text/plain; charset="us-ascii" If we reached agreement to remove it, then why do we need to wait a month to remove it? Why not remove it now. Bruce_Kahn@notesdev.ibm.com Sent by: owner-ietf-calendar@mail.imc.org 02/20/2003 18:05 To: ietf-calendar@imc.org cc: Subject: CAP 10-17FEB03: Stored VAGENDAs? I thought we reached WG agreement last month to remove the concept of stored VAGENDAs in CAP 1.0. In the latest draft I still see them in the text: 3.2. Calendar Store Object Model [iCAL] describes components such as events, todos, alarms, and timezones. [CAP] requires additional object infrastructure. In particular, detailed definitions of the containers for events and todos (calendars), access control objects, and a query language. The conceptual model for a calendar store is shown below. The calendar store (VCALSTORE - section 9.2) contains "VCAR"s, "VQUERY"s, "VTIMEZONE"s, "VAGENDA"s and calendar store properties. Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar properties. [Snip] Calendar Store VCALSTORE | +-- properties +-- VCARs +-- VQUERYs +-- VTIMEZONEs +-- VAGENDA | | | +--properties | +--VEVENTs | | | | | +--VALARMs | +--VTODOs | | | | | +--VALARMs | +--VJOURNALs | +--VCARs | +--VTIMEZONEs | +--VQUERYs Please chalk removing this up for the next draft. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005C672685256CD4_= Content-Type: text/html; charset="us-ascii"
If we reached agreement to remove it, then why do we need to wait a month to remove it?  Why not remove it now.


Bruce_Kahn@notesdev.ibm.com
Sent by: owner-ietf-calendar@mail.imc.org

02/20/2003 18:05

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        CAP 10-17FEB03: Stored VAGENDAs?




I thought we reached WG agreement last month to remove the concept of stored VAGENDAs in CAP 1.0.  In the latest draft I still see them in the text:

3.2.  Calendar Store Object Model

[iCAL] describes components such as events, todos, alarms, and timezones. [CAP] requires additional object infrastructure. In particular, detailed definitions of the containers for events and todos (calendars), access control objects, and a query language.

The conceptual model for a calendar store is shown below. The calendar store (VCALSTORE - section 9.2) contains "VCAR"s, "VQUERY"s, "VTIMEZONE"s, "VAGENDA"s and calendar store properties.

Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar properties.

[Snip]

Calendar Store

VCALSTORE
|
+-- properties
+-- VCARs
+-- VQUERYs
+-- VTIMEZONEs
+-- VAGENDA
|     |
|     +--properties
|     +--VEVENTs
|     |    |
|     |    +--VALARMs
|     +--VTODOs
|     |    |
|     |    +--VALARMs
|     +--VJOURNALs
|     +--VCARs
|     +--VTIMEZONEs
|     +--VQUERYs

Please chalk removing this up for the next draft.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 005C672685256CD4_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 21 12:26:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07816 for ; Fri, 21 Feb 2003 12:26:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LHIul11903 for ietf-calendar-bks; Fri, 21 Feb 2003 09:18:56 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LHItd11899 for ; Fri, 21 Feb 2003 09:18:55 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 21 Feb 2003 12:18:53 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/21/2003 12:18:40 PM, Serialize complete at 02/21/2003 12:18:40 PM Content-Type: multipart/alternative; boundary="=_alternative 005F168D85256CD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005F168D85256CD4_= Content-Type: text/plain; charset="US-ASCII" I replied on 02/20/2003 05:56:20 PM > > The reason multiple QUERYs were added was so that you could get all BOOKED > > entries for a date range and all UNPROCESSED entries in one round trip. > > ~Something~ like: > > > > QUERY:SELECT * FROM VAGENDA WHERE <...date range...> > > AND STATE() == 'BOOKED' > > QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED' > > > > It avoided two round trips for what was thought to be > > a common 1st query after authentication. > > If I can craft the EXACT same logical query using: > > BEGIN:VQUERY > QUERY:SELECT * FROM VAGENDA WHERE <...date range...> AND STATE() == 'BOOKED' > END:VQUERY > BEGIN:VQUERY > QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED' > END:VQUERY > > with no apparent justification for this then I call this > overengineering it. Lets simplify the design to avoid "Well I did > it this way only since the spec says I can. I dont care if you only > designed your product to do it only another way! kinds of > discussions we will eventually run into otherwise. I should note here that I do NOT disagree w/Dougs described case; it is prefectly normal and reasonable. However it does not factor in that the data set of results does NOT overlap. The current draft has no mention on the the sole expected behaviour is for the case where QUERYs result in overlapping results. This is what Andrea and I have been trying to point out as needing some more polish. All we want is there to be some explicit description for the behaviour when the results do overlap so we get consistant results no matter the implementation. There, I hope that clarifies the issue. Now I still think that my suggestion of returning 1 result per matching unique entry is the way to go. Is there another way to achieve the same clarity? Im all ears... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005F168D85256CD4_= Content-Type: text/html; charset="US-ASCII"
I replied on 02/20/2003 05:56:20 PM
> > The reason multiple QUERYs were added was so that you could get all BOOKED
> > entries for a date range and all UNPROCESSED entries in one round trip.
> >   ~Something~ like:
> >
> >    QUERY:SELECT * FROM VAGENDA WHERE <...date range...>
> >           AND STATE() == 'BOOKED'
> >    QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'
> >
> > It avoided two round trips for what was thought to be
> > a common 1st query after authentication.
>
> If I can craft the EXACT same logical query using:
>
> BEGIN:VQUERY
> QUERY:SELECT * FROM VAGENDA WHERE <...date range...> AND STATE() == 'BOOKED'
> END:VQUERY
> BEGIN:VQUERY
> QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'
> END:VQUERY
>
> with no apparent justification for this then I call this
> overengineering it.   Lets simplify the design to avoid "Well I did
> it this way only since the spec says I can.  I dont care if you only
> designed your product to do it only another way! kinds of
> discussions we will eventually run into otherwise.

I should note here that I do NOT disagree w/Dougs described case; it is prefectly normal and reasonable.  However it does not factor in that the data set of results does NOT overlap.  The current draft has no mention on the the sole expected behaviour is for the case where QUERYs result in overlapping results.  This is what Andrea and I have been trying to point out as needing some more polish.

All we want is there to be some explicit description for the behaviour when the results do overlap so we get consistant results no matter the implementation.  There, I hope that clarifies the issue.  Now I still think that my suggestion of returning 1 result per matching unique entry is the way to go.  Is there another way to achieve the same clarity?  Im all ears...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 005F168D85256CD4_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 21 13:50:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10860 for ; Fri, 21 Feb 2003 13:50:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LIdjZ17767 for ietf-calendar-bks; Fri, 21 Feb 2003 10:39:45 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LIdid17759 for ; Fri, 21 Feb 2003 10:39:44 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1LIdeb2001470 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Feb 2003 10:39:44 -0800 Message-ID: <3E567267.2050600@Royer.com> Date: Fri, 21 Feb 2003 11:39:35 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020908050608050602060105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020908050608050602060105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It overlaps exactly the same as if two commands have been each done separately - in the case of delete it can not overlap because the 1st would have already deleted any overlaps. Correct? Bruce_Kahn@notesdev.ibm.com wrote: > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020908050608050602060105 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjExODM5MzVaMCMGCSqGSIb3DQEJBDEWBBSr 3cbYHZOsn113C98Dx1UJIb/S2DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAoDZW0q7vWlj9 ZRoOfxMwv/+HXEhULEosoh91pq/pwU8yhH5BZwDec2BlS8SGmaqPDIup1xK6aGFcDS5Ksshp bVVaPkGRSojgSOltFg4te0SxMdsD8IaYOWBkKU6JLUcsji5G4qhcxfU1oRF/Q6l/LRl2Bu7F Jk/ZUEc7060JTJjfo9IlJbU8VIdOAhE82KLj7/qBZvNJKvo3CoqXS+ExkcuQmeh1SlgEEcyR B2/uHptCePb/Lyetd3MI1oz/pWxGeK6GVu8uDHgkb+RPQ9MA3rASyPWqYCmIbWeyCZ8Amegs V5byRT58tuJ2A89z1/gp+k/pXVdfBgzQwEa9XIxGPQAAAAAAAA== --------------ms020908050608050602060105-- From owner-ietf-calendar@mail.imc.org Fri Feb 21 16:00:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14740 for ; Fri, 21 Feb 2003 16:00:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LKspW23876 for ietf-calendar-bks; Fri, 21 Feb 2003 12:54:51 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LKsod23869 for ; Fri, 21 Feb 2003 12:54:50 -0800 (PST) In-Reply-To: <3E567267.2050600@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 21 Feb 2003 15:54:46 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/21/2003 03:54:43 PM, Serialize complete at 02/21/2003 03:54:43 PM Content-Type: multipart/alternative; boundary="=_alternative 0072DA1A85256CD4_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072DA1A85256CD4_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 02/21/2003 01:39:35 PM: > It overlaps exactly the same as if two commands have been > each done separately - in the case of delete it can not > overlap because the 1st would have already deleted any overlaps. > Correct? Not true for the DELETE command. Ok, back to the "All VEVENTS last week" AND "VEVENT with UID:12345@QWERTY" case for this. Ordering here can and will produce DIFFERENT results in the DELETE command: If the "All VEVENTs last week" deletion is done first then there will be a delete-vreply with UID:12345@QWERTY in it and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted. So when the "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:5.x;No such entry! property in it. Hence the CUA gets 2 delete-vreplys for the _same_ UID; one a success and one a failure. If the "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted. So when the "All VEVENTs last week" deletion is done next there would be no additional delete-vreply to send back since the VEVENT was already removed and thus not part of the "last week" set. Hence the CUA gets 1 delete-vreply for the UID; one success and NO failures. Thus ordering here can result in mixed messages to the CUA. If the QUERYs did NOT overlap (as in _your_ example) then there is no problem since there would be no duplication of responses. However when there is overlap we need to have a clear and concise definition for how the processor is to proceed. If the result sets are combined into 1 total set for processing instead of treated as separate actions (since they came on the SAME command its NOT the same scneario as if they were issued separately!) then we would get back 1 response per matching entry (ie: VEVENT above) and there would be no confusion or ambiguity. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0072DA1A85256CD4_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 02/21/2003 01:39:35 PM:
> It overlaps exactly the same as if two commands have been
> each done separately - in the case of delete it can not
> overlap because the 1st would have already deleted any overlaps.
> Correct?
Not true for the DELETE command.  Ok, back to the "All VEVENTS last week" AND "VEVENT with UID:12345@QWERTY" case for this.  Ordering here can and will produce DIFFERENT results in the DELETE command:

  1. If the "All VEVENTs last week" deletion is done first then there will be a delete-vreply with UID:12345@QWERTY in it and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted.  So when the "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:5.x;No such entry! property in it.  Hence the CUA gets 2 delete-vreplys for the _same_ UID; one a success and one a failure.
  2. If the  "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted.  So when the  "All VEVENTs last week" deletion is done next there would be no additional delete-vreply to send back since the VEVENT was already removed and thus not part of the "last week" set.  Hence the CUA gets 1 delete-vreply for the UID; one success and NO failures.

Thus ordering here can result in mixed messages to the CUA.  

If the QUERYs did NOT overlap (as in _your_ example) then there is no problem since there would be no duplication of responses.  However when there is overlap we need to have a clear and concise definition for how the processor is to proceed.

If the result sets are combined into 1 total set for processing instead of treated as separate actions (since they came on the SAME command its NOT the same scneario as if they were issued separately!) then we would get back 1 response per matching entry (ie: VEVENT above) and there would be no confusion or ambiguity.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0072DA1A85256CD4_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 21 17:06:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16651 for ; Fri, 21 Feb 2003 17:06:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLu6P26686 for ietf-calendar-bks; Fri, 21 Feb 2003 13:56:06 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LLu5d26682 for ; Fri, 21 Feb 2003 13:56:05 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1LLu3b2002915 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Feb 2003 13:56:06 -0800 Message-ID: <3E56A06E.3080601@Royer.com> Date: Fri, 21 Feb 2003 14:55:58 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: CREATE Command and ordering of responses. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040401030109000400040602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040401030109000400040602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I still do not follow your point. In a calendar: VEVENT 1 ======== UID:1 SUMMARY:ABC VEVENT 2 ======== UID:2 SUMMARY:ABC If you issue a DELETE with: QUERY:SELECT * FROM VAGENDA WHERE SUMMARY = 'ABC'; Both UID 1 and UID 2 get deleted - agree? If you were instead had issued as SEPARATE commands: QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE 'A%' Then later: QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE '%C' The 1st query would have deleted both. The 2nd query would have not deleted anything. You would get UID:1 and UID:2 listed in the first response. The 2nd response would be empty - no overlap. Just the same as if you had issued the two queries in the same command. Do you agree? Now, instead of DELETE subsitute SEARCH: The 1st query would have returned both UID:1 and UID:2 The 2nd query would have returned both UID:1 and UID:2 They overlap - agree? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040401030109000400040602 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjEyMTU1NThaMCMGCSqGSIb3DQEJBDEWBBTy 9m983X2NHR1e4ub8ESFemcXUxDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEACOaiINkADM+E hARNhi7eY3a3AM/uzI/Fh/gKGecv/GiOPPvx8HEh7O1fW6e7K5fWqwjIZWyHzuUFE91bWYxR uhvy+7BAh6HSHylq15ZGHZz2U76KWO1TVRiSS10pGoa8naBpOSs/tu2WXoNtrCT/0+aLNMFC XkIZlQh1I1Pe5IgCmtFKTU3V5rBjRJ9mo6XKqVgpFnWWSRczW4EkWe/JIXhOvgsZTZ5TP4Ea ssAVdhxOh1vftkyQTtDlMyFLKpphm8GvvP0hWNCwphLrBqP/N8UZNBKXVuJFhzc3Q1NcTcvT m9DHbr+SjCmFD/CbWWLIZCrJzsY0qvRfO6ocIqT99QAAAAAAAA== --------------ms040401030109000400040602-- From owner-ietf-calendar@mail.imc.org Sat Feb 22 20:46:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19081 for ; Sat, 22 Feb 2003 20:46:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1N1XSc22203 for ietf-calendar-bks; Sat, 22 Feb 2003 17:33:28 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1N1XPd22199 for ; Sat, 22 Feb 2003 17:33:25 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1N1XLb2014237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 22 Feb 2003 17:33:24 -0800 Message-ID: <3E5824DC.700@Royer.com> Date: Sat, 22 Feb 2003 18:33:16 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" , "ietf-calendar@imc.org" Subject: REQUEST-STATUS errors and issues for CAP Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080706050805080309060808" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080706050805080309060808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have started adding / checking status code replies for CAP and found 2 issues (detail below). (1) Conflict in iTIP over REQUEST-STATUS - 3.14 and 5.3 codes. See my [NOTE]s below for my proposal. (2) A note that says that REQUEST-STATUS is optional on success. I propose that REQUEST-STATUS not be optional in CAP for replies. --> My comments are marked with [NOTE]. The following REQUEST-STATUS codes are documented in RFC-244[567]: -------------------------------------------------------------------- ICAL / 2445 ICAL: 4.8.8.2 Request Status ... |==============+===============================================| | Short Return | Longer Return Status Description | | Status Code | | |==============+===============================================| | 1.xx | Preliminary success. This class of status | | | of status code indicates that the request has | | | request has been initially processed but that | | | completion is pending. | |==============+===============================================| | 2.xx | Successful. This class of status code | | | indicates that the request was completed | | | successfully. However, the exact status code | | | can indicate that a fallback has been taken. | |==============+===============================================| | 3.xx | Client Error. This class of status code | | | indicates that the request was not successful.| | | The error is the result of either a syntax or | | | a semantic error in the client formatted | | | request. Request should not be retried until | | | the condition in the request is corrected. | |==============+===============================================| | 4.xx | Scheduling Error. This class of status code | | | indicates that the request was not successful.| | | Some sort of error occurred within the | | | calendaring and scheduling service, not | | | directly related to the request itself. | |==============+===============================================| -- [NOTE] The rest of the values used in 2445 are examples and need [NOTE] not be an exact match (by just reading 2445), shown here: Example: The following are some possible examples of this property. The COMMA and SEMICOLON separator characters in the property value are BACKSLASH character escaped because they appear in a text value. REQUEST-STATUS:2.0;Success REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: MAILTO:jsmith@host.com ----------------------------------------------------------------------- ITIP / 2446 [NOTE] Sections 3.2.3 and 3.4.4 seem to conflict with each other [NOTE] and section 3.6 "Status Replies" with respect to error [NOTE] code "5.3". [NOTE] [NOTE] I think that the "5.3" error code in section 3.4.4 of iTIP [NOTE] should say "3.14". Agree? [NOTE] [NOTE] So I propose that in CAP we specify that code '3.14' means [NOTE] that the "Attendee" calendar does not support the ADD method [NOTE] for any component type, and that code "5.3" means that the [NOTE] calendar does not support ANY scheduling - that is NO METHOD [NOTE] values may be deposited in to the calendar. If it is attempted [NOTE] then CS replies with 5.3, and they are not deposited. [NOTE] [NOTE] Existing implementations should not be effected as they [NOTE] do not interact with CAP. I further think we need to [NOTE] specify that CUA's only use 5.3 when the CS does not [NOTE] support ANY scheduling and 3.14 when the CS does not [NOTE] support the ADD method. -- ITIP: 3.2.4 ADD The "UID" must be that of the existing event. If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VEVENT". If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". -- ITIP: 3.4.4 ADD If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VTODO". If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH". -- ITIP: 3.6 Status Replies |==============+============================+=========================| | Short Return | Longer Return Status | Offending Data | | Status Code | Description | | |==============+============================+=========================| | 2.0 | Success. | None. | |==============+============================+=========================| | 2.1 | Success but fallback taken | Property name and value | | | on one or more property | MAY be specified. | | | values. | | |==============+============================+=========================| | 2.2 | Success, invalid property | Property name MAY be | | | ignored. | specified. | |==============+============================+=========================| | 2.3 | Success, invalid property | Property parameter name | | | parameter ignored. | and value MAY be | | | | specified. | |==============+============================+=========================| | 2.4 | Success, unknown non- | Non-standard property | | | standard property ignored. | name MAY be specified. | |==============+============================+=========================| | 2.5 | Success, unknown non | Property and non- | | | standard property value | standard value MAY be | | | ignored. | specified. | |==============+============================+=========================| | 2.6 | Success, invalid calendar | Calendar component | | | component ignored. | sentinel (e.g., BEGIN: | | | | ALARM) MAY be | | | | specified. | |==============+============================+=========================| | 2.7 | Success, request forwarded | Original and forwarded | | | to Calendar User. | caluser addresses MAY | | | | be specified. | |==============+============================+=========================| | 2.8 | Success, repeating event | RRULE or RDATE property | | | ignored. Scheduled as a | name and value MAY be | | | single component. | specified. | |==============+============================+=========================| | 2.9 | Success, truncated end date| DTEND property value | | | time to date boundary. | MAY be specified. | |==============+============================+=========================| | 2.10 | Success, repeating VTODO | RRULE or RDATE property | | | ignored. Scheduled as a | name and value MAY be | | | single VTODO. | specified. | |==============+============================+=========================| | 2.11 | Success, unbounded RRULE | RRULE property name and | | | clipped at some finite | value MAY be specified. | | | number of instances | Number of instances MAY | | | | also be specified. | |==============+============================+=========================| | 3.0 | Invalid property name. | Property name MAY be | | | | specified. | |==============+============================+=========================| | 3.1 | Invalid property value. | Property name and value | | | | MAY be specified. | |==============+============================+=========================| | 3.2 | Invalid property parameter.| Property parameter name | | | | and value MAY be | | | | specified. | |==============+============================+=========================| | 3.3 | Invalid property parameter | Property parameter name | | | value. | and value MAY be | | | | specified. | |==============+============================+=========================| | 3.4 | Invalid calendar component | Calendar component | | | sequence. | sentinel MAY be | | | | specified (e.g., BEGIN: | | | | VTIMEZONE). | |==============+============================+=========================| | 3.5 | Invalid date or time. | Date/time value(s) MAY | | | | be specified. | |==============+============================+=========================| | 3.6 | Invalid rule. | Rule value MAY be | | | | specified. | |==============+============================+=========================| | 3.7 | Invalid Calendar User. | Attendee property value | | | |MAY be specified. | |==============+============================+=========================| | 3.8 | No authority. | METHOD and Attendee | | | | property values MAY be | | | | specified. | |==============+============================+=========================| | 3.9 | Unsupported version. | VERSION property name | | | | and value MAY be | | | | specified. | |==============+============================+=========================| | 3.10 | Request entity too large. | None. | |==============+============================+=========================| | 3.11 | Required component or | Component or property | | | property missing. | name MAY be specified. | |==============+============================+=========================| | 3.12 | Unknown component or | Component or property | | | property found | name MAY be specified | |==============+============================+=========================| | 3.13 | Unsupported component or | Component or property | | | property found | name MAY be specified | |==============+============================+=========================| | 3.14 | Unsupported capability | Method or action MAY | | | | be specified | |==============+============================+=========================| | 4.0 | Event conflict. Date/time | DTSTART and DTEND | | | is busy. | property name and values| | | | MAY be specified. | |==============+============================+=========================| | 5.0 | Request MAY supported. | Method property value | | | | MAY be specified. | |==============+============================+=========================| | 5.1 | Service unavailable. | ATTENDEE property value | | | | MAY be specified. | |==============+============================+=========================| | 5.2 | Invalid calendar service. | ATTENDEE property value | | | | MAY be specified. | |==============+============================+=========================| | 5.3 | No scheduling support for | ATTENDEE property value | | | user. | MAY be specified. | |==============+============================+=========================| -- [NOTE] An interesting note in iTIP about REQUEST-STATUS being optional [NOTE] on success. I propose that in CAP that REQUEST-STATUS be [NOTE] mandatory! iTIP: 4.2.2 Reply To A Group Event Request "B" could have declined the meeting or indicated tentative acceptance by setting the "ATTENDEE" "partstat" parameter to "declined" or "tentative", respectively. Also, "REQUEST-STATUS" is not required in successful transactions. -- iTIP: 5.1.2 Free/Busy-Related Fallbacks Method Fallback -------------- ----------------------------------------------------- PUBLISH Implementations MAY ignore the METHOD type. The REQUEST-STATUS "3.14;Unsupported capability" MUST be returned. REQUEST Implementations MAY ignore the METHOD type. The REQUEST-STATUS "3.14;Unsupported capability" MUST be returned. REPLY Implementations MAY ignore the METHOD type. The REQUEST-STATUS "3.14;Unsupported capability" MUST be returned. -- 5.1.4 Journal-Related Fallbacks Method Fallback -------------- ----------------------------------------------------- PUBLISH Implementations MAY ignore the METHOD type. The REQUEST-STATUS "3.14;Unsupported capability" MUST be returned. ADD Implementations MAY ignore the METHOD type. The REQUEST-STATUS "3.14;Unsupported capability" MUST be returned. CANCEL Implementations MAY ignore the METHOD type. The REQUEST-STATUS "3.14;Unsupported capability" MUST be returned. ----------------------------------------------------------------------- IMIP / 2447 [NOTE] NO 'REQUEST-STATUS' is defined in 2447. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080706050805080309060808 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjMwMTMzMTZaMCMGCSqGSIb3DQEJBDEWBBSI 5SMnypGubWlBfPsZVPxOOCCnuzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAP4JiSr0bpf8m PpXDlje3Z8dCJ/flulq7ILvb30pFaW4NxE8830TJxRHg0eR1MzDbaWT3eKLz4dsM7JYodwKq 6CK06BJda9+X/Tdo1rp0s8ccvij1ULbjPDxV/dZGu+eC77d8xRI3PE58hGjhxgn0qOxmYVXp d8btJ4CyyOQyRoZIB3Dfaiyzyf8m3oRyBYRtvKjZoX7Nf0fQenm/mevuPgWxwysJMshWDefk H6REdPbKJDZZ0qxipDKajlEBhvp8yyj+S6CYUgaYbSdN/RpkCf4t1QT+RY9bfH1/F2nUcMWZ cqGo4mfuKAuTeVfBjq8SZrQlLYj+E2gm0BmpJL0wRwAAAAAAAA== --------------ms080706050805080309060808-- From owner-ietf-calendar@mail.imc.org Sun Feb 23 14:39:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11735 for ; Sun, 23 Feb 2003 14:39:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1NJTt402777 for ietf-calendar-bks; Sun, 23 Feb 2003 11:29:55 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1NJTrd02773 for ; Sun, 23 Feb 2003 11:29:53 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1NJTnb2010220 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 23 Feb 2003 11:29:53 -0800 Message-ID: <3E592128.6060509@Royer.com> Date: Sun, 23 Feb 2003 12:29:44 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP REQUEST-STATUS - update and proposals Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020906060905070307010109" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020906060905070307010109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit One of the tasks that was left to do wih CAP was to fix up the REQUEST-STATUS codes. Here is pass 1 of my proposal. I have attempted to keep them in sync with iCAL and iTIP and I think that many are duplicates and can be eliminated. Comments please. Here (new) means new error code and (modified) means that I have suggested some changes. If the changes are accepted then I'll modify the ABNF to specify the exact syntax including any optional syntax for each of these (or in sets). I also propose that we call all 6.x codes CMD or CS codes and renumber all 6.x, 7.x, 8.x, 9.x, and 10,x codes to be 6.x codes. We may also want to renumber some of these that are not used prior to CAP anyway. Code Description 2.0 Success. The parameters vary with the operation and are specified. 2.0.3 In response to the client issuing an "abort" reply, this reply code indicates that any command currently underway was successfully aborted. (new) 2.0.4 In response to the client issuing an "ASK" reply, this reply code indicates that any command currently underway was successfully stopped and asked if it should continue. 2.1 Success but fallback taken on one or more property values. (modified) Property name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated just as if they were parameters inside of a property including using '=' to separate name from value. (modified) 2.2 Success, unknown property ignored. (modified) Property name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated just as if they were parameters inside of a property. 2.3 Success, invalid property parameter ignored. (modified) Parameter name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. 2.4 Success, unknown non-standard property ignored. (modified) Parameter name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. 2.5 Success, unknown non-standard property value ignored. (modified) Parameter name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. (modified) 2.6 Success, unknown calendar component name ignored. (modified) Calendar component name (VALARM) MAY be specified and if specified MUST be in the 'extdata' segment comma separated. (modified) 2.7 Success, request forwarded to Calendar User. This specifies that in a way unspecified the CS has forwarded the request to another CS for processing. (modified) Original and forwarded caluser addresses MAY be specified and if specified must be in the 'extdata' segment comma separated (oldname=newname). (modified) 2.8 Success, repeating object ignored. Scheduled as a single component. This error can also be used when the RRULE is not usable for any reason. RRULE or RDATE property name and value MAY be specified and if specified must be in the 'extdata' segment comma separated (propname=value). (modified) 2.9 Success, truncated end date time to date boundary. This code MUST BE returned whenever an object has its instances truncated. (modified) DTEND property value MAY be specified and if specified must be in the 'extdata' segment comma separated (DTEND=date/date-time). 2.10 (deleted use 2.8) 2.11 (deleted use 2.9) 3.0 Invalid property name. (modified) Property name MAY be specified and if specified must be in the 'extdata' segment comma separated. 3.1 Invalid property value. (modified) Property name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated just as if they were parameters inside of a property including using '=' to separate name from value. 3.1.4 Capability not supported. 3.2 Invalid property parameter. (modified) Parameter name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. 3.3 Invalid property parameter value. (modified) Parameter name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. 3.4 (deleted - components are not sequenced - assumed to be old text) 3.5 Invalid date or time. (added) Parameter or property name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. (modified) 3.6 Invalid RRULE. (modified) value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. (modified) 3.7 Invalid Calendar User. An object was attempted to be deposited in a calendar that is unrelated to the calendar. For example booking an object where none of the attendees are the owners. Only if this is disallowed by calendar. (modified) Attendee values MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. (modified) 3.8 No authority. Perhaps one or more VCARs deny the operation. (modified) 3.9 Unsupported iCalendar version in VCALENDAR object. (modified) VERSION property name and value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. 3.10 Request entity too large. 3.11 Required component or property missing. (modified) Component or property name MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. (modified - property was deleted from this. For unknown property use - 3.1) 3.12 Unknown component. (modified) Component name MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. 3.13 (deleted use 3.12 and 3.1) 3.14 (deleted use 3.1.4) (modified) 4.0 Event conflict. Date/time is busy and NOCONFLICT set. DTSTART and DTEND property name and values MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. 4.1 Calendar store access denied. 5.0 (deleted - had no defined meaning, use 2.2? ) 5.1 (deleted - use 4.1) 5.2 (deleted - had no defined meaning, use 2.2? ) 5.3 (deleted - use 4.1 or 3.8) (modified) 6.1 TARGET not found. TARGET property value MAY be specified and if they are specified MUST be in the 'extdata' segment comma separated. 6.2 (deleted - use 4.0) (modified) 6.3 Bad CMD args. 6.4 (deleted - use 3.8) 7.0 (deleted - use 2.0.3 or 2.0.4) 8.0 A failure has occurred in the CS that prevents the operation from succeeding. 8.1 A query was performed and the query is too complex for the CS. The operation was not performed. 8.2 (deleted use 3.11) 8.3 A DATETIME value was too far in the future represented on this Calendar. 8.4 A DATETIME value was too far in the past to be represented on this Calendar. 8.5 An attempt was made to create a new object but the unique UID specified is already in use. 9.0 An unrecognized command was received. Or an unsupported command was received. 10.4 The operation has not been performed because it would cause the resources (memory, disk, CPU, etc) to exceed the allocated quota. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020906060905070307010109 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjMxOTI5NDRaMCMGCSqGSIb3DQEJBDEWBBT7 A1Mu5CflznmTLqVUuf+GqnYPdjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAB0onTHejDN9A Hzd1HY7MyPWPWGifp/Wx5lDcaXK1zMaRSA4ijN6F9ojPXDxXU7SFECak4qVUDD9AUrJf+FUm OlekHwYkid69v/OZSpvSuFDRGQLVL9lfXuAc2OnkzZdS5+6JU+RgYoBfoShNAN5ZC8vYMBE2 RXTeH/ssKvBint5EuPNmUpfMEiI+nLVTaFVcImfcbdUQ45kzTLmaBoBQ72X/0bwimeu7EU1M Bvx8q067pDQxn+p72N4KeJuWOBOWALtB2axt5h7pHpGI/y/1RpHpMJPjGB4HXN2FTPB7gfrm 4An3ZdDnfUnndHJNCeDO+F2YhiSjNJ3cscZWA29mAAAAAAAAAA== --------------ms020906060905070307010109-- From owner-ietf-calendar@mail.imc.org Sun Feb 23 20:25:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16712 for ; Sun, 23 Feb 2003 20:25:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1O1Iit12361 for ietf-calendar-bks; Sun, 23 Feb 2003 17:18:44 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1O1Ihd12357 for ; Sun, 23 Feb 2003 17:18:43 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 7280A4F2B for ; Sun, 23 Feb 2003 20:18:12 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: RFC: UTF-8 iCalendar bug solution Date: Sun, 23 Feb 2003 20:18:26 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200302232018.26629.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, I don't claim to know didly about character sets, but that hasn't stopped me before so... I would like to state some problems with rfc2445 wrt character sets and propose a solution. The problems: Problem 1: The current iCalendar specification states that UTF-8 is the default character set, yet does not allow all UTF-8 characters. Problem 2: Since UTF-8 characters are often 1, 2, and 3 bytes we need to make alterations to the RFC. Put another way, if the RFC is written to support a default character set that can have 3 byte characters then defining things like NON-US-ASCII to be "%x80-F8" is broken and needs fixing. #1 in more detail: (Quote from the spec as a reminder that UTF-8 is the default charset) 4.1.4 Character Set There is not a property parameter to declare the character set used in a property value. The default character set for an iCalendar object is UTF-8 as defined in [RFC 2279]. Note that the definition of NON-US-ASCII is %x80-F8. This excludes the following characters: 371 249 F9 ù LATIN SMALL LETTER U WITH GRAVE 372 250 FA ú LATIN SMALL LETTER U WITH ACUTE 373 251 FB û LATIN SMALL LETTER U WITH CIRCUMFLEX 374 252 FC ü LATIN SMALL LETTER U WITH DIAERESIS 375 253 FD ý LATIN SMALL LETTER Y WITH ACUTE 376 254 FE þ LATIN SMALL LETTER THORN 377 255 FF ÿ LATIN SMALL LETTER Y WITH DIAERESIS F.E. this (VEVENT holiday) summary is not allowed in iCalendar (%xFA): SUMMARY:Proclamação da República A quick fix might be to change NON-US-ASCII to "%x80-FF" but since this only deals with a single character and does not handle every 2+ byte UTF-8 character this isn't good enough. A unified solution is presented at the bottom. #2 in more detail Note the following definition (and comment): TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B %x5D-7E / NON-US-ASCII ; Any character except CTLs not needed by the current ; character set, DQUOTE, ";", ":", "\", "," Note: Certain other character sets may require modification of the above definitions, but this is beyond the scope of this document. This is just another example of a range of characters that ignores the range of the UTF-8 character set. Notice the "Note:". Also note that the problem and solution presented here do not fall into the "other character sets" category (they fall into the default "supported character sets" category). The solution to problems 1 and 2: Change all 8-bit byte values to 16-bit byte values like this: NON-US-ASCII = \u0080 - \uffff If an RFC is going to state that UTF-8 is supported (which they must IMHO) then at the very least it MUST define all characters and character ranges in a minimum of 16-bit values. It should be noted that several commercial packages already seem to be redefining character ranges to 16-bit values and are creating public iCalendars that are actually using 2 and 3 byte UTF-8 codes for summary text. IMHO this is the right thing to do. Various commercial packages have tweaked the spec for other reasons and I agree for tweaking it for UTF-8. I would like to propose the RFC be modified accordingly. Comments please. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 11:43:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18559 for ; Mon, 24 Feb 2003 11:43:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OGRVQ13571 for ietf-calendar-bks; Mon, 24 Feb 2003 08:27:31 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OGRUd13565 for ; Mon, 24 Feb 2003 08:27:30 -0800 (PST) In-Reply-To: <3E56A06E.3080601@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 10: CREATE Command and ordering of responses. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 24 Feb 2003 11:27:29 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/24/2003 11:27:21 AM, Serialize complete at 02/24/2003 11:27:21 AM Content-Type: multipart/alternative; boundary="=_alternative 005A514C85256CD7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005A514C85256CD7_= Content-Type: text/plain; charset="US-ASCII" Doug said on 02/21/2003 04:55:58 PM: > If you issue a DELETE with: > > QUERY:SELECT * FROM VAGENDA WHERE SUMMARY = 'ABC'; > > Both UID 1 and UID 2 get deleted - agree? Yup. > If you were instead had issued as SEPARATE commands: > > QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE 'A%' > > Then later: > QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE '%C' > > The 1st query would have deleted both. > The 2nd query would have not deleted anything. [Snip] > Do you agree? Yes. The first query would result in 2 delete-vreplys being sent back; both with REQUEST-STATUS;2.0 on them and each with the proper UIDs. The second query would result in 1 delete-vreply being sent back; most likely with a REQUEST-STATUS;4.x;No matches found and NO UIDs. Actually I think it is NOT currently doable given the current DELETE ABNF in the 17Feb2003 Draft: delete-reply = "BEGIN" ":" "VCALENDAR" CRLF calprops ; MUST include 'reply-cmd' 1*(delete-vreply) "END" ":" "VCALENDAR" CRLF delete-vreply = "BEGIN" ":" "VREPLY" CRLF deleted-id request-status "END" ":" "VREPLY" CRLF ; Where the id is appropriate for the ; type of object deleted: ; ; VAGENDA = calid ; VCAR = carid ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid ; VQUERY = queryid ; ALARM = sequence ; VTIMEZONE = tzid ; x-component = x-id ; An instance = uid recurid ; deleted-id = ( calid / carid / uid / uid recurid / queryid / tzid / sequence / x-id ) As you will note, the deleted-id MUST be in the delete-vreply but there are NONE to return in the case where none match. So I think we found a flaw in the ABNF. The ABNF needs to be amended so that its permissable to return a REQUEST-STATUS but NO deleted-id for those cases where none match!! Better add this to the CAP issues list before we forget it. The above was done on separate DELETE commands. The ordering of querys in the SAME command would probably have the same results. However you did not address my cases where it can be shown that the ordering of the querys in the SAME command WILL generate different and conflicting results. Your cases are generic enough because they deal with pools of entries rather than pools and specific entries. My example of "All events last week" and "VEVENT with UID:12345@QWERTY" is 100% legal and it deals with the case where the 2nd querys delete-vreply WOULD have a UID on it to match it to my QUERYs SELECT information. For this kind of case we can potentially get mulitple delete-vreplys for the same UID in the _SAME_ command with _different_ REQUEST-STATUSs. So what is the CUA to make of that?? This is why I think we need to simplify the approach as I already described. That way we do not generate potentially conflicting information on the SAME command. Lets revisit my case of the "All VEVENTS last week" AND "VEVENT with UID:12345@QWERTY" to also look at the separate command case too. First, the ordering here can and will produce DIFFERENT results in a single DELETE command: 1. If the "All VEVENTs last week" deletion is done first then there will be a delete-vreply with UID:12345@QWERTY in it and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted. So when the "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:5.x;No such entry! property in it. Hence the CUA gets 2 delete-vreplys for the _same_ UID; one a success and one a failure. 2. If the "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted. So when the "All VEVENTs last week" deletion is done next there would be no additional delete-vreply to send back since the VEVENT was already removed and thus not part of the "last week" set. Hence the CUA gets 1 delete-vreply for the UID; one success and NO failures. Thus ordering here can result in mixed messages to the CUA. Right? If the 2 were done in separate DELETE commands the results would be as follows: If the "All VEVENTs last week" deletion is done first , there will be a delete-vreply with UID:12345@QWERTY in it and a "REQUEST-STATUS:2.0;The events gone!" property so the CUA can see that it was deleted. Then if the CUA decided to ignore the fact that it just got a delete-vreply for UID:12345@QWERTY it could just blindly try to expressly DELETE it. For that separate DELETE command it would get back a separate delete-verply with UID:12345@QWERTY and a REQUEST-STATUS:5.x;No such entry! property in it. As such it got back 2.0 on one attempt and 5.x on another; NO conflicting information really (just a dumb CUA to try and reDELETE something it was just told was DELETEd! If the "VEVENT with UID:12345@QWERTY" deletion is done first there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The events gone! property so the CUA can see that it was deleted. When the "All VEVENTs last week" deletion is tried later there would be no delete-vreply with UID:12345@QWERTY in it since the VEVENT was already removed. The CUA again does NOT percieve a conflict as it did not get back a "Could not DELETE UID:12345@QWERTY" response in the latter case as it was not there to delete nor would there be any way to SELECT it from the pool of existing VEVENTs. So by looking at the cases of sequencing of multiple QUERYs within a _single_ it can be demonstrated that ordering WILL result in conflicting result information in some cases when done on the SAME command. Did I miss anything that would make my example analysis wrong? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005A514C85256CD7_= Content-Type: text/html; charset="US-ASCII"
Doug said on 02/21/2003 04:55:58 PM:
> If you issue a DELETE with:
>
>       QUERY:SELECT * FROM VAGENDA WHERE SUMMARY = 'ABC';
>
> Both UID 1 and UID 2 get deleted - agree?
Yup.

> If you were instead had issued as SEPARATE commands:
>
>       QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE 'A%'
>
> Then later:
>       QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE '%C'
>
> The 1st query would have deleted both.
> The 2nd query would have not deleted anything.
[Snip]
> Do you agree?
Yes.

The first query would result in 2 delete-vreplys being sent back; both with REQUEST-STATUS;2.0 on them and each with the proper UIDs.  

The second query would result in 1 delete-vreply being sent back; most likely with a REQUEST-STATUS;4.x;No matches found and NO UIDs.  Actually I think it is NOT currently doable given the current DELETE ABNF in the 17Feb2003 Draft:

delete-reply   = "BEGIN" ":" "VCALENDAR" CRLF
                calprops   ; MUST include 'reply-cmd'
                1*(delete-vreply)
                "END" ":" "VCALENDAR" CRLF

delete-vreply  = "BEGIN" ":" "VREPLY" CRLF
                deleted-id
                request-status
                "END" ":" "VREPLY" CRLF

               ; Where the id is appropriate for the
               ; type of object deleted:
               ;
               ; VAGENDA = calid
               ; VCAR = carid
               ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
               ; VQUERY = queryid
               ; ALARM = sequence
               ; VTIMEZONE = tzid
               ; x-component = x-id
               ; An instance = uid recurid
               ;
deleted-id    = ( calid / carid / uid / uid recurid
              / queryid / tzid / sequence / x-id )
As you will note, the deleted-id MUST be in the delete-vreply but there are NONE to return in the case where none match.  So I think we found a flaw in the ABNF.  The ABNF needs to be amended so that its permissable to return a REQUEST-STATUS but NO deleted-id for those cases where none match!!  Better add this to the CAP issues list before we forget it.

The above was done on separate DELETE commands.  The ordering of querys in the SAME command would probably have the same results.

However you did not address my cases where it can be shown that the ordering of the querys in the SAME command WILL generate different and conflicting results.

Your cases are generic enough because they deal with pools of entries rather than pools and specific entries.  My example of "All events last week" and "VEVENT with UID:12345@QWERTY" is 100% legal and it deals with the case where the 2nd querys delete-vreply WOULD have a UID on it to match it to my QUERYs SELECT information.  

For this kind of case we can potentially get mulitple delete-vreplys for the same UID in the _SAME_ command with _different_ REQUEST-STATUSs.  So what is the CUA to make of that??  

This is why I think we need to simplify the approach as I already described.  That way we do not generate potentially conflicting information on the SAME command.

Lets revisit my case of the "All VEVENTS last week" AND "VEVENT with UID:12345@QWERTY" to also look at the separate command case too.

First, the ordering here can and will produce DIFFERENT results in a single DELETE command:

1.        If the "All VEVENTs last week" deletion is done first then there will be a delete-vreply with UID:12345@QWERTY in it and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted.  So when the "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:5.x;No such entry! property in it.  Hence the CUA gets 2 delete-vreplys for the _same_ UID; one a success and one a failure.
2.        If the  "VEVENT with UID:12345@QWERTY" deletion is tried there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see that it was deleted.  So when the  "All VEVENTs last week" deletion is done next there would be no additional delete-vreply to send back since the VEVENT was already removed and thus not part of the "last week" set.  Hence the CUA gets 1 delete-vreply for the UID; one success and NO failures.

Thus ordering here can result in mixed messages to the CUA.   Right?

If the 2 were done in separate DELETE commands the results would be as follows:

If the "All VEVENTs last week" deletion is done first , there will be a delete-vreply with UID:12345@QWERTY in it and a "REQUEST-STATUS:2.0;The events gone!" property so the CUA can see that it was deleted.   Then if the CUA decided to ignore the fact that it just got a  delete-vreply for UID:12345@QWERTY it could just blindly try to expressly DELETE it.  For that separate DELETE command it would get back a separate delete-verply with UID:12345@QWERTY and a REQUEST-STATUS:5.x;No such entry! property in it.  As such it got back 2.0 on one attempt and 5.x on another; NO conflicting information really (just a dumb CUA to try and reDELETE something it was just told was DELETEd!

If the  "VEVENT with UID:12345@QWERTY" deletion is done first there will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The events gone! property so the CUA can see that it was deleted.   When the  "All VEVENTs last week" deletion is tried later there would be no delete-vreply with UID:12345@QWERTY in it since the VEVENT was already removed.  The CUA again does NOT percieve a conflict as it did not get back a "Could not DELETE UID:12345@QWERTY" response in the latter case as it was not there to delete nor would there be any way to SELECT it from the pool of existing VEVENTs.

So by looking at the cases of sequencing of multiple QUERYs within a _single_ it can be demonstrated that ordering WILL result in conflicting result information in some cases when done on the SAME command.

Did I miss anything that would make my example analysis wrong?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005A514C85256CD7_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 12:00:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19066 for ; Mon, 24 Feb 2003 12:00:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OGmeo14282 for ietf-calendar-bks; Mon, 24 Feb 2003 08:48:40 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OGmcd14278 for ; Mon, 24 Feb 2003 08:48:38 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1OGmZb2019244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Feb 2003 08:48:38 -0800 Message-ID: <3E5A4CDD.8010801@Royer.com> Date: Mon, 24 Feb 2003 09:48:29 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050704000103020206090900" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050704000103020206090900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit In all uses of the 'NON-US-ASCII' ABNF definition in 2445 it allows for zero or MORE octets. It looks to me as if it does allow for 1 or more octet (multibyte) characters. Assuming you are correct and it should be %x80-FF, that looks to me as if it would solve the problem by changing that alone. Have you verified that all of the valid UTF-8 octet sequences that can include 0xF9-FF are printable (not control) characters? If not we would have to also exclude those characters sequences. Changing from UTF-8 to UTF-16 (which I think is your proposal) would break existing iMIP implementations. If you are talking about the standard multibyte to wide charset translation functions you are talking about changing the charset definition from ASCII valid to ASCII not valid. Although numerically 'A' == 0x41 == 0x0041, in the UTF-8 charset the sequence 0x0041 != 'A'. When using standard string functions existing implementations would break. If an existing implementation internally already used standard multibyte to wide character conversion functions, then when it converted to wide characters (not knowing it already was as you propose) and it got a a sequence of 0x0041, it would stop the conversion of UTF-8 at the 0x00 octet and never see the 'A' character. And for implementations that use multibyte (non-wide char) aware string functions, they would expect UTF-8 and again would stop at the 0x00 octet never seeing the 'A'. Mark Swanson wrote: > > #1 in more detail: > > (Quote from the spec as a reminder that UTF-8 is the default charset) > > 4.1.4 Character Set > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > object is UTF-8 as defined in [RFC 2279]. > > > Note that the definition of NON-US-ASCII is %x80-F8. This excludes the > following characters: > > ... > > A quick fix might be to change NON-US-ASCII to "%x80-FF" but since this only > deals with a single character and does not handle every 2+ byte UTF-8 > character this isn't good enough. A unified solution is presented at > the bottom. All instances of the ABNF that use NON-US-ASCII ABNF definition use * which allows for ZERO or more octets. > > #2 in more detail > > Note the following definition (and comment): > > > Change all 8-bit byte values to 16-bit byte values like this: > > NON-US-ASCII = \u0080 - \uffff Which is UTF-16 - correct? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050704000103020206090900 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjQxNjQ4MjlaMCMGCSqGSIb3DQEJBDEWBBSz xIe+vbdd75M2Z+Mrl0j4XQsFBTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAbHeNZWNEbVZ6 WB3GPCbSoGIIwQ5+H8Pn4WzAupjcWG+aa4vuGkj64V+LH+bBl20jw8HIc038RisEVBmFGJfJ ZlJDqlq28qQLhS9lNsf/7u/WTulpomO1M8cH31wbcohYwepY8whLX2rMduMFDZ20wKlI4c+0 WcVXE2dHX7Jtuuh1+uq+HC7YYqwYX2UCCPF/D6qxez03KYMU8Y5rn9RLP4MREN/z4DvPgT01 RhYQiNxlsUx90goZTcohDNwSF62ynb3AyxPWhqhzrNlA8zNTXnPgDEqxgqaLeHKiqEIL38oX C9YFMG2w7Vz3i0L7MPBYdtof/+20cXHghzKpVLyccwAAAAAAAA== --------------ms050704000103020206090900-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 12:01:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19104 for ; Mon, 24 Feb 2003 12:01:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OGuDh14562 for ietf-calendar-bks; Mon, 24 Feb 2003 08:56:13 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OGu5d14555 for ; Mon, 24 Feb 2003 08:56:07 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 090EA4F2B for ; Mon, 24 Feb 2003 11:55:32 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Q: Outlook conformance (CLASS) Date: Mon, 24 Feb 2003 11:54:17 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302241154.17592.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, Below is a snippet of iCalendar text that Outlook created. Outlook seems to create this on every meeting request. This was sent to me and I do not know what version of Outlook was used (though very likely a recent version). It seems to me that the CLASS property needs a value. Since we all want to be able to parse each others RFC 2445 messages I was wondering how everyone else here was handling this error? Thanks. BEGIN:VEVENT DTSTAMP:20030113T175450Z DTSTART;TZID="Eastern Time (US & Canada)":20030114T100000 SEQUENCE:0 PRIORITY:5 CLASS: CREATED:20030113T175450Z LAST-MODIFIED:20030113T175501Z STATUS:CONFIRMED END:VEVENT -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 12:29:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19780 for ; Mon, 24 Feb 2003 12:29:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHH8j15116 for ietf-calendar-bks; Mon, 24 Feb 2003 09:17:08 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHH7d15112 for ; Mon, 24 Feb 2003 09:17:07 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1OHH4b2019451 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Feb 2003 09:17:07 -0800 Message-ID: <3E5A538B.9010302@Royer.com> Date: Mon, 24 Feb 2003 10:16:59 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: CREATE Command and ordering of responses. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020709040101080903070207" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020709040101080903070207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > As you will note, the deleted-id MUST be in the delete-vreply but there > are NONE to return in the case where none match. So I think we found a > flaw in the ABNF. The ABNF needs to be amended so that its permissable > to return a REQUEST-STATUS but NO deleted-id for those cases where none > match!! Better add this to the CAP issues list before we forget it. I edited the text, I added the last sentence in the following paragraph and changed '1*(delete-vreply)' to '*(delete-vreply)' in the ABNF. When components are deleted, only the top most component "REQUEST-STATUS" properties are returned. No "REQUEST-STATUS" properties are returned for components inside of the selected components. There MUST BE one "VREPLY" component returned for each object that is deleted or marked for delete. Note that if there are no "VREPLY" components then nothing matched and nothing was deleted. ... delete-reply = "BEGIN" ":" "VCALENDAR" CRLF calprops ; MUST include 'reply-cmd' *(delete-vreply) "END" ":" "VCALENDAR" CRLF -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020709040101080903070207 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjQxNzE2NTlaMCMGCSqGSIb3DQEJBDEWBBR1 PxA++GJgMvYgtokoYXUC9MpnPTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAKIhsE0H1mbHn I728zGj1Asu3uo1Ltcs70j+dDgupucNqkO7YXGSG72IMOVWoOu5/IKrQaoVMTDM5mG9JhrsB rucy5i9A7L7yOJF5pjERrhHc1G9UuSPBSGSNxvPke/5roUO8/nhhxSusijnDeznIypSmYer8 oxeRP4O+TJC89JsdfgtvFFd9Eluwjor1KrE+d0E4utSLvgn0/HaDeJUhAPjupNa/jYS24J54 p+xnPNlyAaes4AiEscqR7dSTCLgGvq1Ib9STFG0/tJIX392jRf0evFzwcwXjYidHtttjla21 RhVUOJ/9lvdf8Wk9qxEsrY2C0TEWpBgASJpDi/9GMwAAAAAAAA== --------------ms020709040101080903070207-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 12:33:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19847 for ; Mon, 24 Feb 2003 12:33:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHN2B15352 for ietf-calendar-bks; Mon, 24 Feb 2003 09:23:02 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHN1d15348 for ; Mon, 24 Feb 2003 09:23:01 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1OHMwb2019494 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Feb 2003 09:23:01 -0800 Message-ID: <3E5A54ED.70503@Royer.com> Date: Mon, 24 Feb 2003 10:22:53 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP 10: CREATE Command and ordering of responses. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060102070603060301030603" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060102070603060301030603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > The above was done on separate DELETE commands. The ordering of querys > in the SAME command would probably have the same results. No matter which order they were sent, no matter of they were sent in one or two commands. You can NEVER delete the same UID twice. > However you did not address my cases where it can be shown that the > ordering of the querys in the SAME command WILL generate different and > conflicting results. You can NEVER delete the same UID twice. > Your cases are generic enough because they deal with pools of entries > rather than pools and specific entries. My example of "All events last > week" and "VEVENT with UID:12345@QWERTY" is 100% legal and it deals with > the case where the 2nd querys delete-vreply WOULD have a UID on it to > match it to my QUERYs SELECT information. > > For this kind of case we can potentially get mulitple delete-vreplys for > the same UID in the _SAME_ command with _different_ REQUEST-STATUSs. So > what is the CUA to make of that?? You can NEVER delete the same UID twice no matter how complex the query. It does not say find everything that matches. It says: "...There MUST BE one "VREPLY" component returned for each object that is deleted or marked for delete. ..." It does not say that if your query matches the same UID multiple times return the SAME UID multiple times. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060102070603060301030603 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjQxNzIyNTNaMCMGCSqGSIb3DQEJBDEWBBQL jsyET0rJELkppWBgO3LdQRLbyDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEANFs3TuPOwNB1 nH6kpI0yGDQ2v68n0Hpi6/bMYeP3JSJV+cj0tvidq1Qcl0yzNhiLo2RDZyVPSY46bwhrXRoH 9bHPp9QKi88KmT9wE2er8LNXNWfWoftR5w1x7BVUL5+TraYA95mbWGuNbImjpYY9+qfockWK oeL/X6JGh/jGUwmedBDqYRDS322L7K6NsgIwgyEkWAFVXzPcoC6oj3lgY/+3RxeascqEdz9H xeT7w+R4rrEgKT2c5kjjwupxdHg48VEE7AeW5/uFF+4fzVsx9LiQQW7VxXoOub0Rw0nAaJa0 xer5mPi+wJCVFH3qG/upNi31elFQhR0jeCp9Pw94lwAAAAAAAA== --------------ms060102070603060301030603-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 12:36:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19909 for ; Mon, 24 Feb 2003 12:36:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHTD415586 for ietf-calendar-bks; Mon, 24 Feb 2003 09:29:13 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHTBd15582 for ; Mon, 24 Feb 2003 09:29:12 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1OHT9b2019536 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Feb 2003 09:29:12 -0800 Message-ID: <3E5A5660.20008@Royer.com> Date: Mon, 24 Feb 2003 10:29:04 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Q: Outlook conformance (CLASS) References: <200302241154.17592.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070306000504020002040707" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070306000504020002040707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Yep - they are busted. In 2445: classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token / x-name ;Default is PUBLIC So I would mark it as PUBLIC. However my CS currently would reject it == fix it in the CUA prior to depositing it into the CS :-) Mark Swanson wrote: > Hello, > > Below is a snippet of iCalendar text that Outlook created. Outlook seems to > create this on every meeting request. This was sent to me and I do not know > what version of Outlook was used (though very likely a recent version). > > It seems to me that the CLASS property needs a value. > > Since we all want to be able to parse each others RFC 2445 messages I was > wondering how everyone else here was handling this error? > > Thanks. > > BEGIN:VEVENT > DTSTAMP:20030113T175450Z > DTSTART;TZID="Eastern Time (US & Canada)":20030114T100000 > > SEQUENCE:0 > PRIORITY:5 > CLASS: > CREATED:20030113T175450Z > LAST-MODIFIED:20030113T175501Z > STATUS:CONFIRMED > > END:VEVENT > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070306000504020002040707 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjQxNzI5MDRaMCMGCSqGSIb3DQEJBDEWBBSX pZmDznG1BIi0uk6TATSqCVypdjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYQdOqqJgYNiy jreaAMVZE8TcpfP0xjrGT3XSLL/LmqMKh0RdkI3HUG0Uqhlo/pu/b0uafkyErvOoozGkeXYj PMBbKF0X3o1Ou8/pWMLVvzPRVLMF8yPQhxm8hvWq5aDxZJyvfXMGTKnZuVBDANKie1D8+ZvC 3IGQCqC1zZM2Vl3rzoTr0VAhgNBl//IXWB++SB/BV/5uG7PMGyv55Hx8MQKOQopXt421GPKX V9SLyyLL3//FTg1FfqtVvElHI7r24KgG9ErxbKdlGMdDkX8ylNNFg3L9G6lqbAEMVPBePAxq iyJkB7WcYb5OmMAUlhHQnsRS7xIUjnZya7IPT+4CzQAAAAAAAA== --------------ms070306000504020002040707-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 12:48:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20453 for ; Mon, 24 Feb 2003 12:48:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHfxL16675 for ietf-calendar-bks; Mon, 24 Feb 2003 09:41:59 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHfwd16667 for ; Mon, 24 Feb 2003 09:41:58 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id A78BE4DA2; Mon, 24 Feb 2003 12:41:33 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: Doug Royer , "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 12:40:15 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <3E5A4CDD.8010801@Royer.com> In-Reply-To: <3E5A4CDD.8010801@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302241240.15310.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 24, 2003 11:48 am, Doug Royer wrote: > In all uses of the 'NON-US-ASCII' ABNF definition in 2445 it allows for > zero or MORE octets. It looks to me as if it does allow for 1 or more > octet (multibyte) characters. I've searched all occurences of octet in 2445 and haven't found any references to multibyte characters. Since NON-US-ASCII is defined as %x80-xF8 how is it possible to even implicitly understand this means multibyte - especially when I see some utf-8 chinese characters I'm parsing have 0x05 as one of their bytes? > Assuming you are correct and it should be %x80-FF, that looks to me > as if it would solve the problem by changing that alone. Have you verified > that all of the valid UTF-8 octet sequences that can include 0xF9-FF are > printable (not control) characters? If not we would have to also exclude > those characters sequences. There are no control characters in that range. UTF-8 is a 1:1 mapping of latin1 wrt 0x80-0xFF. You can verify this here: http://www.unicode.org/Public/MAPPINGS/ However, it appears that simply allowing 0x80-0xFF will not do because while UTF-8 is an 8-bit character set for all of ASCII and latin1, as soon as you use Chinese it switches to 2 or more bytes which may contain characters below 0x80. I realize that statement may set off warning bells. But I can safely say that it all works in theory and practice as at least 2 commercial iCalendar implementations are doing it this way and it works perfectly. The implementation details are roughly: 1. Assume the iCalendar text is in UTF-8. (1:1 mapping to ASCII and latin1) 2. Only pass UTF-8 strings to your parser. 3. Define NON-US-ASCII as \u0080 - \uffff I made these changes to the ScheduleWorld parser and it parses and displays any language defined in Unicode - nothing else in 2445 had to change. > Changing from UTF-8 to UTF-16 (which I think is your proposal) would > break existing iMIP implementations. No, I'm not changing from UTF-8 to UTF-16. It may have appeared that way because of the syntax: NON-US-ASCII = \u0080 - \uffff However, it is not what you think. I didn't mention it explicitly but I was refering to 2 separate things: 1. UTF-8 (we all know what that is) 2. the actual Unicode character ranges that UTF-8 maps to. F.E. it might take 3 bytes for UTF-8 to define unicode character \u5859 (I think this is one of the actual Chinese characters I was testing) > If you are talking about the standard multibyte to wide charset > translation functions you are talking about changing the charset > definition from ASCII valid to ASCII not valid. Although numerically > 'A' == 0x41 == 0x0041, in the UTF-8 charset the sequence 0x0041 != 'A'. > When using standard string functions existing implementations would break. > If an existing implementation internally already used standard multibyte to > wide character conversion functions, then when it converted to wide > characters (not knowing it already was as you propose) and it got a a > sequence of 0x0041, it would stop the conversion of UTF-8 at the 0x00 octet > and never see the 'A' character. And for implementations that use > multibyte (non-wide char) aware string functions, they would expect > UTF-8 and again would stop at the 0x00 octet never seeing the 'A'. Please understand that I am proposing to stick with UTF-8 where 0x41 == 0x41, completely 1:1 compatible with ASCII _and_ ISO-8859-1 (latin1). No string comparrisons will stop working with ASCII and latin1. String comparrisons will _start_ to work with characters above \u00ff. The key seems to be that UTF-8 can represent any character from 0x0000 - 0xffff and 2445 MUST take this into consideration. I have a feeling that I may not be clear. Though it all works for me I am not a Unicode expert (yet! :-) and I may be missing something too. > Mark Swanson wrote: > > #1 in more detail: > > > > (Quote from the spec as a reminder that UTF-8 is the default charset) > > > > 4.1.4 Character Set > > There is not a property parameter to declare the character set used > > in a property value. The default character set for an iCalendar > > object is UTF-8 as defined in [RFC 2279]. > > > > > > Note that the definition of NON-US-ASCII is %x80-F8. This excludes the > > following characters: > > > > ... > > > > A quick fix might be to change NON-US-ASCII to "%x80-FF" but since this > > only deals with a single character and does not handle every 2+ byte > > UTF-8 character this isn't good enough. A unified solution is presented > > at the bottom. > > All instances of the ABNF that use NON-US-ASCII ABNF definition > use * which allows for ZERO or more octets. > > > #2 in more detail > > > > Note the following definition (and comment): > > > > > > > > Change all 8-bit byte values to 16-bit byte values like this: > > > > NON-US-ASCII = \u0080 - \uffff > > Which is UTF-16 - correct? -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 13:05:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20935 for ; Mon, 24 Feb 2003 13:05:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHwkw17823 for ietf-calendar-bks; Mon, 24 Feb 2003 09:58:46 -0800 (PST) Received: from smtp7.andrew.cmu.edu (SMTP7.andrew.cmu.edu [128.2.10.87]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHwjd17817 for ; Mon, 24 Feb 2003 09:58:45 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp7.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1OHwf4V021734; Mon, 24 Feb 2003 12:58:41 -0500 Date: Mon, 24 Feb 2003 12:58:41 -0500 Message-Id: <200302241758.h1OHwf4V021734@smtp7.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: "ietf-calendar@imc.org" , Doug Royer , Mark Swanson In-reply-to: <200302241240.15310.mark@WebServiceSolutions.com> Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <3E5A4CDD.8010801@Royer.com> <200302241240.15310.mark@WebServiceSolutions.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Mark Swanson Date: Mon, 24 Feb 2003 12:40:15 -0500 [...] I've searched all occurences of octet in 2445 and haven't found any references to multibyte characters. Since NON-US-ASCII is defined as %x80-xF8 how is it possible to even implicitly understand this means multibyte - especially when I see some utf-8 chinese characters I'm parsing have 0x05 as one of their bytes? It is not possible for 0x05 to appear in UTF-8 text representing (part of) a Chinese character. 0x05 always represents the UCS-4 character \u0005. Please consult RFC 2279. > Assuming you are correct and it should be %x80-FF, that looks to > me as if it would solve the problem by changing that alone. Have > you verified that all of the valid UTF-8 octet sequences that can > include 0xF9-FF are printable (not control) characters? If not we > would have to also exclude those characters sequences. There are no control characters in that range. UTF-8 is a 1:1 mapping of latin1 wrt 0x80-0xFF. You can verify this here: http://www.unicode.org/Public/MAPPINGS/ This is incorrect. The first 255 characters of UCS-4 (Unicode) map 1:1 to ISO-8859-1. UTF-8 is an encoding of UCS-4 in which the ASCII subset of UCS-4 is mapped to a single byte sequence. However, it appears that simply allowing 0x80-0xFF will not do because while UTF-8 is an 8-bit character set for all of ASCII and latin1, as soon as you use Chinese it switches to 2 or more bytes which may contain characters below 0x80. This is incorrect. 1. Assume the iCalendar text is in UTF-8. (1:1 mapping to ASCII and latin1) 2. Only pass UTF-8 strings to your parser. 3. Define NON-US-ASCII as \u0080 - \uffff UTF-8 consists of variable length characters. You seem to be talking about UTF-32 or some multi-byte fixed length character encoding. Please consult RFC 2279. [...] Please understand that I am proposing to stick with UTF-8 where 0x41 == 0x41, completely 1:1 compatible with ASCII _and_ ISO-8859-1 (latin1). This is not UTF-8. No string comparrisons will stop working with ASCII and latin1. String comparrisons will _start_ to work with characters above \u00ff. The key seems to be that UTF-8 can represent any character from 0x0000 - 0xffff and 2445 MUST take this into consideration. This is correct; a UTF-8 octet sequence can represent any UCS-4 character. To me it is easiest to talk about iCalendar objects as sequences of UCS-4 characters, which must be encoded in UTF-8 octets, with the shortest legal sequence for any UCS-4 character. Trying to cram the UTF-8 rules into the iCalendar ABNF is just silly, but most other IETF protocols do it, so iCalendar might as well. Larry From owner-ietf-calendar@mail.imc.org Mon Feb 24 13:10:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21097 for ; Mon, 24 Feb 2003 13:10:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OI23618233 for ietf-calendar-bks; Mon, 24 Feb 2003 10:02:03 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OI21d18229 for ; Mon, 24 Feb 2003 10:02:01 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1OI1xb2019812 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Feb 2003 10:02:02 -0800 Message-ID: <3E5A5E11.6070609@Royer.com> Date: Mon, 24 Feb 2003 11:01:53 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <3E5A4CDD.8010801@Royer.com> <200302241240.15310.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070103050601080804070102" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070103050601080804070102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > On February 24, 2003 11:48 am, Doug Royer wrote: > >>In all uses of the 'NON-US-ASCII' ABNF definition in 2445 it allows for >>zero or MORE octets. It looks to me as if it does allow for 1 or more >>octet (multibyte) characters. > > > I've searched all occurences of octet in 2445 and haven't found any references > to multibyte characters. Since NON-US-ASCII is defined as %x80-xF8 how is it > possible to even implicitly understand this means multibyte - especially when > I see some utf-8 chinese characters I'm parsing have 0x05 as one of their > bytes? It does not use the word multibyte - however it allows for zero or more sequences of characters. The only 4 uses of 'NON-US-ASCII' in 2445 are: 'SAFE-CHAR', 'QSAFE-CHAR', 'TSAFE-CHAR', and 'VALUE-CHAR' All of them define they they allow exactly 1 octet. And each of those when are used with '*' (zero or more): paramtext = *SAFE-CHAR quoted-string = DQUOTE *QSAFE-CHAR DQUOTE value = *VALUE-CHAR text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) So in all cases it allows for zero or more octets which would cover multibyte. And yes the 2445 ABNF is busted in that it assumes that all octets fall in that range (0x...)! >>Assuming you are correct and it should be %x80-FF, that looks to me >>as if it would solve the problem by changing that alone. Have you verified >>that all of the valid UTF-8 octet sequences that can include 0xF9-FF are >>printable (not control) characters? If not we would have to also exclude >>those characters sequences. > > > There are no control characters in that range. Great! > However, it appears that simply allowing 0x80-0xFF will not do because while > UTF-8 is an 8-bit character set for all of ASCII and latin1, as soon as you > use Chinese it switches to 2 or more bytes which may contain characters below > 0x80. I see your point. Would you like to propose the correct ABNF to make UTF-8 work in 2445? :-) I have been reading other WG lists where they are running into the same or similar UTF-8 issues with respect to the ABNF. I think the real problem is that the authors did not really understand charsets (Sorry Frank and all) and just did their best. I agree that the charset part of the 2445 ABNF is busted. I think we rely on the ABNF too much and should just default to text that says: Its UTF-8 - except you can not use control characters XXX,... and that YYY needs to be quoted... > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070103050601080804070102 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjQxODAxNTNaMCMGCSqGSIb3DQEJBDEWBBQO YLKXY9a/EWQpb8wZ3/6WYxSXxDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEApMw88ouoFpSB p/nKFRI3yJkYE/4w7J5898vZadAS+wU7cbmhB0+gOzNM/rvn1iBo+TIKvnZCfXrxyXe/abqr zPF+Kv+zFxS9u0J/JvFKU+OuBN5z8iVFuVJ1NmYZ4xCbnOv3PLabjwzxD+kfxDzyqOVtgC6a g3Sg9dHTCnVYmDsYvy1f9osgQEj3cq/HSDY6iAdiJObDWuKJJu8L/vp3G07AKqlQKkDoY84W I45uqTFR4odODQL0K//WRJZqyHHuHPR2dBKLSLwmSS4mQ3zfNmKWpctF4IZdy5K/zXVx4Rcu pWoDAijPc8KjIyeUyB/LMQE2NWOKNKxfCcSWQKSR1AAAAAAAAA== --------------ms070103050601080804070102-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 13:17:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21400 for ; Mon, 24 Feb 2003 13:17:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OI6BQ18347 for ietf-calendar-bks; Mon, 24 Feb 2003 10:06:11 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OI69d18341 for ; Mon, 24 Feb 2003 10:06:10 -0800 (PST) To: ietf-calendar@imc.org Subject: Proposed changed GET-CAPABILITY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 24 Feb 2003 13:06:04 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/24/2003 01:05:56 PM, Serialize complete at 02/24/2003 01:05:56 PM Content-Type: multipart/alternative; boundary="=_alternative 006357B285256CD7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006357B285256CD7_= Content-Type: text/plain; charset="US-ASCII" A while back there was some WG discussion about the GET-CAPABILITY command and whether or not there should be defaulting or not and if the command should be required of all sides of the CAP protocol. There seemed to be general agreement about some changes but no proposed change text. I have taken the task of making the change text as I was the one who proposed much of the changes. Currently the GET-CAPABILITY command is proposed to be required of all CSs and optional of all CUAs. However this is not a good design as a basis for CAP 1.0 and it does not factor in that we may eventually have CS <-> CS CAP where there is no CUA involved in the work (although one side may view the other as a CUA but thats not equivalent). In addition, if some component values are not in the response for the command they are assumed defaulted. This too is not a good design as defaults may change from CAP version to CAP version and thus incorrect assumptions could be made. To avoid confusion and future interoperability problems I am proposing we change GET-CAPAIBLITY to the the text below. I changed mainly the lead in text but I also made changes to the ABNF (to be consistant w/the rest of CAP and to the descriptions of the returned properties). I did rework the ABNF to be more consistant and to have some more accurate comments. I also removed PRODID and VERSION from the list of properties in the cap-vreply since its already specified in the cap-reply container and are therefore superfluous. I changed the reference from "SQL support" to "CAP-QL support" since Im sure it was just a Freudian slip on someones part. It was not dissucssed in the WG if we truely need to have bounded latency on GET-CAPABILITY or not. Nor did we discuss the need to name the GET-CAPABILITY command. If we remove bounded latency from GET-CAPAIBLITY then we can remove the id-param too from the capablitiyparam ABNF. I did add IANA-PROP and X-PROP to the table since they actually make up the other-prop in the ABNF but have separate meanings. Here is my proposed revised version of the the GET-CAPAIBLITY command: [I see that Doug put out a new draft but this is based on the 10Jan2003 draft since that was what I started with (and this got filed in my Drafts folder instead of being sent over a week ago). The vast majority should map just fine if you change the section number accordingly.] ====================================== 10.3. GET-CAPABILITY Command CMD: GET-CAPABILITY Purpose: The "GET-CAPABILITY" command returns the capabilities of the other end point of the session. All CAP implemenations MUST support the "GET-CAPABLITY" command. Furthermore, the "GET-CAPABLITY" command SHOULD be issued early in the CAP session to properly detect restrictions or abilities of the other end point. A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. Another "GET-CAPABILITY" command subsequent to successful authentiation MAY be useful in case the CS alters the options allowed based on the authentication credentials provided. The CS MUST send a "GET-CAPABILITY" command to a CUA after the initial connection. Multiple "GET-CAPABILITY" commands to the CUA SHOULD NOT be necessary. Formal Definition: A "GET-CAPABILITY" command is defined by the following notation: get-capability-cmd = capibiltyparam ":" "GET-CAPABILITY" capibiltyparam = *( ; The following are optional, ; but MUST NOT occur more than once ; id-param / localize-param / latency-param / ; The following MUST occur exactly once and only ; when the latency-param has been supplied and ; MUST NOT be supplied if the latency-param is ; not supplied. ; action-param / ; the following is optional, ; and MAY occur more than once ; other-params ) Response: The "GET-CAPABILITY" command returns information about the other end of the session given the current state of the connection. The "GET-CAPABILITY" reply may return different results depending on the UPN and if the UPN is authenticated. Client implementations SHOULD NOT require any capability element beyond those defined in this specification, and MAY ignore any nonstandard, experimental capability elements. When sending a reply to a "GET-CAPABILITY" command, all of the properties below MUST BE supplied. All implementations MUST always send the full reply when queried. Properties or property values MUST NOT be defaulted or assumed by either end point. If the queried sided does not indicate a value or setting then it MAY NOT be defaulted; it is simply unavailable. The following properties are returned in response to a "GET-CAPABILITY" command: cap-reply = "BEGIN" ":" "VCALENDAR" CRLF ; All properties may be in any order. ; ; The following are optional, ; but MUST NOT occur more than once ; prodid / version / ; The following are optional, ; but MAY occur more than once ; other-props / ; The following are required and ; MUST occur only once ; cap-vreply "END" ":" "VCALENDAR" CRLF cap-vreply = "BEGIN" ":" "VREPLY" CRLF ; All properties may be in any order. ; ; The following MUST occur only once ; cap-version / car-level / components / stores-expanded / maxdate / mindate / itip-version / max-comp-size / multipart / query-level / recur-accepted / recur-expand / recur-limit / ; The following MAY occur more than once ; other-props "END" ":" "VREPLY" CRLF Name Occurs Description ------------------------------------------------------------------ CAP-VERSION 1 Version of CAP. It MUST include at least "XX" (NOTE 'XX' WILL BE REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT) for this version of CAP. This is a multiple value property with values separated with commas (,). All values MUST be positive integer values. CAR-LEVEL 1 Indicates level of CAR support. This version of CAP defines the following possible values: "CAR-NONE", "CAR-MIN" and "CAR-FULL-1". If "CAR-FULL-1" is supplied then "CAR-MIN" MUST BE assumed. A "CAR-MIN" implementation only supports the DEFAULT-VCARS listed in the VCALSTORE and does not support the creation or modification of VCARS. COMPONENTS 1 A comma separated list of the names of components that are supported. This includes any components inside of other components (ie: VALARMs). For this version of CAP the list MUST include at least "VCALSTORE", "VCALENDAR", "VREPLY", "VAGENDA" and at least one of "VEVENT", "VTODO", "VJOURNAL" or "VTIMEZONE". This version of CAP defines the following possible values: "VCALSTORE", "VCALENDAR", "VREPLY", "VAGENDA", "VEVENT", "VJOURNAL", "VTODO", "VALARM", "VTIMEZONE", "DAYLIGHT" and "STANDARD" STORES-EXPANDED 1 A boolean value of either "TRUE" or "FALSE". If TRUE then it expands multiple instances separately when they are stored (RRULEs converted to RDATEs) and when sent. If FALSE then it expands instances dynamically during sending. MAXDATE 1 The datetime value in UTC beyond which the end point cannot accept. The maximum value allowed is 99991231T235959Z. MINDATE 1 The datetime value in UTC prior to which the end point cannot accept. The minimum value allowed is 00000101T000000Z. ITIP-VERSION 1 A comma separated list of the version(s) of ITIP supported. The list MUST include at least the value of "2446" to specify RFC-2446 support. MAX-COMPONENT-SIZE 1 A non-negative integer value that specifies the size of the largest iCalendar object that can be accepted in octets. Objects larger than this will be rejected. A value of zero (0) means no limit. This is also the maximum value of any [BEEP] payload that will be accepted or sent. MULTIPART 1 A comma separated list of lower cased MIME multipart subtypes that the sender supports. If multipart is not supported then the property has no value (ie: an empty list). Example: MULTIPART:related,alternate QUERY-LEVEL 1 Indicates level of CAP-QL support. This version of CAP defines the following possible values: "CAL-QL-1" and "CAL-QL-NONE". "CAL-QL-NONE" is for end points that allow ITIP methods only to be deposited and nothing else. RECUR-ACCEPTED 1 A boolean value to indicate whether recurrence rules are acceptable. RECUR-EXPAND 1 A boolean value to indicate whether or not the end point supports the expansion of recurrence rules. RECUR-LIMIT 1 A non-negative integer value that indicates the maximum number of occurrences of a recurrence rule that are expanded. A value of zero (0) means unlimited. RECUR-ACCEPTED 1 A boolean value to indicate whether recurrence rules are acceptable. IANA-PROPS 0+ Zero or more IANA defined properties. X-PROPS 0+ Zero or more experimental properties supported by a particular implementation. ------------------------------------------------------- Example: I: Content-Type: text/calendar I: I: BEGIN:VCALENDAR I: VERSION:2.0 I: PRODID:-//someone's prodid I: CMD;ID=unique-per-cua-125:GET-CAPABILITY I: END:VCALENDAR L: Content-Type: text/calendar L: L: BEGIN:VCALENDAR L: VERSION:2.0 L: PRODID:-//someone's prodid L: CMD;ID=unique-per-cua-125:REPLY L: BEGIN:VREPLY L: CAP-VERSION:1.0 L: PRODID:The CS prodid L: QUERY-LEVEL:CAL-QL-1 L: CAR-LEVEL:CAR-FULL-1 L: MAXDATE:99991231T235959Z L: MINDATE:00000101T000000Z L: MAX-COMPONENT-SIZE:0 L: COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR, L: VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT,VREPLY L: ITIP-VERSION:2447 L: RECUR-ACCEPTED:TRUE L: RECUR-EXPAND:TRUE L: RECUR-LIMIT:0 L: STORES-EXPANDED:FALSE L: X-INET-PRIVATE-COMMANDS:1.0 L: END:VREPLY L: END:VCALENDAR =========================================== The big changes in my proposal were already covered in the WG, I just put some prose to the changes (mainly the text under "Purpose") but I did make some minor changes to the rest as I already noted in the text above. I would like to propose that we remove bounded latency from GET-CAPAIBLITY for 2 reasons: 1: It should not require any great number of cycles for any implementation to actually implement and perform compared to most other commands. 2: It needs to be done before any other commands are done and once done does not need to be performed again (after authentication that is). As such we can simplify the command a bit by removing the latency related properties and trimming down the example above. After all, its somewhat foolhearty to NOT wait for this relatively quick command to complete before doing other commands like C&S workflow... Comments? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006357B285256CD7_= Content-Type: text/html; charset="US-ASCII"
A while back there was some WG discussion about the GET-CAPABILITY command and whether or not there should be defaulting or not and if the command should be required of all sides of the CAP protocol.  There seemed to be general agreement about some changes but no proposed change text.  I have taken the task of making the change text as I was the one who proposed much of the changes.  

Currently the GET-CAPABILITY command is proposed to be required of all CSs and optional of all CUAs.  However this is not a good design as a basis for CAP 1.0 and it does not factor in that we may eventually have CS <-> CS CAP where there is no CUA involved in the work (although one side may view the other as a CUA but thats not equivalent).  In addition, if some component values are not in the response for the command they are assumed defaulted.  This too is not a good design as defaults may change from CAP version to CAP version and thus incorrect assumptions could be made.

To avoid confusion and future interoperability problems I am proposing we change GET-CAPAIBLITY to the the text below.  I changed mainly the lead in text but I also made changes to the ABNF (to be consistant w/the rest of CAP and to the descriptions of the returned properties).

I did rework the ABNF to be more consistant and to have some more accurate comments.  I also removed PRODID and VERSION from the list of properties in the cap-vreply since its already specified in the cap-reply container and are therefore superfluous.

I changed the reference from "SQL support" to "CAP-QL support" since Im sure it was just a Freudian slip on someones part.

It was not dissucssed in the WG if we truely need to have bounded latency on GET-CAPABILITY or not.  Nor did we discuss the need to name the GET-CAPABILITY command.  If we remove bounded latency from GET-CAPAIBLITY then we can remove the id-param too from the capablitiyparam ABNF.

I did add IANA-PROP and X-PROP to the table since they actually make up the other-prop in the ABNF but have separate meanings.

Here is  my proposed revised version of the the GET-CAPAIBLITY command:

[I see that Doug put out a new draft but this is based on the 10Jan2003 draft since that was what I started with (and this got filed in my Drafts folder instead of being sent over a week ago).  The vast majority should map just fine if you change the section number accordingly.]

======================================
10.3. GET-CAPABILITY Command
CMD: GET-CAPABILITY

Purpose: The "GET-CAPABILITY" command returns the capabilities of the other end point of the session.

All CAP implemenations MUST support the "GET-CAPABLITY" command.  Furthermore, the "GET-CAPABLITY" command SHOULD be issued early in the CAP session to properly detect restrictions or abilities of the other end point.

A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection.  Another "GET-CAPABILITY" command subsequent to successful authentiation MAY be useful in case the CS alters the options allowed based on the authentication credentials provided.

The CS MUST send a "GET-CAPABILITY" command to a CUA after the initial connection.  Multiple "GET-CAPABILITY" commands to the CUA SHOULD NOT be necessary.

Formal Definition: A "GET-CAPABILITY" command is defined by the following notation:

get-capability-cmd   = capibiltyparam ":" "GET-CAPABILITY"

capibiltyparam     = *(
                  ; The following are optional,
                  ; but MUST NOT occur more than once
                  ;
                  id-param /
                   localize-param /
                   latency-param /

                  ; The following MUST occur exactly once and only
                  ; when the latency-param has been supplied and
                  ; MUST NOT be supplied if the latency-param is
                  ; not supplied.
                  ;
                  action-param /

                  ; the following is optional,
                  ; and MAY occur more than once
                  ;
                  other-params
                  )
Response:

The "GET-CAPABILITY" command returns information about the other end of the session given the current state of the connection. The "GET-CAPABILITY" reply may return different results depending on the UPN and if the UPN is authenticated.

Client implementations SHOULD NOT require any capability element beyond those defined in this specification, and MAY ignore any nonstandard, experimental capability elements.

When sending a reply to a "GET-CAPABILITY" command, all of the properties below MUST BE supplied. All implementations MUST always send the full reply when queried.  Properties or property values MUST NOT be defaulted or assumed by either end point.  If the queried sided does not indicate a value or setting then it MAY NOT be defaulted; it is simply unavailable.

The following properties are returned in response to a "GET-CAPABILITY" command:

cap-reply   = "BEGIN" ":" "VCALENDAR" CRLF
                 ; All properties may be in any order.
                  ;
                 ; The following are optional,
                 ; but MUST NOT occur more than once
                 ;
                 prodid /
                 version /
                  ; The following are optional,
                 ; but MAY occur more than once
                 ;
                  other-props /

                  ; The following are required and
                 ; MUST occur only once
                 ;
                  cap-vreply
                "END" ":" "VCALENDAR" CRLF
cap-vreply     = "BEGIN" ":" "VREPLY" CRLF
                 ; All properties may be in any order.
                  ;
                 ; The following MUST occur only once
                 ;
                 cap-version /
                 car-level /
                 components /
                 stores-expanded /
                 maxdate /
                 mindate /
                 itip-version /
                 max-comp-size /
                 multipart /
                 query-level /
                 recur-accepted /
                 recur-expand /
                 recur-limit /
                  ; The following MAY occur more than once
                 ;
                 other-props
                 "END" ":" "VREPLY" CRLF

Name            Occurs  Description
                                   
------------------------------------------------------------------
 CAP-VERSION        1     Version of CAP. It MUST include at least "XX"
                          (NOTE 'XX' WILL BE REPLACED WITH THE RFC NUMBER
                          OF THIS DOCUMENT) for this version of CAP. This
                          is a multiple value property with values
                          separated with commas (,).  All values MUST be
                           positive integer values.

 CAR-LEVEL          1     Indicates level of CAR support. This version
                           of CAP defines the following possible values:
                           "CAR-NONE", "CAR-MIN" and "CAR-FULL-1". If
                           "CAR-FULL-1" is supplied then "CAR-MIN" MUST BE
                           assumed.  A "CAR-MIN" implementation only supports
                          the DEFAULT-VCARS listed in the VCALSTORE
                          and does not support the creation or
                          modification of VCARS.

  COMPONENTS        1     A comma separated list of the names of
                          components that are supported. This
                          includes any components inside of other components
                           (ie: VALARMs).  For this version of CAP the list
                           MUST include at least "VCALSTORE", "VCALENDAR",
                           "VREPLY", "VAGENDA" and at least one of "VEVENT",
                          "VTODO", "VJOURNAL" or "VTIMEZONE".  This version of
                           CAP defines the following possible values:
                          "VCALSTORE", "VCALENDAR", "VREPLY", "VAGENDA",
                          "VEVENT", "VJOURNAL", "VTODO", "VALARM",
                           "VTIMEZONE", "DAYLIGHT" and "STANDARD"

  STORES-EXPANDED    1    A boolean value of either "TRUE" or "FALSE".
                           If TRUE then it expands multiple instances
                          separately when they are stored (RRULEs
                          converted to RDATEs) and when sent. If
                          FALSE then it expands instances dynamically
                          during sending.

  MAXDATE            1    The datetime value in UTC beyond which the
                          end point cannot accept. The maximum value
                           allowed is 99991231T235959Z.


  MINDATE          1      The datetime value in UTC prior to which
                          the end point cannot accept. The minimum value
                           allowed is 00000101T000000Z.

  ITIP-VERSION      1     A comma separated list of the version(s) of
                           ITIP supported.  The list MUST include at least
                           the value of "2446"  to specify RFC-2446 support.

  MAX-COMPONENT-SIZE
                    1     A non-negative integer value that specifies
                          the size of the largest iCalendar object
                          that can be accepted in octets.  Objects
                          larger than this will be rejected. A
                          value of zero (0) means no limit.
                          This is also the maximum value of any [BEEP]
                          payload that will be accepted or sent.

  MULTIPART         1     A comma separated list of lower cased MIME
                           multipart subtypes that the sender supports.
                           If multipart is not supported then the property
                           has no value (ie: an empty list). Example:
                           MULTIPART:related,alternate

  QUERY-LEVEL       1     Indicates level of CAP-QL support. This version of
                           CAP defines the following possible values:
                           "CAL-QL-1" and "CAL-QL-NONE".  "CAL-QL-NONE" is
                           for end points that allow ITIP methods only to
                           be deposited and nothing else.
                       
  RECUR-ACCEPTED    1     A boolean value to indicate whether recurrence
                           rules are acceptable.


  RECUR-EXPAND      1     A boolean value to indicate whether or not the
                           end point supports the expansion of recurrence rules.

  RECUR-LIMIT       1     A non-negative integer value that indicates the maximum
                          number of occurrences of a recurrence rule that are expanded.
                          A value of zero (0) means unlimited.

  RECUR-ACCEPTED    1     A boolean value to indicate whether recurrence
                          rules are acceptable.

  IANA-PROPS        0+    Zero or more IANA defined properties.

   X-PROPS           0+    Zero or more experimental properties supported by
                           a particular implementation.

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

  Example:

  I: Content-Type: text/calendar
  I:
  I: BEGIN:VCALENDAR
  I: VERSION:2.0
  I: PRODID:-//someone's prodid
  I: CMD;ID=unique-per-cua-125:GET-CAPABILITY
  I: END:VCALENDAR

  L: Content-Type: text/calendar
  L:
  L: BEGIN:VCALENDAR
  L: VERSION:2.0
  L: PRODID:-//someone's prodid
  L: CMD;ID=unique-per-cua-125:REPLY
  L: BEGIN:VREPLY
  L: CAP-VERSION:1.0
  L: PRODID:The CS prodid
  L: QUERY-LEVEL:CAL-QL-1
  L: CAR-LEVEL:CAR-FULL-1
  L: MAXDATE:99991231T235959Z
  L: MINDATE:00000101T000000Z
  L: MAX-COMPONENT-SIZE:0
  L: COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR,
  L:  VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT,VREPLY
  L: ITIP-VERSION:2447
  L: RECUR-ACCEPTED:TRUE
  L: RECUR-EXPAND:TRUE
  L: RECUR-LIMIT:0
  L: STORES-EXPANDED:FALSE
  L: X-INET-PRIVATE-COMMANDS:1.0
  L: END:VREPLY
  L: END:VCALENDAR

===========================================

The big changes in my proposal were already covered in the WG, I just put some prose to the changes (mainly the text under "Purpose") but I did make some minor changes to the rest as I already noted in the text above.

I would like to propose that we remove bounded latency from GET-CAPAIBLITY for 2 reasons:

1: It should not require any great number of cycles for any implementation to actually implement and perform compared to most other commands.
2: It needs to be done before any other commands are done and once done does not need to be performed again (after authentication that is).

As such we can simplify the command a bit by removing the latency related properties and trimming down the example above.  After all, its somewhat foolhearty to NOT wait for this relatively quick command to complete before doing other commands like C&S workflow...

Comments?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006357B285256CD7_=-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 14:00:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22693 for ; Mon, 24 Feb 2003 14:00:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OIomn21746 for ietf-calendar-bks; Mon, 24 Feb 2003 10:50:48 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OIold21740 for ; Mon, 24 Feb 2003 10:50:47 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id B14BC4DA2; Mon, 24 Feb 2003 13:50:21 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: Lawrence Greenfield , "ietf-calendar@imc.org" , Doug Royer Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 13:48:56 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241240.15310.mark@WebServiceSolutions.com> <200302241758.h1OHwf4V021734@smtp7.andrew.cmu.edu> In-Reply-To: <200302241758.h1OHwf4V021734@smtp7.andrew.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302241348.56681.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 24, 2003 12:58 pm, Lawrence Greenfield wrote: > From: Mark Swanson > Date: Mon, 24 Feb 2003 12:40:15 -0500 > [...] > I've searched all occurences of octet in 2445 and haven't found any > references to multibyte characters. Since NON-US-ASCII is defined > as %x80-xF8 how is it possible to even implicitly understand this > means multibyte - especially when I see some utf-8 chinese > characters I'm parsing have 0x05 as one of their bytes? > > It is not possible for 0x05 to appear in UTF-8 text representing (part > of) a Chinese character. > > 0x05 always represents the UCS-4 character \u0005. > > Please consult RFC 2279. OK - the \u0005 was my mistake. > > Assuming you are correct and it should be %x80-FF, that looks to > > me as if it would solve the problem by changing that alone. Have > > you verified that all of the valid UTF-8 octet sequences that can > > include 0xF9-FF are printable (not control) characters? If not we > > would have to also exclude those characters sequences. > > There are no control characters in that range. UTF-8 is a 1:1 > mapping of latin1 wrt 0x80-0xFF. You can verify this here: > http://www.unicode.org/Public/MAPPINGS/ > > This is incorrect. > > The first 255 characters of UCS-4 (Unicode) map 1:1 to ISO-8859-1. > > UTF-8 is an encoding of UCS-4 in which the ASCII subset of UCS-4 is > mapped to a single byte sequence. Got it. > However, it appears that simply allowing 0x80-0xFF will not do > because while UTF-8 is an 8-bit character set for all of ASCII and > latin1, as soon as you use Chinese it switches to 2 or more bytes > which may contain characters below 0x80. > > This is incorrect. That's interesting. If true I need to start verifying the output of my third party parser... > 1. Assume the iCalendar text is in UTF-8. (1:1 mapping to ASCII and > latin1) > 2. Only pass UTF-8 strings to your parser. > 3. Define NON-US-ASCII as \u0080 - \uffff > > UTF-8 consists of variable length characters. You seem to be talking > about UTF-32 or some multi-byte fixed length character encoding. > > Please consult RFC 2279. The above works. I'm talking about the Unicode character. It would not make sense to deal directly with UTF-8 octets. > [...] > Please understand that I am proposing to stick with UTF-8 where > 0x41 == 0x41, completely 1:1 compatible with ASCII _and_ ISO-8859-1 > (latin1). > > This is not UTF-8. Got it. > No string comparrisons will stop working with ASCII and > latin1. String comparrisons will _start_ to work with characters > above \u00ff. > > The key seems to be that UTF-8 can represent any character from > 0x0000 - 0xffff and 2445 MUST take this into consideration. > > This is correct; a UTF-8 octet sequence can represent any UCS-4 > character. > > To me it is easiest to talk about iCalendar objects as sequences of > UCS-4 characters, which must be encoded in UTF-8 octets, with the > shortest legal sequence for any UCS-4 character. Trying to cram the > UTF-8 rules into the iCalendar ABNF is just silly, but most other IETF > protocols do it, so iCalendar might as well. > > Larry I understand and agree with your first sentence. I have no idea what you are refering to in your second sentence :-) To try and summarize: 1. We need to ensure 0xf9-0xff does not contain any non-printable characters with the UTF-8 encoding. 2. UTF-8 capable parsers should parse after decoding UTF-8 characters into UCS-4. 3. When dealing with UCS-4 characters we should use: NON-US-ASCII = \u0080 - \uffff Correct? -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 14:04:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22810 for ; Mon, 24 Feb 2003 14:04:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OIwSK22796 for ietf-calendar-bks; Mon, 24 Feb 2003 10:58:28 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OIwRd22788 for ; Mon, 24 Feb 2003 10:58:27 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1OIwOb2020237 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Feb 2003 10:58:27 -0800 Message-ID: <3E5A6B4B.9080901@Royer.com> Date: Mon, 24 Feb 2003 11:58:19 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Proposed changed GET-CAPABILITY Command References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010505070309030800020509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010505070309030800020509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > A while back there was some WG discussion about the GET-CAPABILITY > command and whether or not there should be defaulting or not and if the > command should be required of all sides of the CAP protocol. yes - I think we did agree - I simply forgot it. > The big changes in my proposal were already covered in the WG, I just > put some prose to the changes (mainly the text under "Purpose") but I > did make some minor changes to the rest as I already noted in the text > above. > > I would like to propose that we remove bounded latency from > GET-CAPAIBLITY for 2 reasons: > > 1: It should not require any great number of cycles for any > implementation to actually implement and perform compared to most other > commands. I don't follow (not that I agree or disagree). > 2: It needs to be done before any other commands are done and once done > does not need to be performed again (after authentication that is). Not true it says (And has said for a while): 10.3 ... The "GET-CAPABILITY" command returns information about the Calendar other end of the session given the current state of the connection. The values returned may differ depending on current user identify and the security level of the connection. So the values reutured AFTER authentication and INDENTIFY might be more or less restrictive than before authentication and change of identity. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010505070309030800020509 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjQxODU4MTlaMCMGCSqGSIb3DQEJBDEWBBQD S820xbJTlpxrd1JdyASiYGF0jjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAk1t4ELcHlF/k 2bri10mgAsjw5mbF2CG6Vk54EvXHVIDau+j1RBMN7iRLPnOUJLljSO2w0wB9F0YvVbAZv/a5 z45ynOxkZT3UY9QbdqHVYTKSnaJcqmq9uycrO2qjMycx4/NxXGynIEWo/dY4dWI+3qSs79XN v9v4Q7b0ueMzD5ri9GOm0JwOW49lHU4LrHiPsmEpjEqqotkmKJYiU9X/XvadtF4f89O4XuIq /YqGF3JCVBSZCBtyYtSu+4zganwVd+tyPJExoLlziME9/L+sRIAU4OYH2Eh7lv21JOmP9D2l ZnnTvC5b+GP45a4t0HjgqOQobDx397bxA6+ktJU9SgAAAAAAAA== --------------ms010505070309030800020509-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 14:10:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23008 for ; Mon, 24 Feb 2003 14:10:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OJ3Rd23300 for ietf-calendar-bks; Mon, 24 Feb 2003 11:03:27 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OJ3Qd23292 for ; Mon, 24 Feb 2003 11:03:26 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1OJ3Ob2020291 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Feb 2003 11:03:27 -0800 Message-ID: <3E5A6C76.9070607@Royer.com> Date: Mon, 24 Feb 2003 12:03:18 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241240.15310.mark@WebServiceSolutions.com> <200302241758.h1OHwf4V021734@smtp7.andrew.cmu.edu> <200302241348.56681.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000306070109000703040406" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000306070109000703040406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > ... > ... > >>To me it is easiest to talk about iCalendar objects as sequences of >>UCS-4 characters, which must be encoded in UTF-8 octets, with the >>shortest legal sequence for any UCS-4 character. Trying to cram the >>UTF-8 rules into the iCalendar ABNF is just silly, but most other IETF >>protocols do it, so iCalendar might as well. >> >>Larry > > > I understand and agree with your first sentence. > > I have no idea what you are refering to in your second sentence :-) I think he is referring to the fact that many RFCs try to define the ABNF for UTF-8 and fail - like 2445 fails. > To try and summarize: > > 1. We need to ensure 0xf9-0xff does not contain any non-printable characters > with the UTF-8 encoding. > > 2. UTF-8 capable parsers should parse after decoding UTF-8 characters into > UCS-4. You can if you want to, however my implementation runs just fine in the UTF-8 charset. It would be up to implementations. > 3. When dealing with UCS-4 characters we should use: > NON-US-ASCII = \u0080 - \uffff I think we need to not use 'UCS-4' in 2445 corrections and just state that it is UTF-8, don't use control characters and list the ones that force the data to be quoted. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000306070109000703040406 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjQxOTAzMThaMCMGCSqGSIb3DQEJBDEWBBRm wdR3tTkzhd4ozLk1dIrJ1DfQ7jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAIjCkXBcGFZJN hnEZ6j2TY/CbaXnv3A5nqpVDd7EvbNjQ4OpLfxbxS3Bs8Sx7uxBCsEWlSbpMpjS+KWcXS1iV cJRHWPp1oElRzlc1JKHhpSpIE0A1jUW3V9IXfBHNk1EQUpsBCMBlPdBdUumnfSLL9VSQd291 tuZuotUHLezGFtNH0PGsbg2DMPuwcmIr6RFInPlNwtxTXlkw7CV4Yg3NBq2NggoAiVR/k9bV V+opEhynDGxO+V8ee1MgenSaWSzhDx6myU5fuOB6QhEOKOXobYsBJM0HDyoC/EQ/arxi0/r3 1bOX6MSVmW3p6cZ5aEsfCurZPKwlX+Akr9QeIm7s0QAAAAAAAA== --------------ms000306070109000703040406-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 14:17:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23213 for ; Mon, 24 Feb 2003 14:17:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OJAba23849 for ietf-calendar-bks; Mon, 24 Feb 2003 11:10:37 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OJAad23845 for ; Mon, 24 Feb 2003 11:10:36 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 5986B4DA2 for ; Mon, 24 Feb 2003 14:10:12 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 14:08:45 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241240.15310.mark@WebServiceSolutions.com> <3E5A5E11.6070609@Royer.com> In-Reply-To: <3E5A5E11.6070609@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302241408.45990.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 24, 2003 01:01 pm, Doug Royer wrote: > Mark Swanson wrote: > > On February 24, 2003 11:48 am, Doug Royer wrote: > >>In all uses of the 'NON-US-ASCII' ABNF definition in 2445 it allows for > >>zero or MORE octets. It looks to me as if it does allow for 1 or more > >>octet (multibyte) characters. > > > > I've searched all occurences of octet in 2445 and haven't found any > > references to multibyte characters. Since NON-US-ASCII is defined as > > %x80-xF8 how is it possible to even implicitly understand this means > > multibyte - especially when I see some utf-8 chinese characters I'm > > parsing have 0x05 as one of their bytes? > > It does not use the word multibyte - however it allows for zero > or more sequences of characters. > > The only 4 uses of 'NON-US-ASCII' in 2445 are: > > 'SAFE-CHAR', 'QSAFE-CHAR', 'TSAFE-CHAR', and 'VALUE-CHAR' > > All of them define they they allow exactly 1 octet. > And each of those when are used with '*' (zero or more): > > paramtext = *SAFE-CHAR > > quoted-string = DQUOTE *QSAFE-CHAR DQUOTE > > value = *VALUE-CHAR > > text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) > > > So in all cases it allows for zero or more octets which > would cover multibyte. Ah, I see. Thank you. > And yes the 2445 ABNF is busted in that it assumes that all octets > fall in that range (0x...)! > > >>Assuming you are correct and it should be %x80-FF, that looks to me > >>as if it would solve the problem by changing that alone. Have you > >> verified that all of the valid UTF-8 octet sequences that can include > >> 0xF9-FF are printable (not control) characters? If not we would have to > >> also exclude those characters sequences. > > > > There are no control characters in that range. > > Great! > > > However, it appears that simply allowing 0x80-0xFF will not do because > > while UTF-8 is an 8-bit character set for all of ASCII and latin1, as > > soon as you use Chinese it switches to 2 or more bytes which may contain > > characters below 0x80. > > I see your point. > > Would you like to propose the correct ABNF to make UTF-8 work in 2445? :-) > I have been reading other WG lists where they are running into the > same or similar UTF-8 issues with respect to the ABNF. I think the real > problem is that the authors did not really understand charsets (Sorry Frank > and all) and just did their best. > > I agree that the charset part of the 2445 ABNF is busted. I think we rely > on the ABNF too much and should just default to text that says: > > > Its UTF-8 - except you can not use control characters XXX,... > and that YYY needs to be quoted... Lawrence has schooled me on a few points I made. Apparently UTF-8 is only a mapping to ASCII and not latin1 and UTF-8 characters do not use values below 0x80. I have verified this with rfc 2279. Based on your above analysis that states all instances of multibyte characters are provided for two questions come to mind: 1. Is it clear enough that multibyte octets are supported in 2445? Perhaps I should have caught that, but perhaps we could add something. The answer to #2 would give us all we need to suggest something. 2. I still haven't found what UTF-8 encodings of 0xf9 - 0xff decode to in UCS-4. It would be great if they were not control characters. Cheers. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 14:17:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23228 for ; Mon, 24 Feb 2003 14:17:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OJDZp23965 for ietf-calendar-bks; Mon, 24 Feb 2003 11:13:35 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OJDYd23961 for ; Mon, 24 Feb 2003 11:13:34 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 097488D7B9 for ; Mon, 24 Feb 2003 11:13:35 -0800 (PST) From: "Chris Olds" To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 11:13:34 -0800 Message-Id: <20030224191334.M65955@asitturnsout.org> In-Reply-To: <200302241240.15310.mark@WebServiceSolutions.com> References: <200302232018.26629.mark@WebServiceSolutions.com> <3E5A4CDD.8010801@Royer.com> <200302241240.15310.mark@WebServiceSolutions.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 2003.02.24 10:01 Doug Royer wrote: > > Mark Swanson wrote: >> On February 24, 2003 11:48 am, Doug Royer wrote: >> >>> In all uses of the 'NON-US-ASCII' ABNF definition in 2445 it allows for >>> zero or MORE octets. It looks to me as if it does allow for 1 or more >>> octet (multibyte) characters. >> >> I've searched all occurences of octet in 2445 and haven't found any >> references to multibyte characters. Since NON-US-ASCII is defined as >> %x80-xF8 how is it possible to even implicitly understand this means >> multibyte - especially when I see some utf-8 chinese characters I'm >> parsing have 0x05 as one of their bytes? Any utf-8 sequence that includes a byte 0x05 must be encoding a ^E (ENQ) character. In UTF-8, 7-bit ASCII is mapped 1:1, and nothing else uses bytes with the high bit clear. >>> Assuming you are correct and it should be %x80-FF, that looks to me >>> as if it would solve the problem by changing that alone. Have you >>> verified that all of the valid UTF-8 octet sequences that can include >>> 0xF9-FF are printable (not control) characters? If not we would have to >>> also exclude those characters sequences. >> >> There are no control characters in that range. Unless you're encoding a character at a code point >= 0x200000, there are no characters that use values in that range, period. >> However, it appears that simply allowing 0x80-0xFF will not do >> because while UTF-8 is an 8-bit character set for all of ASCII and >> latin1, as soon as you use Chinese it switches to 2 or more bytes >> which may contain characters below 0x80. This is wrong. UTF-8 is 8-bits for 7-bit ASCII only. Values in the upper half of Latin-1 are two bytes (as are all code points < 0x800); if the character is in an int named 'ch', the first byte will be (0xC0 | ch>>6), and the second byte will be (0x80 | (ch & 0x3F)). All non-ascii characters in UTF-8 are encoded by a lead byte with two or more high bits set, followed by a 0 bit, followed by as many high bits of the code point (absctract character) as will fit. This lead byte is followed by one or more bytes containing 0x80 and the next six bits of the code point; the number of follow bytes is the same as the number of leading 1 bits in the lead byte. Chinese characters will take 3 or 4 octets to encode, all of which will have at least the high bit set. > > I see your point. > > Would you like to propose the correct ABNF to make UTF-8 work in > 2445? :-) > I have been reading other WG lists where they are running into the > same or similar UTF-8 issues with respect to the ABNF. I think the > real problem is that the authors did not really understand charsets (Sorry > Frank and all) and just did their best. > > I agree that the charset part of the 2445 ABNF is busted. I think we > rely on the ABNF too much and should just default to text that says: > > Its UTF-8 - except you can not use control characters XXX,... > and that YYY needs to be quoted... From a conformance point of view, the only things I see lacking are that it should be explicit what one should do with invalid UTF-8 sequences and properly encoded C1 control characters (0x80-0x9F in Latin1); the ABNF allows all of the currently defined unicode characters, so it is currently permissive enough. For an overview of UTF-8 and some of the issues involved, see [1] (I have nothing to do with that, but Google liked it, and I agree). /cco [1] http://czyborra.com/utf/ -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Mon Feb 24 14:37:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23948 for ; Mon, 24 Feb 2003 14:37:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OJYEc24601 for ietf-calendar-bks; Mon, 24 Feb 2003 11:34:14 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OJYDd24597 for ; Mon, 24 Feb 2003 11:34:13 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id B909A8D7B9 for ; Mon, 24 Feb 2003 11:34:14 -0800 (PST) From: "Chris Olds" To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 11:34:14 -0800 Message-Id: <20030224193414.M30594@asitturnsout.org> In-Reply-To: <200302241348.56681.mark@WebServiceSolutions.com> References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241240.15310.mark@WebServiceSolutions.com> <200302241758.h1OHwf4V021734@smtp7.andrew.cmu.edu> <200302241348.56681.mark@WebServiceSolutions.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 24 Feb 2003 13:48:56 -0500, Mark Swanson wrote > > To try and summarize: > > 1. We need to ensure 0xf9-0xff does not contain any non-printable > characters with the UTF-8 encoding. Correct UTF-8 encoding of Unicode 3.1 will never use these octet values. > 2. UTF-8 capable parsers should parse after decoding UTF-8 > characters into UCS-4. That seems more complicated than needed. Since all of the characters that matter to the ABNF productions are ASCII, all I think a parser MUST do is return sequences containing octets matching NON-US-ASCII as-is; unless the rest of the system is UCS-4 aware, decoding into UCS-4 is a bug. Being 8-bit clean should be enough for a lot of systems. There's no reason to form UCS-4 characters just to parse. > 3. When dealing with UCS-4 characters we should use: > NON-US-ASCII = \u0080 - \uffff NON-US-ASCII should be left as-is, possibly with a note saying that a parser (or CS, or CUA, whatever) MAY or SHOULD validate that NON-US-ASCII sequences are valid UTF-8 sequences. In any case, UCS-4 defines code point blocks using values through 0x1FFFF. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Mon Feb 24 14:53:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24260 for ; Mon, 24 Feb 2003 14:53:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OJlUh25121 for ietf-calendar-bks; Mon, 24 Feb 2003 11:47:30 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OJlSd25115 for ; Mon, 24 Feb 2003 11:47:29 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id E9A044DA2 for ; Mon, 24 Feb 2003 14:47:01 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 14:45:32 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241758.h1OHwf4V021734@smtp7.andrew.cmu.edu> <200302241348.56681.mark@WebServiceSolutions.com> In-Reply-To: <200302241348.56681.mark@WebServiceSolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200302241445.32582.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > 1. We need to ensure 0xf9-0xff does not contain any non-printable > characters with the UTF-8 encoding. I wrote some code to display the above characters in latin-1 and utf-8. The results are: utf-8:���� 0:� 1:� 2:� 3:� latin1:ùúûüýþÿ 0:ù 1:ú 2:û 3:ü 4:ý 5:þ 6:ÿ You may not see the UTF-8 characters The latin-1 characters are correct as verified by my iso_8859_1 man page: 371 249 F9 ù LATIN SMALL LETTER U WITH GRAVE 372 250 FA ú LATIN SMALL LETTER U WITH ACUTE 373 251 FB û LATIN SMALL LETTER U WITH CIRCUMFLEX 374 252 FC ü LATIN SMALL LETTER U WITH DIAERESIS 375 253 FD ý LATIN SMALL LETTER Y WITH ACUTE 376 254 FE þ LATIN SMALL LETTER THORN 377 255 FF ÿ LATIN SMALL LETTER Y WITH DIAERESIS As for the UTF-8 characters, I see 4 symbols on my Linux terminal but I suppose that's no way to be 100% sure. Also, if I scroll the terminal these specific UTF-8 characters can change slightly. OK OK, I'm using a 2-year old Linux konsole I should probably upgrade to KDE3.1... If anyone knows the real way to check what these characters are mapped to please emal. BTW, if you want to see a snapshot of me editing a Chinese 2445 document in a _vi_ Linux text konsole click below... http://www.scheduleworld.com/china1.png Notice some of the strange rendering errors I get there too? Likely because of 2-year old software...too busy to upgrade... -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 15:15:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25150 for ; Mon, 24 Feb 2003 15:15:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OK2W825659 for ietf-calendar-bks; Mon, 24 Feb 2003 12:02:32 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OK2Vd25655 for ; Mon, 24 Feb 2003 12:02:31 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 0214F4DA2; Mon, 24 Feb 2003 15:02:04 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "Chris Olds" , "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 15:00:33 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241240.15310.mark@WebServiceSolutions.com> <20030224191334.M65955@asitturnsout.org> In-Reply-To: <20030224191334.M65955@asitturnsout.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302241500.33898.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From a conformance point of view, the only things I see lacking are that it > should be explicit what one should do with invalid UTF-8 sequences and > properly encoded C1 control characters (0x80-0x9F in Latin1); the ABNF > allows all of the currently defined unicode characters, so it is currently > permissive enough. http://czyborra.com/utf/ Thanks for the link. In it I see 0xf9-0xff are legal UTF-8 values. So this is the single modification to 2445 that I think should be made: NON-US-ASCII = %x80-xF8 changed to NON-US-ASCII = %x80-xff Thoughts? -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 15:19:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25233 for ; Mon, 24 Feb 2003 15:19:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OK7W525855 for ietf-calendar-bks; Mon, 24 Feb 2003 12:07:32 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OK7Vd25851 for ; Mon, 24 Feb 2003 12:07:31 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id C858A4DA2; Mon, 24 Feb 2003 15:07:05 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "Chris Olds" , "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 15:05:34 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241348.56681.mark@WebServiceSolutions.com> <20030224193414.M30594@asitturnsout.org> In-Reply-To: <20030224193414.M30594@asitturnsout.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200302241505.34668.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On February 24, 2003 02:34 pm, Chris Olds wrote: > On Mon, 24 Feb 2003 13:48:56 -0500, Mark Swanson wrote > > > To try and summarize: > > > > 1. We need to ensure 0xf9-0xff does not contain any non-printable > > characters with the UTF-8 encoding. > > Correct UTF-8 encoding of Unicode 3.1 will never use these octet values. Hmm. The link you sent me showed legal values for 0xf9-0xff in a table about 85% of the way through. latin1 utf-1 utf-8 utf-7,5 utf-7 JAVA HTML ù ù ù £ù +APk- \u00f9 ù ú ú ú £ú +APo- \u00fa ú û û û £û +APs- \u00fb û ü ü ü £ü +APw- \u00fc ü ý ý ý £ý +AP0- \u00fd ý þ þ þ £þ +AP4- \u00fe þ ÿ ÿ ÿ £ÿ +AP8- \u00ff ÿ -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 15:46:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26093 for ; Mon, 24 Feb 2003 15:46:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OKbLM27249 for ietf-calendar-bks; Mon, 24 Feb 2003 12:37:21 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OKbKd27245 for ; Mon, 24 Feb 2003 12:37:20 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 386918D7B9; Mon, 24 Feb 2003 12:37:22 -0800 (PST) From: "Chris Olds" To: Mark Swanson , "Chris Olds" , "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 12:37:22 -0800 Message-Id: <20030224203722.M48554@asitturnsout.org> In-Reply-To: <200302241505.34668.mark@WebServiceSolutions.com> References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241348.56681.mark@WebServiceSolutions.com> <20030224193414.M30594@asitturnsout.org> <200302241505.34668.mark@WebServiceSolutions.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 24 Feb 2003 15:05:34 -0500, Mark Swanson wrote > On February 24, 2003 02:34 pm, Chris Olds wrote: > > On Mon, 24 Feb 2003 13:48:56 -0500, Mark Swanson wrote > > > > > To try and summarize: > > > > > > 1. We need to ensure 0xf9-0xff does not contain any non-printable > > > characters with the UTF-8 encoding. > > > > Correct UTF-8 encoding of Unicode 3.1 will never use these octet values. > > Hmm. The link you sent me showed legal values for 0xf9-0xff in a > table about 85% of the way through. > > latin1 utf-1 utf-8 utf-7,5 utf-7 JAVA HTML > ù ù ù £ù +APk- \u00f9 ù > ú ú ú £ú +APo- \u00fa ú > û û û £û +APs- \u00fb û > ü ü ü £ü +APw- \u00fc ü > ý ý ý £ý +AP0- \u00fd ý > þ þ þ £þ +AP4- \u00fe þ > ÿ ÿ ÿ £ÿ +AP8- \u00ff ÿ The UCS values 0xF9-0xFF can be encoded in UTF-8, but the octet values 0xF9-0xFF cannot appear in a valid UTF-8 sequence representing Unicode 3.1 (or prior) code points. The example you quote correctly shows that the UCS values \u00F9-\u00FF are encoded in UTF-8 by à (an octet with value 0xC3) followed by another octet in the range 0xB9-0xBF. It's not the case that the characters ùúûüýþÿ cannot be used in the messages defined by rfc2445 (et al), but it is the case that the octet values 0xF9-0xDD cannot appear in those messages. This is the difference between UCS-4 (a character set) and UTF-8 (a transformation format). /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Mon Feb 24 16:20:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26913 for ; Mon, 24 Feb 2003 16:20:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OLDPF28331 for ietf-calendar-bks; Mon, 24 Feb 2003 13:13:25 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OLDOd28327 for ; Mon, 24 Feb 2003 13:13:24 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 266C64DA2; Mon, 24 Feb 2003 16:13:01 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "Chris Olds" , "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 16:11:22 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241505.34668.mark@WebServiceSolutions.com> <20030224203722.M48554@asitturnsout.org> In-Reply-To: <20030224203722.M48554@asitturnsout.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200302241611.23520.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Chris (and to everyone else for responding). I haven't found documentation that 0xf9-0xff is not allowed, but I have found in the link Chris provided and in RFC 2779: - - The octet values FE and FF never appear. Is there a specific reason the other 5 bytes do not appear? I see the start octet that states the following bytes are to encode: 0400 0000-7FFF FFFF (UCS-4) starts with UTF-8 (1111110x) (0xFC). If we do not allow 0xFC we will not allow a very large mapping of UCS-4 characters from 0400 0000-7FFF FFFF. - -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+Wop7BtoFHHwdJ/cRAovnAKCgAg+EZS89N+iv4mjuYWjCFo/8dQCgkZ6A uAw3AHwr7O464iQfFLFbl80= =x9ex -----END PGP SIGNATURE----- From owner-ietf-calendar@mail.imc.org Mon Feb 24 16:53:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27884 for ; Mon, 24 Feb 2003 16:53:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OLlBS00914 for ietf-calendar-bks; Mon, 24 Feb 2003 13:47:11 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OLlAd00908 for ; Mon, 24 Feb 2003 13:47:10 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 8EACF8D7B9 for ; Mon, 24 Feb 2003 13:47:12 -0800 (PST) From: "Chris Olds" To: Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 13:47:12 -0800 Message-Id: <20030224214712.M11661@asitturnsout.org> In-Reply-To: <200302241611.23520.mark@WebServiceSolutions.com> References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241505.34668.mark@WebServiceSolutions.com> <20030224203722.M48554@asitturnsout.org> <200302241611.23520.mark@WebServiceSolutions.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 24 Feb 2003 16:11:22 -0500, Mark Swanson wrote > Thanks Chris (and to everyone else for responding). Glad I can help (I'm new here, but I learned a lot about UCS/UTF working on XML WGs). > I haven't found documentation that 0xf9-0xff is not allowed, but I > have found in the link Chris provided and in RFC 2779: > > - - The octet values FE and FF never appear. > > Is there a specific reason the other 5 bytes do not appear? > > I see the start octet that states the following bytes are to encode: > 0400 0000-7FFF FFFF (UCS-4) > starts with UTF-8 (1111110x) (0xFC). > > If we do not allow 0xFC we will not allow a very large mapping of > UCS-4 characters from 0400 0000-7FFF FFFF. This is true, but not (currently) that big a deal. Most importantly, Unicode 3.1 (the current version) doesn't define any characters from 0x20000 up (the jargon is that only the BMP (Basic Multilingual Plane) and the 1st Astral Plane (0x10000-0x1FFFF) are defined). For these planes, a lead byte of 11110xxx (0xF0-0xF7) is (more than) enough (in fact, it will encode 21 bits of data, covering the BMP and the first 31 astral planes). Since a lead byte of 0xF8 (111110 00) allows 24 bits worth of characters to be encoded, I cannot imagine a need for greater range anytime soon. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Mon Feb 24 17:27:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28710 for ; Mon, 24 Feb 2003 17:27:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OMGhs02590 for ietf-calendar-bks; Mon, 24 Feb 2003 14:16:43 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OMGfd02582 for ; Mon, 24 Feb 2003 14:16:41 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 82AE74DA2 for ; Mon, 24 Feb 2003 17:16:15 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 17:14:31 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241611.23520.mark@WebServiceSolutions.com> <20030224214712.M11661@asitturnsout.org> In-Reply-To: <20030224214712.M11661@asitturnsout.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302241714.31841.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 24, 2003 04:47 pm, Chris Olds wrote: > On Mon, 24 Feb 2003 16:11:22 -0500, Mark Swanson wrote > > > > If we do not allow 0xFC we will not allow a very large mapping of > > UCS-4 characters from 0400 0000-7FFF FFFF. > > This is true, but not (currently) that big a deal. Most importantly, > Unicode 3.1 (the current version) doesn't define any characters from > 0x20000 up (the jargon is that only the BMP (Basic Multilingual Plane) and > the 1st Astral Plane (0x10000-0x1FFFF) are defined). For these planes, a > lead byte of 11110xxx (0xF0-0xF7) is (more than) enough (in fact, it will > encode 21 bits of data, covering the BMP and the first 31 astral planes). > Since a lead byte of 0xF8 (111110 00) allows 24 bits worth of characters to > be encoded, I cannot imagine a need for greater range anytime soon. It seems we have a minor issue and I'd like to know how to proceed. We could change the spec and forget about this forever, or leave it as is and forget about it without harm for some period of time. What is the process for voting on something like this? How would we take an issue (even a minor one like this) and its solution and see it through to making it part of the RFC? Thanks. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 18:11:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29712 for ; Mon, 24 Feb 2003 18:11:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ON7qu04218 for ietf-calendar-bks; Mon, 24 Feb 2003 15:07:52 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ON7pd04211 for ; Mon, 24 Feb 2003 15:07:51 -0800 (PST) Subject: Re: RFC: UTF-8 iCalendar bug solution To: "Chris Olds" Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Mon, 24 Feb 2003 18:07:50 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 02/24/2003 06:07:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, excuse my ignorance if I say something stupid but here goes. One of the missions of all working groups is to ensure that our drafts/RFC's live well in the world of internationalization. I believe Unicode is one of those areas. We "sort of " reviewed our drafts a year ago and said we felt they were "OK". Do you feel that is the case - it sounds like you might have an idea - and I'm taking the liberty to check for a level-set. If you think we're OK, let us know. If you think this is a problem, can you let us know what we need to do to make sure our RFC's handle unicode, etc. "Chris Olds" > cc: Sent by: Subject: Re: RFC: UTF-8 iCalendar bug solution owner-ietf-calendar@m ail.imc.org 02/24/03 04:47 PM On Mon, 24 Feb 2003 16:11:22 -0500, Mark Swanson wrote > Thanks Chris (and to everyone else for responding). Glad I can help (I'm new here, but I learned a lot about UCS/UTF working on XML WGs). > I haven't found documentation that 0xf9-0xff is not allowed, but I > have found in the link Chris provided and in RFC 2779: > > - - The octet values FE and FF never appear. > > Is there a specific reason the other 5 bytes do not appear? > > I see the start octet that states the following bytes are to encode: > 0400 0000-7FFF FFFF (UCS-4) > starts with UTF-8 (1111110x) (0xFC). > > If we do not allow 0xFC we will not allow a very large mapping of > UCS-4 characters from 0400 0000-7FFF FFFF. This is true, but not (currently) that big a deal. Most importantly, Unicode 3.1 (the current version) doesn't define any characters from 0x20000 up (the jargon is that only the BMP (Basic Multilingual Plane) and the 1st Astral Plane (0x10000-0x1FFFF) are defined). For these planes, a lead byte of 11110xxx (0xF0-0xF7) is (more than) enough (in fact, it will encode 21 bits of data, covering the BMP and the first 31 astral planes). Since a lead byte of 0xF8 (111110 00) allows 24 bits worth of characters to be encoded, I cannot imagine a need for greater range anytime soon. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Mon Feb 24 18:14:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29783 for ; Mon, 24 Feb 2003 18:14:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ON7BG04176 for ietf-calendar-bks; Mon, 24 Feb 2003 15:07:11 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ON79d04172 for ; Mon, 24 Feb 2003 15:07:09 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1ON78b2022168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Feb 2003 15:07:11 -0800 Message-ID: <3E5AA596.6090103@Royer.com> Date: Mon, 24 Feb 2003 16:07:02 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241611.23520.mark@WebServiceSolutions.com> <20030224214712.M11661@asitturnsout.org> <200302241714.31841.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030700090804000207000404" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030700090804000207000404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > > It seems we have a minor issue and I'd like to know how to proceed. > We could change the spec and forget about this forever, or leave it as is and > forget about it without harm for some period of time. What is the process for > voting on something like this? > > How would we take an issue (even a minor one like this) and its solution and > see it through to making it part of the RFC? I have heard that there are errata pages some place one the IETF web site. I just did a quick check and could not find them. Short of that Pat or Bob (our chairs) could post them on the calsch.org web site :-) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030700090804000207000404 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjQyMzA3MDNaMCMGCSqGSIb3DQEJBDEWBBQp psXFfqY1TluBCulGv574HaRdhTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAcZ1ST2moIq7y kPoXCBNm7p9YImoV+oli3EeWeC0C+epG/vvofjFNRaqdBsVYgXs/urrvf3FYclthrYFyeS1d gKjE7T/ioLz/M4i4wnmCfdkynhjM6Yznh6nag7x22chET4XeFPBiEUl6bGex2QvNBvqByva5 uEBzuSRlgWGlpVkBozq5cUPPoq7EzY42wuuytfiyECwVe7Mw2ooIdyDgCuB1RTbTLMxVsDs+ zMfNrf2mCN7F8YX0HXejhFu7Efwu7mRXcO3CmATar6n7i8361Gc2bnRpcJbKXxDYbK3hMj9J 0Oor8f5A74E5R19sDUZBFiMfz+ubQFN58P/ie2V4tAAAAAAAAA== --------------ms030700090804000207000404-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 18:25:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29962 for ; Mon, 24 Feb 2003 18:25:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ONCQJ04372 for ietf-calendar-bks; Mon, 24 Feb 2003 15:12:26 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ONCOd04359 for ; Mon, 24 Feb 2003 15:12:24 -0800 (PST) Subject: Re: RFC: UTF-8 iCalendar bug solution To: Mark Swanson Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Mon, 24 Feb 2003 18:12:26 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 02/24/2003 06:12:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark. Here's the process when there is an issue. If someone feels there is one, they articulate that on the list - hopefully in a small note (i.e. without all the appends, dialog, etc.). Ask the question to the list - what does this list think. Then, it is up to the chairs to see if there is 'rough concensus'. If there is, then we go back to the authors of the RFC's to get the items changed, and the RFC gets resubmitted and needs to go through last call, etc. Does that make sense. To the rest of the list, it helps if people speak up so we, the chairs, can get a feel for concensus. Note - one person making a statement or opinion IS NOT consensus. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Mark Swanson ions.com> cc: Sent by: Subject: Re: RFC: UTF-8 iCalendar bug solution owner-ietf-calendar@m ail.imc.org 02/24/03 05:14 PM On February 24, 2003 04:47 pm, Chris Olds wrote: > On Mon, 24 Feb 2003 16:11:22 -0500, Mark Swanson wrote > > > > If we do not allow 0xFC we will not allow a very large mapping of > > UCS-4 characters from 0400 0000-7FFF FFFF. > > This is true, but not (currently) that big a deal. Most importantly, > Unicode 3.1 (the current version) doesn't define any characters from > 0x20000 up (the jargon is that only the BMP (Basic Multilingual Plane) and > the 1st Astral Plane (0x10000-0x1FFFF) are defined). For these planes, a > lead byte of 11110xxx (0xF0-0xF7) is (more than) enough (in fact, it will > encode 21 bits of data, covering the BMP and the first 31 astral planes). > Since a lead byte of 0xF8 (111110 00) allows 24 bits worth of characters to > be encoded, I cannot imagine a need for greater range anytime soon. It seems we have a minor issue and I'd like to know how to proceed. We could change the spec and forget about this forever, or leave it as is and forget about it without harm for some period of time. What is the process for voting on something like this? How would we take an issue (even a minor one like this) and its solution and see it through to making it part of the RFC? Thanks. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Mon Feb 24 18:47:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00557 for ; Mon, 24 Feb 2003 18:47:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ONgUj05590 for ietf-calendar-bks; Mon, 24 Feb 2003 15:42:30 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ONgTd05585 for ; Mon, 24 Feb 2003 15:42:29 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 9AD758D7B9; Mon, 24 Feb 2003 15:42:31 -0800 (PST) From: "Chris Olds" To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 15:42:31 -0800 Message-Id: <20030224234231.M27902@asitturnsout.org> In-Reply-To: References: X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 24 Feb 2003 18:07:50 -0500, pregen wrote > Chris, excuse my ignorance if I say something stupid but here goes. > One of the missions of all working groups is to ensure that our > drafts/RFC's live well in the world of internationalization. I > believe Unicode is one of those areas. We "sort of " reviewed our > drafts a year ago and said we felt they were "OK". Do you feel that > is the case - it sounds like you might have an idea - and I'm taking > the liberty to check for a level-set. If you think we're OK, let us > know. If you think this is a problem, can you let us know what we > need to do to make sure our RFC's handle unicode, etc. As I said, I'm new here; I started writing an rfc2445 parser last week (in Python; I know there are parsers in other languages, but since I wanted to understand the RFC anyway, I thought, 'what the heck...'). I haven't actually sat down and read much beyond 2445, so I can't yet give any opinion on the recent draft; it's on my list of VTODO's... In 2445, there appears to be a reliance on MIME encapsulation to carry encoding (and character set) information, which I'm not completely comfortable with, but that seems to be the way these things are done in IETF work. It certainly isn't very clear to me how the character-range productions that include NON-US-ASCII are supposed to be used if a MIME-encapsulated iCalendar object specifies a charset parameter other than UTF-8 (e.g. "text/calendar; charset=ISO-8859-15"); it appears that a) people mostly Don't Do That, and b) if they did, the expectation is that applications should behave as they would if the data was transcoded into UTF-8 and presented. The problem, of course, is that I just made that up. As I said, I still need to read the current CAP draft, but I'll be sure to give my opinion on i18n either way. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Mon Feb 24 18:47:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00586 for ; Mon, 24 Feb 2003 18:47:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ONeeu05550 for ietf-calendar-bks; Mon, 24 Feb 2003 15:40:40 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ONecd05545 for ; Mon, 24 Feb 2003 15:40:38 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1ONeab2022434 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Feb 2003 15:40:40 -0800 Message-ID: <3E5AAD6E.9010003@Royer.com> Date: Mon, 24 Feb 2003 16:40:30 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040003050301050301090405" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040003050301050301090405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit When the WG feels that it is a bug or typo in an RFC and prior to issuing a new RFC - could we list them on calsch.org ? Perhaps an errata link for 244[567] + guide ? pregen@egenconsulting.com wrote: > > Hi Mark. Here's the process when there is an issue. ... > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040003050301050301090405 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjQyMzQwMzBaMCMGCSqGSIb3DQEJBDEWBBRw lJFu8eC7XmwOQiHww1OVI1pHvDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAklC5EwGCd8N/ 4ZO1lrNXlcbnMCaY80k3wAE0jrHVQyCE38NhfL7Sig4v7O7MB4PFHQrb2/G3ri7BBUBdju6n 3kO2k3cKJn8WEPQ9OPvKzwc8ydaRLbyWyhh7Vqce0eitCCkTTCzo2Mp4F2C64jQzJoeMzTIF qykUSTSicHEbQ/KAXP+GbVGSk4M1JhROLW1ZqtqEGKSCoHyO1TwZ2KKlDiygm0IfQbOSyhEk SuDL9tGM9J9eM25TddOIClbduH1K80c839hCAOV/ylaJT3jHdIOdQitKFWcl1PNe/ssLrNne sq6UUjeShrSkiqgPHnctq4ZHMMgLDHpEiT4wyQ/ZWAAAAAAAAA== --------------ms040003050301050301090405-- From owner-ietf-calendar@mail.imc.org Mon Feb 24 19:49:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01737 for ; Mon, 24 Feb 2003 19:49:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1P0dcF08045 for ietf-calendar-bks; Mon, 24 Feb 2003 16:39:38 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1P0dbd08040 for ; Mon, 24 Feb 2003 16:39:37 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 6D8804DA2; Mon, 24 Feb 2003 19:39:14 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org, Doug Royer , "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Mon, 24 Feb 2003 19:37:15 -0500 User-Agent: KMail/1.5 References: <3E5AAD6E.9010003@Royer.com> In-Reply-To: <3E5AAD6E.9010003@Royer.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200302241937.16375.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On February 24, 2003 06:40 pm, Doug Royer wrote: > When the WG feels that it is a bug or typo in an RFC and > prior to issuing a new RFC - could we list them on calsch.org ? > > Perhaps an errata link for 244[567] + guide ? In order to help build consensus on this issue I aggree! - -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+Wrq7BtoFHHwdJ/cRAoytAJ9LNKXKgjns+uaaO/dMRdoHhNB7DQCgtk0V 3XUH8VifVM8YZtWHE54TAQU= =ylyb -----END PGP SIGNATURE----- From owner-ietf-calendar@mail.imc.org Tue Feb 25 05:17:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22501 for ; Tue, 25 Feb 2003 05:17:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PA86E20051 for ietf-calendar-bks; Tue, 25 Feb 2003 02:08:06 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PA81d20042 for ; Tue, 25 Feb 2003 02:08:05 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 41FC1155C6; Tue, 25 Feb 2003 11:07:54 +0100 (CET) Date: Tue, 25 Feb 2003 11:07:54 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: Proposed changed GET-CAPABILITY Command Message-ID: <20030225100754.GA35811@inet.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Feb 24, 2003 at 01:06:04PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > general agreement about some changes but no proposed change text. I have > taken the task of making the change text as I was the one who proposed > much of the changes. Thanks for doing this, and I like your proposed text in general. I do have a couple minor notes. > All CAP implemenations MUST support the "GET-CAPABLITY" command. > Furthermore, the "GET-CAPABLITY" command SHOULD be issued early in the CAP > session to properly detect restrictions or abilities of the other end > point. OK. > A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial > connection. Another "GET-CAPABILITY" command subsequent to successful > authentiation MAY be useful in case the CS alters the options allowed > based on the authentication credentials provided. I'm not sure I follow you here. We don't have a CAP (application-layer) authentication phase, rather, we rely on SASL as mandated by BEEP. So basically this means, when a channel is established and the peers are able to exchange commands, authentication has already occurred in all cases (even if the peer is anonymous). You are thinking of INDENTIFY, right? so the sentence above is still relevant but should probably be reworded as: A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. Another "GET-CAPABILITY" command subsequent to a change of credentials MAY be useful in case the CS alters the options allowed based on the authorization credentials provided. This may happen when an IDENTIFY command is sent. > The CS MUST send a "GET-CAPABILITY" command to a CUA after the initial > connection. Multiple "GET-CAPABILITY" commands to the CUA SHOULD NOT be > necessary. Now that I look at this more closely: you still explicitely identify exchanges as going from the CUA to the CS or from the CS to the CUA. Is this right? I thought what you had in mind was more like: A CUA MUST send a "GET-CAPABILITY" command after the initial ... The CS MUST send a "GET-CAPABILITY" command after the initial > MULTIPART 1 A comma separated list of lower cased MIME > multipart subtypes that the sender supports. > If multipart is not supported then the property > has no value (ie: an empty list). Example: > MULTIPART:related,alternate How would an empty list appear? MULTIPART: Is this even allowed by the ABNF? Should we use an explicit `none' instead? > RECUR-ACCEPTED 1 A boolean value to indicate whether recurrence > rules are acceptable. > [...] > > RECUR-ACCEPTED 1 A boolean value to indicate whether recurrence > rules are acceptable. You have this twice. > I would like to propose that we remove bounded latency from GET-CAPAIBLITY > for 2 reasons: > > 1: It should not require any great number of cycles for any implementation > to actually implement and perform compared to most other commands. > 2: It needs to be done before any other commands are done and once done > does not need to be performed again (after authentication that is). > > As such we can simplify the command a bit by removing the latency related > properties and trimming down the example above. After all, its somewhat > foolhearty to NOT wait for this relatively quick command to complete > before doing other commands like C&S workflow... I absolutely agree. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Tue Feb 25 05:36:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22778 for ; Tue, 25 Feb 2003 05:36:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PAPmS21593 for ietf-calendar-bks; Tue, 25 Feb 2003 02:25:48 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PAPld21587 for ; Tue, 25 Feb 2003 02:25:47 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 714D5155C6; Tue, 25 Feb 2003 11:25:47 +0100 (CET) Date: Tue, 25 Feb 2003 11:25:47 +0100 From: Andrea Campi To: Mark Swanson Cc: ietf-calendar@imc.org Subject: Re: RFC: UTF-8 iCalendar bug solution Message-ID: <20030225102547.GC35811@inet.it> References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241611.23520.mark@WebServiceSolutions.com> <20030224214712.M11661@asitturnsout.org> <200302241714.31841.mark@WebServiceSolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302241714.31841.mark@WebServiceSolutions.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Feb 24, 2003 at 05:14:31PM -0500, Mark Swanson wrote: > It seems we have a minor issue and I'd like to know how to proceed. > We could change the spec and forget about this forever, or leave it as is and > forget about it without harm for some period of time. What is the process for > voting on something like this? Picking one semi-random message to reply to: Even if it's a minor issue, and no character should use that range, I'd say we should fix RFC2445 to correctly include 0x80-0xff. That would be more future-proof: with the current text, a conformant implementation is free to reject valid, albeit very rare, UTF-8 codes. With the proposed change, an implementation will be free to (mostly) not even care about what's in a value. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Tue Feb 25 09:56:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02432 for ; Tue, 25 Feb 2003 09:56:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PEe8706988 for ietf-calendar-bks; Tue, 25 Feb 2003 06:40:08 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PEe7d06984 for ; Tue, 25 Feb 2003 06:40:07 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 335A94F2C; Tue, 25 Feb 2003 09:39:42 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: Andrea Campi Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Tue, 25 Feb 2003 09:39:49 -0500 User-Agent: KMail/1.5 Cc: ietf-calendar@imc.org References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241714.31841.mark@WebServiceSolutions.com> <20030225102547.GC35811@inet.it> In-Reply-To: <20030225102547.GC35811@inet.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200302250939.51012.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On February 25, 2003 05:25 am, Andrea Campi wrote: > Picking one semi-random message to reply to: > > Even if it's a minor issue, and no character should use that > range, I'd say we should fix RFC2445 to correctly include 0x80-0xff. > That would be more future-proof: with the current text, a conformant > implementation is free to reject valid, albeit very rare, UTF-8 > codes. With the proposed change, an implementation will be free to > (mostly) not even care about what's in a value. > > Bye, > Andrea I agree, 0x80-0xff should be used even though 0xfe and 0xff are not valid UTF-8. In the perfect world, there would be no competing and conflicting character encodings. However, latin1 is quite dominant and I'm seeing latin1 encoded characters in iCalendars published on many websites (including Mozilla's and Apple's). This is illegal, but if some of the most popular iCalendar clients allow people to use latin1 (which is the most popular character set encoding) then we are going to see a lot of it in the real world. Note that libical (no offense Andrea!) allows latin1 characters and is used by a great many iCalendar projects. Here's something that may make this easier to swallow: the printable latin1 encodings from 0xA0 - 0xFF would likely never be found side by side. F.E. ææ is an unlikely combination. So is µµ. etc... If you look at the iso_8859_1 man page (or any source of the latin1 character set) you'll see this. This means a UTF-8 decoder will know that the non-ascii character in Independência is not UTF-8 and can fall back to latin1. (The decoder knows because any UTF-8 character above 0x80 MUST be followed by another character above 0x80) If the character is not encoded in latin1 then you are hosed unless you are told what character encoding to fall back to. Java already works this way. It's how I currently handle the current mix of latin1 and UTF-8 iCalendars in the real world. The small number of characters we are blocking (0xf9-0xff) actually are being used (German holidays come to mind). So that's my case for supporting 0x80-0xFF. I'm lucky enough to be working in the Java language that takes care of this for me. I'm really curious to know what options are available for C/C++ and projects like libical. What UTF-8 decoding options are available and are they good enough to fallback to another character encoding (like latin1) when illegal UTF-8 is found? Cheers. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Tue Feb 25 10:26:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03095 for ; Tue, 25 Feb 2003 10:26:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PFBem07717 for ietf-calendar-bks; Tue, 25 Feb 2003 07:11:40 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1PFBcd07708 for ; Tue, 25 Feb 2003 07:11:38 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022510085301564 for ; Tue, 25 Feb 2003 10:08:53 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Feb 2003 10:03:52 -0500 Message-ID: <3E5B85D8.6080604@centive.com> Date: Tue, 25 Feb 2003 10:03:52 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241240.15310.mark@WebServiceSolutions.com> <200302241758.h1OHwf4V021734@smtp7.andrew.cmu.edu> <200302241348.56681.mark@WebServiceSolutions.com> <20030224193414.M30594@asitturnsout.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2003 15:03:52.0703 (UTC) FILETIME=[1C1940F0:01C2DCDF] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris Olds wrote: >There's no reason to form UCS-4 >characters just to parse. > However, it would be reasonable for the spec to take that approach, even if the implementations find a more efficient way. If we consider ABNF to be a statement about characters, rather than bytes, then it is independent of the character set in use (provided all specified characters are available--don't go waving EBCDIC in my face ;-). So, conceptually, the "%x80-F8" refers to the Unicode characters \u0080-\u00f8. Under this interpretation, NON-US-ASCII should be redefined to be \u00000080-\uffffffff ("\u" now being taken as specifying 4 bytes; I know it usually doesn't). Better would be if we had a complement operator in ABNF, but it doesn't look like we do. If we did, we could write something like "NON-US-ASCII = ! US-ASCII" and "US-ASCII = %x00-7F". -- /==============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |==============================================================| |The sooner you fall behind, the more time you'll have to catch| |up! | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 25 11:22:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05162 for ; Tue, 25 Feb 2003 11:22:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PG9YK13616 for ietf-calendar-bks; Tue, 25 Feb 2003 08:09:34 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PG9Xd13612 for ; Tue, 25 Feb 2003 08:09:33 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1PG9Tb2029793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Feb 2003 08:09:33 -0800 Message-ID: <3E5B9534.3000606@Royer.com> Date: Tue, 25 Feb 2003 09:09:24 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302241714.31841.mark@WebServiceSolutions.com> <20030225102547.GC35811@inet.it> <200302250939.51012.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020204000201070706050101" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020204000201070706050101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > > I'm really curious to know what options are available for C/C++ and projects > like libical. What UTF-8 decoding options are available and are they good > enough to fallback to another character encoding (like latin1) when illegal > UTF-8 is found? As all iCalendar objects are MIME objects the charset is in the MIME header. So there is no need to fall back to anything. For CAP the charset/lang to use is determined by the commands, so nothing to fall back to. If you are using the X charset and get a character not in the X charset, someone sent you trash. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020204000201070706050101 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjUxNjA5MjRaMCMGCSqGSIb3DQEJBDEWBBSm 1a0Fr/RobGAlLgpRAUGncLUqvjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAHYyyaBkv5R4G 5Ox7IzogR36MnUq8Z9vA8uWNBkFyFjZ4nOLUkdINMLOVbm4RTsZUOmy3FQSLDgz1Ixt5+qL0 0BjcPFjSytp5lCKrOliZW5pXw68sAAmoMnClvthAyX62vgz5nlJZD4BIZl7BWfUnKX1mXQmH ozKiKd9VmIJf0ty+YfIWXc6Lh/B7cX6HxcVtUap3Xv3zhZgkd0LQ9HXWs4j0SfiGwIOD9Nsj ROXGwytA15OOg4Z/MxLGJc/LtWx6VbjFRwVoUXZAS7my7VzLgWjjaCcf9i0b9x5BKM30Bw3s SVn1W4nWnOJszh8svedqHsxN0LfPfZ8qvCV0d2aKjAAAAAAAAA== --------------ms020204000201070706050101-- From owner-ietf-calendar@mail.imc.org Tue Feb 25 11:32:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05562 for ; Tue, 25 Feb 2003 11:32:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PGMq714197 for ietf-calendar-bks; Tue, 25 Feb 2003 08:22:52 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PGMod14193 for ; Tue, 25 Feb 2003 08:22:50 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1PGMmb2029898 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Feb 2003 08:22:51 -0800 Message-ID: <3E5B9852.3030603@Royer.com> Date: Tue, 25 Feb 2003 09:22:42 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Proposed changed GET-CAPABILITY Command References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040900000100000309060807" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040900000100000309060807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > A while back there was some WG discussion about the GET-CAPABILITY > command and whether or not there should be defaulting or not and if the > command should be required of all sides of the CAP protocol. There > seemed to be general agreement about some changes but no proposed change > text. I have taken the task of making the change text as I was the one > who proposed much of the changes. The 'cap-17-FEB-2003' version already has them as mandatory: A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. The "GET-CAPABILITY" command and reply MUST BE implemented by all CSs and CUAs. I went to edit the draft and noticed that I had in fact already done that. Is what I have not done is removed the word 'default' and it associated text from some of the properties descriptions. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040900000100000309060807 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjUxNjIyNDJaMCMGCSqGSIb3DQEJBDEWBBSF 7Q4DMG1cuWFf/x2hu085KZZREjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAvI78wrNY4RXT WqyQtYwgzrv4iGvrOp38bWx0e9grbvM1mD2zEyUKF/RXSaaAkF3ai5SydG3kllPw4mMuv9P3 38iE75Ke9kFatMhmWy6L9sMlXanXUWMUJb8zBM+nhC9IJ9GuAbjfYBjcDktK7jApI1SoiQr0 GE0/YiAQ+7BK+a0e53YqFzwe6RrTSfv4cHLe8vw6rCS8/4vLYU5Kxf1DEtqB2YuJSEXEcSaX WLcQm0JBlqNgn0+pIEIr1XcLrBn3gL7V6sU5usJZborMx9U8R50cVYIbmboGaANFMHBhAcr5 4GrA2C4/o25WnrNub4YOsdSl0Mwjvr6umVAqe87jJwAAAAAAAA== --------------ms040900000100000309060807-- From owner-ietf-calendar@mail.imc.org Tue Feb 25 11:41:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05842 for ; Tue, 25 Feb 2003 11:41:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PGKH314110 for ietf-calendar-bks; Tue, 25 Feb 2003 08:20:17 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PGKGd14105 for ; Tue, 25 Feb 2003 08:20:16 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id DCBFE4F2C; Tue, 25 Feb 2003 11:19:48 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: John Stracke , "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Tue, 25 Feb 2003 11:19:54 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <20030224193414.M30594@asitturnsout.org> <3E5B85D8.6080604@centive.com> In-Reply-To: <3E5B85D8.6080604@centive.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302251119.54729.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 25, 2003 10:03 am, John Stracke wrote: > Chris Olds wrote: > >There's no reason to form UCS-4 > >characters just to parse. > > However, it would be reasonable for the spec to take that approach, even > if the implementations find a more efficient way. If we consider ABNF > to be a statement about characters, rather than bytes, then it is > independent of the character set in use (provided all specified I really like the wording of that statement. > characters are available--don't go waving EBCDIC in my face ;-). So, > conceptually, the "%x80-F8" refers to the Unicode characters \u0080-\u00f8. > > Under this interpretation, NON-US-ASCII should be redefined to be > \u00000080-\uffffffff ("\u" now being taken as specifying 4 bytes; I > know it usually doesn't). Better would be if we had a complement > operator in ABNF, but it doesn't look like we do. If we did, we could > write something like "NON-US-ASCII = ! US-ASCII" and "US-ASCII = %x00-7F". I like this interpretation because it clearly states how 2445 works with unicode. Doug mentioned previously that the cases were covered for multiple octets (except for the minor 0xf9-0xff issue) but I think using sentences like: "The ABNF is a statement about characters rather than bytes" and "NON-US-ASCII = \u00000080-\uffffffff" make it perfectly clear. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Tue Feb 25 12:04:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06526 for ; Tue, 25 Feb 2003 12:04:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PGv0M15356 for ietf-calendar-bks; Tue, 25 Feb 2003 08:57:00 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1PGuxd15350 for ; Tue, 25 Feb 2003 08:56:59 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022511594902534 for ; Tue, 25 Feb 2003 11:59:49 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 Feb 2003 11:54:49 -0500 Message-ID: <3E5B9FD8.8070908@centive.com> Date: Tue, 25 Feb 2003 11:54:48 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <20030224193414.M30594@asitturnsout.org> <3E5B85D8.6080604@centive.com> <200302251119.54729.mark@WebServiceSolutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2003 16:54:49.0072 (UTC) FILETIME=[9B9A8F00:01C2DCEE] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Swanson wrote: >but I think using sentences like: > >"The ABNF is a statement about characters rather than bytes" and >"NON-US-ASCII = \u00000080-\uffffffff" > >make it perfectly clear. > > Mind you, this isn't the standard interpretation of ABNF; the ABNF RFC takes the other approach. From RFC-2234, sectino 2.3: > Rules resolve into a string of terminal values, sometimes called > characters. In ABNF a character is merely a non-negative integer. > In certain contexts a specific mapping (encoding) of values into a > character set (such as ASCII) will be specified. > But it would be reasonable for a clarified RFC-2445 to specify that the non-negative integers in question are Unicode. -- /=================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=================================================================| |Two words that inspire the same feeling of dread are synominous. | \=================================================================/ From owner-ietf-calendar@mail.imc.org Tue Feb 25 12:10:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06684 for ; Tue, 25 Feb 2003 12:10:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PGvSc15367 for ietf-calendar-bks; Tue, 25 Feb 2003 08:57:28 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PGvRd15363 for ; Tue, 25 Feb 2003 08:57:27 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 677384F2C for ; Tue, 25 Feb 2003 11:57:03 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Tue, 25 Feb 2003 11:57:05 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302250939.51012.mark@WebServiceSolutions.com> <3E5B9534.3000606@Royer.com> In-Reply-To: <3E5B9534.3000606@Royer.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200302251157.07339.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On February 25, 2003 11:09 am, Doug Royer wrote: > As all iCalendar objects are MIME objects the charset is in the MIME > header. So there is no need to fall back to anything. For CAP the > charset/lang to use is determined by the commands, so nothing to > fall back to. > > If you are using the X charset and get a character not in the X charset, > someone sent you trash. I think the big problem though is that many real-world applications (not SW) are allowing a quickly growing userbase to create latin1 iCalendar objects. Perhaps if this trend continues for any length of time there will be too much momentum and supporting latin1 fallback will be unavoidable? - -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+W6BhBtoFHHwdJ/cRAp++AKCGJq0zv9fvT527GJ90xYZytzoGKQCcC4MY GzPYkOBMtDTB14/3SvmgqU4= =LIiC -----END PGP SIGNATURE----- From owner-ietf-calendar@mail.imc.org Tue Feb 25 12:58:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08649 for ; Tue, 25 Feb 2003 12:58:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PHjqA18339 for ietf-calendar-bks; Tue, 25 Feb 2003 09:45:52 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PHjjd18330 for ; Tue, 25 Feb 2003 09:45:46 -0800 (PST) Subject: Re: RFC: UTF-8 iCalendar bug solution To: ietf-calendar@imc.org Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Tue, 25 Feb 2003 12:45:46 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 02/25/2003 12:45:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, we can list the errata. I'd like a volunteer to help us keep it up to date. Also, there is an errata page on the IETF. Here's a couple of links showing ways other groups have handled this. If we are going to do an errata document - it actually needs to become an RFC/Draft - not just a page on the website. The official errata page is designed to hold mino typos. If a draft is wrong and it breaks interoperability, then it goes into a new draft. This is the url to the official RFC errata page: http://www.rfc-editor.org/errata.html. Here's the paragraph that leads off this page: " Published RFCs never change. Although every published RFC has been submitted to careful proof reading by the RFC Editor and the author(s), errors do sometimes go undetected. As a service to the readers of RFCs, this page contains a list of technical and editorial errors that have been reported to the RFC Editor and verified by the authors or the IESG. " Here's a link to a draft with errata and corrections. http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1-errata-01.txt ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Doug Royer To: "ietf-calendar@imc.org" Sent by: cc: owner-ietf-calendar@m Subject: Re: RFC: UTF-8 iCalendar bug solution ail.imc.org 02/24/03 06:40 PM Please respond to ietf-calendar When the WG feels that it is a bug or typo in an RFC and prior to issuing a new RFC - could we list them on calsch.org ? Perhaps an errata link for 244[567] + guide ? pregen@egenconsulting.com wrote: > > Hi Mark. Here's the process when there is an issue. ... > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Tue Feb 25 14:10:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11117 for ; Tue, 25 Feb 2003 14:10:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1PIuZX23868 for ietf-calendar-bks; Tue, 25 Feb 2003 10:56:35 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1PIuXd23863 for ; Tue, 25 Feb 2003 10:56:33 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1PIuVb2031160 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Feb 2003 10:56:34 -0800 Message-ID: <3E5BBC59.4080209@Royer.com> Date: Tue, 25 Feb 2003 11:56:25 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302250939.51012.mark@WebServiceSolutions.com> <3E5B9534.3000606@Royer.com> <200302251157.07339.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020003070900060909030001" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020003070900060909030001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On February 25, 2003 11:09 am, Doug Royer wrote: > >>As all iCalendar objects are MIME objects the charset is in the MIME >>header. So there is no need to fall back to anything. For CAP the >>charset/lang to use is determined by the commands, so nothing to >>fall back to. >> >>If you are using the X charset and get a character not in the X charset, >>someone sent you trash. > > > I think the big problem though is that many real-world applications (not SW) > are allowing a quickly growing userbase to create latin1 iCalendar objects. > > Perhaps if this trend continues for any length of time there will be too much > momentum and supporting latin1 fallback will be unavoidable? No. Instead you have some choices: Set the charset to iso-8859-1 (latin1) in the MIME header and send iCalendar objects using latin1 and not UTF-8. Take the UTF-8 object and charset convert it to iso-8859-1. (or the the other direction) At no point do you have to guess at the charset. If they send you latin1 and tag it as UTF-8, send them a bug. If they send you UTF-8 and tag it as latin1, send them a bug. The iCalendar default of UTF-8 is NOT mandatory for all objects. The only things that are mandatory about UTF-8 is that the spec says that all implementations MUST support UTF-8 and that you correctly tag the MIME header with the correct charset. The reason that UTF-8 was chosen as a must implement is so that there is common framework to interchange data. If you know that you are talking same vendor to same vendor, use any default charset you want. But do not expect everyone to have to guess at the charset you use. If you want to run your software in 8859-1 that's fine. But for interoperability you should send and expect UTF-8 MIME objects. CAP also allows for the charset and lang to be set at runtime. But it also mandates that all implementations be able to use UTF-8 and for the same reason. Interoperability requires that everyone must support at least one common charset. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020003070900060909030001 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjUxODU2MjZaMCMGCSqGSIb3DQEJBDEWBBQo zv+tADhwM8Ukl4THC1+c0PD8VzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAXCtUxlxaxmy6 avwfm+zPNHhegESn9mNHBfBfK9DWdpf9di9C8TfRRGwdXYq2ewMa3s7A/Cr7PRM2/Qg7HV0K VFaN9y6LE8ROEFDGEeAOiM+gAX4UmhjfFiSGFasxBxH4AsWVKyIDxVjZB0cYRegN2ZAazdAy Wl6TFL5/GF4lLXrBG90xKdprDrM7EhTyxrNzWv6ylK74WnwuUqfqsPfZ+Rtc5Ip7YbBrUgoh FkPuQBRmWNwQMzqob9Al2xpVUY3lwgXeMrxpZMPSuiLTAUf01+L1y18oNvWY5Fi9g6inaabM Iy+w4ia9xYEUJ2NqaeRDOmN/0lCN4zh3Kkz/CSSY8gAAAAAAAA== --------------ms020003070900060909030001-- From owner-ietf-calendar@mail.imc.org Tue Feb 25 23:06:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27494 for ; Tue, 25 Feb 2003 23:06:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1Q3xbr09959 for ietf-calendar-bks; Tue, 25 Feb 2003 19:59:37 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q3xad09955 for ; Tue, 25 Feb 2003 19:59:36 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 9382A4F2C for ; Tue, 25 Feb 2003 22:59:14 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Tue, 25 Feb 2003 22:59:09 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302251157.07339.mark@WebServiceSolutions.com> <3E5BBC59.4080209@Royer.com> In-Reply-To: <3E5BBC59.4080209@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302252259.09059.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for the response Doug. Comments inline... > > Set the charset to iso-8859-1 (latin1) in the MIME > header and send iCalendar objects using latin1 and > not UTF-8. > > Take the UTF-8 object and charset convert it to > iso-8859-1. (or the the other direction) > > At no point do you have to guess at the charset. If they send > you latin1 and tag it as UTF-8, send them a bug. If they send > you UTF-8 and tag it as latin1, send them a bug. I agree wrt the MIME transport. But what about the HTTP transport? I see popular iCalendar clients (with more in the pipeline) using a web server to serve/transport iCalendar data. The web server will not (and can not reliably) transmit the character set encoding. These web servers are currently serving up a combination of iCalendar documents encoded in both latin1 and UTF-8. Since the character encoding can not be accurately set in the HTTP response you will have to guess at the encoding when you come across illegal UTF-8. What I'm really hoping to accomplish here is to: 1. bring to light that certain vendors are allowing their growing customer base to create mixed UTF-8 and latin1 iCalendar data. 2. make a suggestion so we can all interoperate with the mixed character encodings until all vendors fix their software. It may be a good business model for Sun to force compliance, but I obviously have no choice but to handle all of the subtle breakage of the spec. > If you want to run your software in 8859-1 that's fine. But for > interoperability you should send and expect UTF-8 MIME objects. I'm sure you mean "If anyone wants to run their software in 8859-1", but I just to be clear that SW will not create 8859-1 encoded characters. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Tue Feb 25 23:19:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27650 for ; Tue, 25 Feb 2003 23:19:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1Q49Qt10306 for ietf-calendar-bks; Tue, 25 Feb 2003 20:09:26 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q49Od10302 for ; Tue, 25 Feb 2003 20:09:24 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 00A2D4F2C for ; Tue, 25 Feb 2003 23:09:02 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Tue, 25 Feb 2003 23:08:56 -0500 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302252308.56992.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 25, 2003 12:45 pm, pregen@egenconsulting.com wrote: > Yes, we can list the errata. I'd like a volunteer to help us keep it up to Great. > This is the url to the official RFC errata page: > http://www.rfc-editor.org/errata.html. Here's the paragraph that leads off > > Here's a link to a draft with errata and corrections. > http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1-errata-01.txt I notice that there is no errata for 244[5,6,7]. If you post the current errata I volunteer to read it and add to it all of the little nits I have saved. I would also like to stick it up on our public web server and update it with any errata other people send me. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Tue Feb 25 23:42:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28344 for ; Tue, 25 Feb 2003 23:42:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1Q4Rgc10898 for ietf-calendar-bks; Tue, 25 Feb 2003 20:27:42 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1Q4Rfd10894 for ; Tue, 25 Feb 2003 20:27:41 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1Q4Rfb2002743 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Feb 2003 20:27:44 -0800 Message-ID: <3E5C4237.103@Royer.com> Date: Tue, 25 Feb 2003 21:27:35 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302251157.07339.mark@WebServiceSolutions.com> <3E5BBC59.4080209@Royer.com> <200302252259.09059.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080300020400020000060608" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080300020400020000060608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > Thanks for the response Doug. Comments inline... > > >> Set the charset to iso-8859-1 (latin1) in the MIME >> header and send iCalendar objects using latin1 and >> not UTF-8. >> >> Take the UTF-8 object and charset convert it to >> iso-8859-1. (or the the other direction) >> >>At no point do you have to guess at the charset. If they send >>you latin1 and tag it as UTF-8, send them a bug. If they send >>you UTF-8 and tag it as latin1, send them a bug. > > > I agree wrt the MIME transport. > > But what about the HTTP transport? **ALL** iCalendar objects are MIME objects - they are NOT iCalendar objects if they do not contain the MIME headers. If you read the specs you will find that it states that the mime headers are omitted from the examples to save space and are are mandatory. > I see popular iCalendar clients (with more > in the pipeline) using a web server to serve/transport iCalendar data. The > web server will not (and can not reliably) transmit the character set > encoding. Absolutely not true - HTTP transports MIME data and it DOES include the MIME headers including charset. > These web servers are currently serving up a combination of > iCalendar documents encoded in both latin1 and UTF-8. Since the character > encoding can not be accurately set in the HTTP response you will have to > guess at the encoding when you come across illegal UTF-8. Look one layer lower in the wire protocol (snoop the line) and you will see that they do in fact send MIME header information. > What I'm really hoping to accomplish here is to: > > 1. bring to light that certain vendors are allowing their growing customer > base to create mixed UTF-8 and latin1 iCalendar data. Valid - as long as you include the mandatory MIME header. > 2. make a suggestion so we can all interoperate with the mixed character > encodings until all vendors fix their software. We did solve that problem :-) That is why we mandate that iCalendar objects are MIME objects. > It may be a good business model for Sun to force compliance, but I obviously > have no choice but to handle all of the subtle breakage of the spec. That part is true, however I do not know of any major vendor that is not transporting them as MIME objects. I have not looked at the apple implementation in detail yet. But if they are not using MIME headers - then they will have to fix that to be able to interoperate. > >>If you want to run your software in 8859-1 that's fine. But for >>interoperability you should send and expect UTF-8 MIME objects. > > > I'm sure you mean "If anyone wants to run their software in 8859-1", but I > just to be clear that SW will not create 8859-1 encoded characters. It can. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080300020400020000060608 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjYwNDI3MzVaMCMGCSqGSIb3DQEJBDEWBBSI tn8QAMZ6moWVnbzDHV8QqOdIADBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAFPIPXmokw+JK Tpxn9K1utH7XGyiqSVglYUf13nPQZTgsKtIwcUQKIaCPSmXi5ckHynxEo8UkmXnhv7Xenfgv HrPalIQUDEFjYDfbPsm77IMDZCTp7uy4IY1HGp/Iur2xBXDTGREYE0afbzOiqjItBjTAv4xw 0rS9PqmhhDgVCcSVwIjwRG1ndosFYICszrJC61GYRQkFnzOGNR+EbX0xAM4xD5JtFYi4E22f IWbvIONWooL306mpOProlpBqZI4joRON9c719cTLcZT2V83kI1TVuRxvJghACFWTRIXpyjBe e9C8dVuvR+qjQ9Y4MohrXNfmopbvo3iXPJmkWWQajwAAAAAAAA== --------------ms080300020400020000060608-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 09:22:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06477 for ; Wed, 26 Feb 2003 09:22:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QE4mt02870 for ietf-calendar-bks; Wed, 26 Feb 2003 06:04:48 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QE4kd02866 for ; Wed, 26 Feb 2003 06:04:46 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id CB99B4F2C for ; Wed, 26 Feb 2003 09:04:21 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Wed, 26 Feb 2003 09:04:31 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> In-Reply-To: <3E5C4237.103@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302260904.33122.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > But what about the HTTP transport? > > **ALL** iCalendar objects are MIME objects - they are NOT > iCalendar objects if they do not contain the MIME headers. > If you read the specs you will find that it states that the > mime headers are omitted from the examples to save space and > are are mandatory. Fascinating. I have never seen a single iCalendar object on the web that contained MIME headers. > > I see popular iCalendar clients (with more > > > > in the pipeline) using a web server to serve/transport iCalendar data. > > The web server will not (and can not reliably) transmit the character set > > encoding. > > Absolutely not true - HTTP transports MIME data and it DOES include the > MIME headers including charset. It absolutely is true. You misunderstood. I said "not reliably", I did not say they were not included. It can not reliably set the MIME headers because if the web server is serving two files: file1.ics and file2.ics it has no way of knowing file1.ics is UTF-8 and file2.ics is 8859-1. > > These web servers are currently serving up a combination of > > iCalendar documents encoded in both latin1 and UTF-8. Since the character > > encoding can not be accurately set in the HTTP response you will have to > > guess at the encoding when you come across illegal UTF-8. > > Look one layer lower in the wire protocol (snoop the line) and > you will see that they do in fact send MIME header information. I never said it wasn't there. Again, I said "accurately". > > What I'm really hoping to accomplish here is to: > > > > 1. bring to light that certain vendors are allowing their growing > > customer base to create mixed UTF-8 and latin1 iCalendar data. > > Valid - as long as you include the mandatory MIME header. > > > 2. make a suggestion so we can all interoperate with the mixed character > > encodings until all vendors fix their software. > > We did solve that problem :-) > That is why we mandate that iCalendar objects are MIME objects. I'm dumbfounded. :-) I'm going to think about this some more before I respond. > > It may be a good business model for Sun to force compliance, but I > > obviously have no choice but to handle all of the subtle breakage of the > > spec. > > That part is true, however I do not know of any major vendor > that is not transporting them as MIME objects. I have not looked > at the apple implementation in detail yet. But if they are not > using MIME headers - then they will have to fix that to be > able to interoperate. Perhaps now that I've mentioned the problem better wrt using a web server you would agree that fixing this would be difficult at best. (file1.ics, file2.ics in different encodings). > >>If you want to run your software in 8859-1 that's fine. But for > >>interoperability you should send and expect UTF-8 MIME objects. > > > > I'm sure you mean "If anyone wants to run their software in 8859-1", but > > I just to be clear that SW will not create 8859-1 encoded characters. > > It can. LOL. Hey, I wrote SW. If you have found a way to do this then it is a bug - and please email me how to reproduce it so I can fix it. Do realize that for a javax.swing.JTextField to create non UTF-8 Strings should not be possible without extending it... -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Feb 26 09:33:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07317 for ; Wed, 26 Feb 2003 09:33:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QEFfW03224 for ietf-calendar-bks; Wed, 26 Feb 2003 06:15:41 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1QEFdd03220 for ; Wed, 26 Feb 2003 06:15:40 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022609182902142 for ; Wed, 26 Feb 2003 09:18:29 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 09:13:28 -0500 Message-ID: <3E5CCB88.1010409@centive.com> Date: Wed, 26 Feb 2003 09:13:28 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302251157.07339.mark@WebServiceSolutions.com> <3E5BBC59.4080209@Royer.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 14:13:28.0856 (UTC) FILETIME=[3C289180:01C2DDA1] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > I see popular iCalendar clients (with more > >> in the pipeline) using a web server to serve/transport iCalendar >> data. The web server will not (and can not reliably) transmit the >> character set encoding. > > > Absolutely not true - HTTP transports MIME data and it DOES include > the MIME > headers including charset. The problem is that people expect to be able to take a text/calendar and save it to disk; when that happens, the MIME headers are lost, and they can't be reconstructed. There's no way to look at the text/calendar and know what character set it's in; if there were, we wouldn't need the character set in the MIME header. This is really a general MIME problem: MIME provides for transmitting metadata about objects, but that metadata tends to get lost once it leaves the MIME transport. The only solution is to define self-describing formats that don't need the MIME headers. I hate to say it, but this is something that an XML encoding would give us for free. >> 2. make a suggestion so we can all interoperate with the mixed >> character encodings until all vendors fix their software. > > We did solve that problem :-) > That is why we mandate that iCalendar objects are MIME objects. Mandating it doesn't make it happen, unfortunately. The only mandate that would work would be to declare that UTF-8 isn't the default; it's the only option. People would gripe about that (for Europe, UTF-8 costs more than Latin-1; for Asia, it costs more than UTF-16), but it'd be an easy requirement to understand and implement. -- /==========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |==========================================================| |A man's concepts should exceed his vocabulary, or what's a| |metaphor? | \==========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 26 09:54:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08577 for ; Wed, 26 Feb 2003 09:54:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QEgR405706 for ietf-calendar-bks; Wed, 26 Feb 2003 06:42:27 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1QEgQd05702 for ; Wed, 26 Feb 2003 06:42:26 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022609451629361 for ; Wed, 26 Feb 2003 09:45:16 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 09:40:16 -0500 Message-ID: <3E5CD1D0.2010301@centive.com> Date: Wed, 26 Feb 2003 09:40:16 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> <200302260904.33122.mark@WebServiceSolutions.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 14:40:16.0204 (UTC) FILETIME=[FA3668C0:01C2DDA4] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Swanson wrote: >LOL. Hey, I wrote SW. If you have found a way to do this then it is a bug - >and please email me how to reproduce it so I can fix it. Do realize that for >a javax.swing.JTextField to create non UTF-8 Strings should not be possible >without extending it... > Java is not the universe. Or do you mean "SW" to stand for something other than "software"? -- /==========================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |==========================================================| |A man's concepts should exceed his vocabulary, or what's a| |metaphor? | \==========================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 26 10:43:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12585 for ; Wed, 26 Feb 2003 10:43:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QFSLV07982 for ietf-calendar-bks; Wed, 26 Feb 2003 07:28:21 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QFSKd07975 for ; Wed, 26 Feb 2003 07:28:20 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id F1FDC4F2C for ; Wed, 26 Feb 2003 10:27:55 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Wed, 26 Feb 2003 10:28:00 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302260904.33122.mark@WebServiceSolutions.com> <3E5CD1D0.2010301@centive.com> In-Reply-To: <3E5CD1D0.2010301@centive.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302261028.00357.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 26, 2003 09:40 am, John Stracke wrote: > Mark Swanson wrote: > >LOL. Hey, I wrote SW. If you have found a way to do this then it is a bug > > - and please email me how to reproduce it so I can fix it. Do realize > > that for a javax.swing.JTextField to create non UTF-8 Strings should not > > be possible without extending it... > > Java is not the universe. ? LOL. > Or do you mean "SW" to stand for something other than "software"? LOL. I refer to ScheduleWorld as SW. I appologize for the confusion. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Feb 26 11:12:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14118 for ; Wed, 26 Feb 2003 11:12:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QG1A212049 for ietf-calendar-bks; Wed, 26 Feb 2003 08:01:10 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1QG19d12045 for ; Wed, 26 Feb 2003 08:01:09 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022611035923430 for ; Wed, 26 Feb 2003 11:03:59 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 10:58:58 -0500 Message-ID: <3E5CE442.1020400@centive.com> Date: Wed, 26 Feb 2003 10:58:58 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302260904.33122.mark@WebServiceSolutions.com> <3E5CD1D0.2010301@centive.com> <200302261028.00357.mark@WebServiceSolutions.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 15:58:58.0730 (UTC) FILETIME=[F90EB0A0:01C2DDAF] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Swanson wrote: >I refer to ScheduleWorld as SW. > There we are: "software" was already in context in your message, so that's what Doug and I dereferenced "SW" to. -- /=============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |=============================================================| |Rope is rope, and string is string, and never the twine shall| |meet. | \=============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 26 11:33:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14976 for ; Wed, 26 Feb 2003 11:33:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QGQSL12915 for ietf-calendar-bks; Wed, 26 Feb 2003 08:26:28 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QGQQd12910 for ; Wed, 26 Feb 2003 08:26:26 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1QGQOb2008196 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 26 Feb 2003 08:26:26 -0800 Message-ID: <3E5CEAAA.6000608@Royer.com> Date: Wed, 26 Feb 2003 09:26:18 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302251157.07339.mark@WebServiceSolutions.com> <3E5BBC59.4080209@Royer.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> <3E5CCB88.1010409@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070702060501090908050706" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070702060501090908050706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > > Doug Royer wrote: > >> > I see popular iCalendar clients (with more >> >>> in the pipeline) using a web server to serve/transport iCalendar >>> data. The web server will not (and can not reliably) transmit the >>> character set encoding. >> >> >> >> Absolutely not true - HTTP transports MIME data and it DOES include >> the MIME >> headers including charset. > > > The problem is that people expect to be able to take a text/calendar and > save it to disk; when that happens, the MIME headers are lost, and they > can't be reconstructed. There's no way to look at the text/calendar and > know what character set it's in; if there were, we wouldn't need the > character set in the MIME header. > > This is really a general MIME problem: MIME provides for transmitting > metadata about objects, but that metadata tends to get lost once it > leaves the MIME transport. The only solution is to define > self-describing formats that don't need the MIME headers. > > I hate to say it, but this is something that an XML encoding would give > us for free. No and for the same reason. If the XML file is in some uncommon charset then you can not read it to find the encoding value. >>> 2. make a suggestion so we can all interoperate with the mixed >>> character encodings until all vendors fix their software. >> >> >> We did solve that problem :-) >> That is why we mandate that iCalendar objects are MIME objects. > > > Mandating it doesn't make it happen, unfortunately. It does as far as the standard and interoperablility is concerned and that is what the WG is about. If a vendor wishes to save the data in the SHIFT_JISX0213 charset they can. However sending that raw file to most implementations will result in breakage. > The only mandate that would work would be to declare that UTF-8 isn't > the default; it's the only option. People would gripe about that (for > Europe, UTF-8 costs more than Latin-1; for Asia, it costs more than > UTF-16), but it'd be an easy requirement to understand and implement. And they did :-) That is why the MIME header is not optional. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070702060501090908050706 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjYxNjI2MThaMCMGCSqGSIb3DQEJBDEWBBTu 0e6mCDOkKcbW2uqePXU76zKw/TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAPmx2lEuhyTuj WozDZ04cpf+HdsKKnpDrthwWbmlpqbm0NB5lmwY0JXbIYvOjvMB4SYu55obXNW7qsS5Y30jg hHIS+xQDsjW9sObvQdPXfkGpsF4ce5CFKpTv+DK7IHX61N74s6mAWRbRgoXjaO7IHbNqsccb Aqi9XZb39LW4Ps0t82l74t9gYtUp2jpIBYxEfUjyH9or1KwjUgJI9qyVHmK1z3DeGCE2gY0B 7K0WzsCSVkaNzymcTsYNTsWi2AsjJ0QIPyw9SJnPSIRLbXYXPmPcxkpjpZCfAelPvGnVFzLs vRIa+FX7kv7zlhSt/UEBf2XwrGR04LO8t7Vrajc4awAAAAAAAA== --------------ms070702060501090908050706-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 11:36:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15055 for ; Wed, 26 Feb 2003 11:36:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QGJHs12658 for ietf-calendar-bks; Wed, 26 Feb 2003 08:19:17 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QGJGd12654 for ; Wed, 26 Feb 2003 08:19:16 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1QGJDb2008125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 26 Feb 2003 08:19:16 -0800 Message-ID: <3E5CE8FB.80408@Royer.com> Date: Wed, 26 Feb 2003 09:19:07 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> <200302260904.33122.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060303060207040907090508" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060303060207040907090508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > > It absolutely is true. You misunderstood. I said "not reliably", I did not say > they were not included. It can not reliably set the MIME headers because if > the web server is serving two files: file1.ics and file2.ics it has no way of > knowing file1.ics is UTF-8 and file2.ics is 8859-1. The ics files should have the MIME headers in them - else they are not iCalednar objects. If you or anyones elses application saves iCalendar objects without the MIME headers then they are not portable. I sent a test arround a year or so ago with over 200 charset conversion of the same iCalendar object. Each with a correct MIME header. There is no known way to figure out the charset of those 200 data files without the MIME headers. You can save them without the MIME headers. But that is not the interoperable standard way to do that. Which is what this WG is about. >>>>If you want to run your software in 8859-1 that's fine. But for >>>>interoperability you should send and expect UTF-8 MIME objects. >>> >>>I'm sure you mean "If anyone wants to run their software in 8859-1", but >>>I just to be clear that SW will not create 8859-1 encoded characters. >> >>It can. > > > LOL. Hey, I wrote SW. If you have found a way to do this then it is a bug - > and please email me how to reproduce it so I can fix it. Do realize that for > a javax.swing.JTextField to create non UTF-8 Strings should not be possible > without extending it... Viewing data and processing do not have to be in UTF-8. Even java can read UTF-8 and convert it to its native UTF-16. Java and any other language that I have seen on Unix and Windows can create 8859-1 encoded characters, which was the statement I was responting to. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060303060207040907090508 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjYxNjE5MDdaMCMGCSqGSIb3DQEJBDEWBBTl nsYphZeQkI03ZjglLygF4Pke8DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAhKtAyHkw8C/U snoMCZEwG9sLGvHa96ANa/Jf24Iy/JBwHQsrhvxflrsK+PZ5PZ/z4IhsXvEGAf0SuHRth/+J RApEKkTK2XENR+RI3DWNOrSyMbKGU8qO+bjpgXWJsoNiH27Si5lQOmOKHTBzWNU8INcEVYxO 8VAVo3dNvey76iRxWNDDz8CSfjNHu8v1gNECZP7XXRBVfBHfv+Cm/IYYlGoUeozChnAyX+VN d1weLoKtIrNj/0lm8eIGzBT1mjSPTUPbxrO/dgJAzarCtP0Xy6GbFif3WWOkd0I40p7EHByK QrY0qUi06Aa3jcduaHdt0aQtHK02iQ6y0+Xst7Uh3AAAAAAAAA== --------------ms060303060207040907090508-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 11:55:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15649 for ; Wed, 26 Feb 2003 11:55:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QGb4413169 for ietf-calendar-bks; Wed, 26 Feb 2003 08:37:04 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QGb2d13165 for ; Wed, 26 Feb 2003 08:37:02 -0800 (PST) In-Reply-To: <3E5CEAAA.6000608@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution MIME-Version: 1.0 X-Mailer: Lotus Notes Build V601_01232003 January 23, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Wed, 26 Feb 2003 11:36:59 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/26/2003 11:36:55 AM, Serialize complete at 02/26/2003 11:36:55 AM Content-Type: multipart/alternative; boundary="=_alternative 005B2AD685256CD9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B2AD685256CD9_= Content-Type: text/plain; charset="US-ASCII" The MIME header is the IMIP not the ICAL. If you save the mime stream it is not a .ics file; It is an .eml file. _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 02/26/2003 11:26 AM Please respond to "ietf-calendar@imc.org" To "ietf-calendar@imc.org" cc Subject Re: RFC: UTF-8 iCalendar bug solution John Stracke wrote: > > Doug Royer wrote: > >> > I see popular iCalendar clients (with more >> >>> in the pipeline) using a web server to serve/transport iCalendar >>> data. The web server will not (and can not reliably) transmit the >>> character set encoding. >> >> >> >> Absolutely not true - HTTP transports MIME data and it DOES include >> the MIME >> headers including charset. > > > The problem is that people expect to be able to take a text/calendar and > save it to disk; when that happens, the MIME headers are lost, and they > can't be reconstructed. There's no way to look at the text/calendar and > know what character set it's in; if there were, we wouldn't need the > character set in the MIME header. > > This is really a general MIME problem: MIME provides for transmitting > metadata about objects, but that metadata tends to get lost once it > leaves the MIME transport. The only solution is to define > self-describing formats that don't need the MIME headers. > > I hate to say it, but this is something that an XML encoding would give > us for free. No and for the same reason. If the XML file is in some uncommon charset then you can not read it to find the encoding value. >>> 2. make a suggestion so we can all interoperate with the mixed >>> character encodings until all vendors fix their software. >> >> >> We did solve that problem :-) >> That is why we mandate that iCalendar objects are MIME objects. > > > Mandating it doesn't make it happen, unfortunately. It does as far as the standard and interoperablility is concerned and that is what the WG is about. If a vendor wishes to save the data in the SHIFT_JISX0213 charset they can. However sending that raw file to most implementations will result in breakage. > The only mandate that would work would be to declare that UTF-8 isn't > the default; it's the only option. People would gripe about that (for > Europe, UTF-8 costs more than Latin-1; for Asia, it costs more than > UTF-16), but it'd be an easy requirement to understand and implement. And they did :-) That is why the MIME header is not optional. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --=_alternative 005B2AD685256CD9_= Content-Type: text/html; charset="US-ASCII"
The MIME header is the IMIP not the ICAL.  If you save the mime stream it is not a .ics file;  It is an .eml file.
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


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

02/26/2003 11:26 AM
Please respond to
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: RFC: UTF-8 iCalendar bug solution







John Stracke wrote:
>
> Doug Royer wrote:
>
>> >  I see popular iCalendar clients (with more
>>
>>> in the pipeline) using a web server to serve/transport iCalendar
>>> data. The web server will not (and can not reliably) transmit the
>>> character set encoding.
>>
>>
>>
>> Absolutely not true - HTTP transports MIME data and it DOES include
>> the MIME
>> headers including charset.
>
>
> The problem is that people expect to be able to take a text/calendar and
> save it to disk; when that happens, the MIME headers are lost, and they
> can't be reconstructed.  There's no way to look at the text/calendar and
> know what character set it's in; if there were, we wouldn't need the
> character set in the MIME header.
>
> This is really a general MIME problem: MIME provides for transmitting
> metadata about objects, but that metadata tends to get lost once it
> leaves the MIME transport.  The only solution is to define
> self-describing formats that don't need the MIME headers.
>
> I hate to say it, but this is something that an XML encoding would give
> us for free.

No and for the same reason. If the XML file is in some uncommon
charset then you can not read it to find the encoding value.

                <xml version="1.0" encoding="one-you-do-not-expect">

>>> 2. make a suggestion so we can all interoperate with the mixed
>>> character encodings until all vendors fix their software.
>>
>>
>> We did solve that problem :-)
>> That is why we mandate that iCalendar objects are MIME objects.
>
>
> Mandating it doesn't make it happen, unfortunately.

It does as far as the standard and interoperablility is concerned
and that is what the WG is about.

If a vendor wishes to save the data in the SHIFT_JISX0213 charset
they can. However sending that raw file to most implementations
will result in breakage.

> The only mandate that would work would be to declare that UTF-8 isn't
> the default; it's the only option.  People would gripe about that (for
> Europe, UTF-8 costs more than Latin-1; for Asia, it costs more than
> UTF-16), but it'd be an easy requirement to understand and implement.

And they did :-)
That is why the MIME header is not optional.



--

 Doug Royer                     |   http://INET-Consulting.com
 -------------------------------|-----------------------------
 Doug@Royer.com                 | Office: (208)612-INET
 http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

                We Do Standards - You Need Standards
--=_alternative 005B2AD685256CD9_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 12:14:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16505 for ; Wed, 26 Feb 2003 12:14:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QH5W514059 for ietf-calendar-bks; Wed, 26 Feb 2003 09:05:32 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1QH5Vd14055 for ; Wed, 26 Feb 2003 09:05:31 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022612082112609 for ; Wed, 26 Feb 2003 12:08:21 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 12:03:21 -0500 Message-ID: <3E5CF359.2060202@centive.com> Date: Wed, 26 Feb 2003 12:03:21 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302251157.07339.mark@WebServiceSolutions.com> <3E5BBC59.4080209@Royer.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> <3E5CCB88.1010409@centive.com> <3E5CEAAA.6000608@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 17:03:21.0479 (UTC) FILETIME=[F76F6970:01C2DDB8] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: >> This is really a general MIME problem: MIME provides for transmitting >> metadata about objects, but that metadata tends to get lost once it >> leaves the MIME transport. The only solution is to define >> self-describing formats that don't need the MIME headers. >> >> I hate to say it, but this is something that an XML encoding would >> give us for free. > > > No and for the same reason. If the XML file is in some uncommon > charset then you can not read it to find the encoding value. > > It works if the character set is an ASCII superset, though, as most are. Plus, that declaration is defined to be at the very start of the document; if one finds that it's not readable, one can give up right away. iCalendar doesn't even attempt to be self-describing this way. Furthermore, RFC-2445 asserts that iCalendar should be useful outside of MIME environments. From the abstract: This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. I am not aware of any filesystem or clipboard that attaches MIME headers to files. >>> That is why we mandate that iCalendar objects are MIME objects. >> >> >> Mandating it doesn't make it happen, unfortunately. > > > It does as far as the standard and interoperablility is concerned > and that is what the WG is about. The WG is about developing a standard that can feasibly be made to interoperate. Pretending that the entire world is MIME-capable doesn't do that. -- /============================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================| |Never do card tricks for your poker buddies.| \============================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 26 12:25:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16750 for ; Wed, 26 Feb 2003 12:25:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QHEUP14367 for ietf-calendar-bks; Wed, 26 Feb 2003 09:14:30 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1QHESd14363 for ; Wed, 26 Feb 2003 09:14:28 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022612171902998 for ; Wed, 26 Feb 2003 12:17:19 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 12:12:18 -0500 Message-ID: <3E5CF572.6040007@centive.com> Date: Wed, 26 Feb 2003 12:12:18 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> <200302260904.33122.mark@WebServiceSolutions.com> <3E5CE8FB.80408@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 17:12:18.0808 (UTC) FILETIME=[37B54F80:01C2DDBA] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Mark Swanson wrote: > >> It absolutely is true. You misunderstood. I said "not reliably", I >> did not say they were not included. It can not reliably set the MIME >> headers because if the web server is serving two files: file1.ics and >> file2.ics it has no way of knowing file1.ics is UTF-8 and file2.ics >> is 8859-1. > > The ics files should have the MIME headers in them - else they > are not iCalednar objects. Nonsense. The RFC does not say this at all. From 2445, 3.10: The file extension of "ics" is to be used to designate a file containing (an arbitrary set of) calendaring and scheduling information consistent with this MIME content type. It says *nothing* about including MIME headers. > You can save them without the MIME headers. But that is > not the interoperable standard way to do that. I have never, ever, seen any MIME implementation (MUA or HTTP client) that includes the MIME headers when it saves a MIME body-part. One of the goals specified in the calsch charter is "A standard content type for capturing calendar event and to-do information. The content type should be suitable as a MIME message entity that can be transferred over MIME based email systems or HTTP World Wide Web." Implicit in that requirement is that the format needs to be transferred from MUA to CUA without loss of information; given that MUAs do not preserve MIME headers when they save body-parts to disk, it follows that it is impossible for this format to rely on the MIME headers being present. -- /============================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |============================================| |Never do card tricks for your poker buddies.| \============================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 26 12:32:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17076 for ; Wed, 26 Feb 2003 12:32:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QHGpP14485 for ietf-calendar-bks; Wed, 26 Feb 2003 09:16:51 -0800 (PST) Received: from peabody.ximian.com (peabody.ximian.com [141.154.95.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHGnd14481 for ; Wed, 26 Feb 2003 09:16:49 -0800 (PST) Received: (qmail 31107 invoked from network); 26 Feb 2003 17:16:43 -0000 Received: from dmz.ximian.com (HELO 10-0-0-222.boston.ximian.com) (141.154.95.1) by peabody.ximian.com with SMTP; 26 Feb 2003 17:16:43 -0000 Subject: Re: RFC: UTF-8 iCalendar bug solution From: Dan Winship To: "ietf-calendar@imc.org" In-Reply-To: <3E5CE8FB.80408@Royer.com> References: <200302232018.26629.mark@WebServiceSolutions.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> <200302260904.33122.mark@WebServiceSolutions.com> <3E5CE8FB.80408@Royer.com> Content-Type: text/plain Message-Id: <1046280158.1942.8.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2.99 Date: 26 Feb 2003 12:22:38 -0500 Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The ics files should have the MIME headers in them - else they > are not iCalendar objects. That can't be right. If the MIME headers were part of the "text/icalendar" data type, then when you sent an iMIP message, you'd need to include two copies of the headers; one that was part of the email message, and one that was part of the iCalendar object. >From the abstract of RFC 2445: This memo is formatted as a registration for a MIME media type per [RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type. -- Dan From owner-ietf-calendar@mail.imc.org Wed Feb 26 12:39:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17439 for ; Wed, 26 Feb 2003 12:39:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QHS0H14922 for ietf-calendar-bks; Wed, 26 Feb 2003 09:28:00 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHRwd14918 for ; Wed, 26 Feb 2003 09:27:58 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 528364F2C for ; Wed, 26 Feb 2003 12:27:34 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Wed, 26 Feb 2003 12:27:33 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302260904.33122.mark@WebServiceSolutions.com> <3E5CE8FB.80408@Royer.com> In-Reply-To: <3E5CE8FB.80408@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302261227.33617.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The ics files should have the MIME headers in them - else they > are not iCalednar objects. If you or anyones elses application > saves iCalendar objects without the MIME headers then they > are not portable. > > I sent a test arround a year or so ago with over 200 charset > conversion of the same iCalendar object. Each with a correct > MIME header. There is no known way to figure out the charset > of those 200 data files without the MIME headers. > > You can save them without the MIME headers. But that is > not the interoperable standard way to do that. Which is > what this WG is about. Thanks for filling me in. Unfortunately my archives don't go back far enough. Would you be able post a link or send them to me? Thanks. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Feb 26 12:57:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18103 for ; Wed, 26 Feb 2003 12:57:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QHooc17316 for ietf-calendar-bks; Wed, 26 Feb 2003 09:50:50 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHond17312 for ; Wed, 26 Feb 2003 09:50:49 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 375378D7B9 for ; Wed, 26 Feb 2003 09:50:50 -0800 (PST) From: "Chris Olds" To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Wed, 26 Feb 2003 09:50:50 -0800 Message-Id: <20030226175050.M99637@asitturnsout.org> In-Reply-To: <3E5CEAAA.6000608@Royer.com> References: <200302232018.26629.mark@WebServiceSolutions.com> <200302251157.07339.mark@WebServiceSolutions.com> <3E5BBC59.4080209@Royer.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> <3E5CCB88.1010409@centive.com> <3E5CEAAA.6000608@Royer.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 26 Feb 2003 09:26:18 -0700, Doug Royer wrote > John Stracke wrote: > > > > Doug Royer wrote: > > > > I hate to say it, but this is something that an XML encoding would give > > us for free. > > No and for the same reason. If the XML file is in some uncommon > charset then you can not read it to find the encoding value. > > XML documents in character sets that cannot be easily detected (based on the assumption that the document is a legal XML document and the encoding declaration) are expected to be very rare. From the XML spec (Second edition[1], but I think the First edition text is identical): Because the contents of the encoding declaration are restricted to characters from the ASCII repertoire (however encoded), a processor can reliably read the entire encoding declaration as soon as it has detected which family of encodings is in use. Since in practice, all widely used character encodings fall into one of the categories above, the XML encoding declaration allows reasonably reliable in-band labeling of character encodings, even when external sources of information at the operating-system or transport-protocol level are unreliable. Character encodings such as UTF-7 that make overloaded usage of ASCII-valued bytes may fail to be reliably detected. Character sets that can be reliably detected by reading the encoding decaration include UTF-16 (BE and LE), EBCDIC, and "any other 7-bit, 8-bit, or mixed-width encoding which ensures that the characters of ASCII have their normal positions, width, and values", which includes BIG5, JIS, UTF-8 and 8859 character sets. /cco [1] http://www.w3.org/TR/REC-xml#sec-guessing -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Wed Feb 26 12:57:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18128 for ; Wed, 26 Feb 2003 12:57:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QHm1Q17150 for ietf-calendar-bks; Wed, 26 Feb 2003 09:48:01 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHm0d17143 for ; Wed, 26 Feb 2003 09:48:00 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1QHltb2008937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 26 Feb 2003 09:48:00 -0800 Message-ID: <3E5CFDC6.2050309@Royer.com> Date: Wed, 26 Feb 2003 10:47:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020202050304040104020706" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020202050304040104020706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert_Ransdell@notesdev.ibm.com wrote: > > The MIME header is the IMIP not the ICAL. If you save the mime stream > it is not a .ics file; It is an .eml file. 2445 is a registration of a MIME media type. And '.eml' is nowhere in 2445, 2446, or 2447 . Perhaps that is a Lotus/IBM thing. But it is not in iCalendar, iTIP, iMIP or CAP thing. However in 2445: 3.10 File Extensions The file extension of "ics" is to be used to designate a file containing (an arbitrary set of) calendaring and scheduling information consistent with this MIME content type. To transport it your going to need the charset defined (if not UTF-8) agreed between the endpoints in advance of transfer. Not because it is a mandate, but because it is a fact necessitated by the other fact that the world does not use just one charset. You can limit your sales (not that you are - but just a point) and interoperability to latin-1 (or whatever) however this WG is concerned about interoperability across vendors and across the internet (world). So I am *not* saying some do not do it that way. I am *not* saying you can not do it that way. I am saying this WG is about interoperability and for that you are going to have to transport MIME objects. Someone talked about loading up .ics files directly into the web tool. And that will work until the .ics file is not UTF-8 or whatever charset they can parse. However that work is not within the scope of this WG. That's one reason CAP exists - to solve these problems. Ignoring the issue will only limit your sales and increase you bug count over time as other charsets are sent in valid format to you customers. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020202050304040104020706 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjYxNzQ3NTBaMCMGCSqGSIb3DQEJBDEWBBQc Iq7Ug4FtOKpjc7x4bMWUljMnPDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAbtmyrIZPf9k0 oROW8BVX3+Ufw3I0Fq31fxsU6Cec6dMZaz7h80KfAsWZppKnkBQJC3jXy5eFlrE2eVqxKjZ5 HRbFq/l8Yq7y0sUiWBQRiKKUGxGjFypc7htWHwNaJxsCcZFY1IKEmtSJXpR6lSQ/j84tLS7W CPEGQnOwwqKr0ya1KOwdo2XPjEUL77+XzLqa++TWBZC8xlBytYScNIPSda/Q2seqdQtAPn0h B/6iVcoXp7n54J28lAvOuw9paqNOLzBMk4bjwdaBDNpKGYKDt0KsN3Y+K2NkWRuecmiKnVOT bE42rplVsAHyrw0gBdEeIQSOiZpoqnDSiMHNvCdNuwAAAAAAAA== --------------ms020202050304040104020706-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 13:08:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18495 for ; Wed, 26 Feb 2003 13:08:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QI06k17754 for ietf-calendar-bks; Wed, 26 Feb 2003 10:00:06 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QI05d17750 for ; Wed, 26 Feb 2003 10:00:05 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1QI01b2009030 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 26 Feb 2003 10:00:05 -0800 Message-ID: <3E5D009C.7030204@Royer.com> Date: Wed, 26 Feb 2003 10:59:56 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302251157.07339.mark@WebServiceSolutions.com> <3E5BBC59.4080209@Royer.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> <3E5CCB88.1010409@centive.com> <3E5CEAAA.6000608@Royer.com> <3E5CF359.2060202@centive.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050101060900060508050709" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050101060900060508050709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: >> It does as far as the standard and interoperablility is concerned >> and that is what the WG is about. > > > The WG is about developing a standard that can feasibly be made to > interoperate. Pretending that the entire world is MIME-capable doesn't > do that. True. But the topic is using the files and data transported from one source to another by some means. So you can transport iCalendar objects any way you want. But this WG is and has proposed iMIP and CAP. If somone has a proposal to tranport iCalendar objects other than iMIP (MIME) or CAP (which defines the charst and language), then we can discuss that. However we (WG) can not declare that non-somehow-tagged files will work across vendors - because they might not. I am just trying to eliminate any belief that just because you have access to a file that the human knows contains iCalendar data, does not mean that a program can always parse it by guessing at the charset. And I also want to (and I think we want to) discourage people from thinking that ftp-ing (or whatever) .ics files will always work - because it migh not and it does not mean that 2445/2446 are busted. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050101060900060508050709 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjYxNzU5NTZaMCMGCSqGSIb3DQEJBDEWBBR4 G0nBD3rc0rpj4O5qmHUmQSDxNDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEABtNAA0VYePZf v/2LaNPQ++tW0oVhZpSJO4NdKH3DSKJTUvecZkQmRQ8njrUyAJIHPgjvXUKOj0Y7UROh5e6U rH9X1bAZ7MDB45lICuP4BuD0wUMELW9BHHMv2t1YTyYR62bzTz5r0+XDOIIj8m8NwGTNSL2m eLUbvIXdfen/WBI4TwPGryflU+VYOaanNpZbH5Q6S1Y+Q6yG1dV/jH4Q+8Jj0/FHdgckyXWJ sIjEPo3lBjUH5nnT7GJMPF4Y1VADaXMV2AGAruHv0uWySUKxXcCCnF44pXm2LqKsrhi4oi4p oRJfSrSdOD6tvcrpDgLCsVNJJHcvlpYPrtNyCi7nEgAAAAAAAA== --------------ms050101060900060508050709-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 13:13:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18610 for ; Wed, 26 Feb 2003 13:13:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QI2ea18092 for ietf-calendar-bks; Wed, 26 Feb 2003 10:02:40 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QI2dd18086 for ; Wed, 26 Feb 2003 10:02:39 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1QI2ab2009074 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 26 Feb 2003 10:02:39 -0800 Message-ID: <3E5D0137.3010408@Royer.com> Date: Wed, 26 Feb 2003 11:02:31 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302252259.09059.mark@WebServiceSolutions.com> <3E5C4237.103@Royer.com> <200302260904.33122.mark@WebServiceSolutions.com> <3E5CE8FB.80408@Royer.com> <1046280158.1942.8.camel@twelve-monkeys.boston.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070500000905030509010105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070500000905030509010105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Stracke wrote: > Nonsense. The RFC does not say this at all. From 2445, 3.10: > ... and Dan Winship wrote: >>The ics files should have the MIME headers in them - else they >>are not iCalendar objects. > > > That can't be right. Your both correct - I was wrong - about .ics files. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070500000905030509010105 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjYxODAyMzFaMCMGCSqGSIb3DQEJBDEWBBQj RBjUgbR5lIZwLLif0m6BBr4+ATBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAYUBdv80sZF38 Aoj03077uowAL955M+f8wo6mEJp8xzUA+zi94TKM1VQnZ8YofXvVHU/QnqyQ175Wmb+QKnQL FbaWtDIfFhxKNv9h5kMiyZ2OXHNwAf+/me1LTQf04hZO8Fscka9pZ4bPVwUA2rQOBRMVgYaY AmeDrTtXjCKd5gF59B0MpmAq6nKV8w/NSgk3Ss/dGjZX7p3xC5bns884MTDUNl7agytTE+kv Q0oUg67av7KaJNLQwTakc+LEvL+kMBVgWf7su+hcvkJpNWsukku5T7MHWCMDNnb85J4gHtSi JNsXieBbwIRuAVo6T/pS/TBFpawQhAu8AW4aH7eEggAAAAAAAA== --------------ms070500000905030509010105-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 13:54:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19680 for ; Wed, 26 Feb 2003 13:54:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QIjKr20468 for ietf-calendar-bks; Wed, 26 Feb 2003 10:45:20 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1QIjId20454 for ; Wed, 26 Feb 2003 10:45:19 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022613480913433 for ; Wed, 26 Feb 2003 13:48:09 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 13:43:09 -0500 Message-ID: <3E5D0ABD.9050508@centive.com> Date: Wed, 26 Feb 2003 13:43:09 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <3E5CFDC6.2050309@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 18:43:09.0327 (UTC) FILETIME=[E87881F0:01C2DDC6] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > Someone talked about loading up .ics files directly into the web tool. > And that will work until the .ics file is not UTF-8 or whatever charset > they can parse. However that work is not within the scope of this WG. Not so. As I quoted from the charter, there is at least one channel (MUA-to-CUA) explicitly in our scope that does not include MIME headers. -- /===============================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===============================================================| |"I use emacs, which might be thought of as a thermonuclear word| |processor." -- Neal Stephenson | \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 26 14:09:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20188 for ; Wed, 26 Feb 2003 14:09:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QJ3ks23200 for ietf-calendar-bks; Wed, 26 Feb 2003 11:03:46 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QJ3id23192 for ; Wed, 26 Feb 2003 11:03:45 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 6B12F4F2C for ; Wed, 26 Feb 2003 14:03:21 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Wed, 26 Feb 2003 14:03:05 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <3E5CF359.2060202@centive.com> <3E5D009C.7030204@Royer.com> In-Reply-To: <3E5D009C.7030204@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302261403.05507.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > True. But the topic is using the files and data transported from > one source to another by some means. So you can transport iCalendar > objects any way you want. But this WG is and has proposed iMIP > and CAP. To requote from Dan's email (quoted from 2445): " the format in this memo is equally applicable for use outside of a MIME message content type." Therefore it should be legal to state that any transport is equally applicable to iMIP and CAP; this includes ftp and http. > charset. And I also want to (and I think we want to) discourage people > from thinking that ftp-ing (or whatever) .ics files will always > work - because it migh not and it does not mean that 2445/2446 > are busted. But the reason it can not work 100% of the time is exactly because 2445 does not specify a mandatory property type for the character set. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Feb 26 14:36:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21128 for ; Wed, 26 Feb 2003 14:36:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QJREW24526 for ietf-calendar-bks; Wed, 26 Feb 2003 11:27:14 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QJRDd24522 for ; Wed, 26 Feb 2003 11:27:13 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1QJR9b2009831 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 26 Feb 2003 11:27:13 -0800 Message-ID: <3E5D1508.3040505@Royer.com> Date: Wed, 26 Feb 2003 12:27:04 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <3E5CF359.2060202@centive.com> <3E5D009C.7030204@Royer.com> <200302261403.05507.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010902030101040103020602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010902030101040103020602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: >>True. But the topic is using the files and data transported from >>one source to another by some means. So you can transport iCalendar >>objects any way you want. But this WG is and has proposed iMIP >>and CAP. > > > To requote from Dan's email (quoted from 2445): > " the format in this memo is equally applicable > for use outside of a MIME message content type." > > Therefore it should be legal to state that any transport is equally applicable > to iMIP and CAP; this includes ftp and http. Yes. Again it can be done. However you will not have a clue about the charset. > >>charset. And I also want to (and I think we want to) discourage people >>from thinking that ftp-ing (or whatever) .ics files will always >>work - because it migh not and it does not mean that 2445/2446 >>are busted. > > > But the reason it can not work 100% of the time is exactly because 2445 does > not specify a mandatory property type for the character set. For the same reason I was wrong about the .ics file, you could not read the charset property without first knowing the charset of the data itself. It MUST BE external to the iCalendar BEGIN/END tags. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010902030101040103020602 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjYxOTI3MDRaMCMGCSqGSIb3DQEJBDEWBBQq EXt3hF1GreEBMGHnUxy2KHzA5DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAvfqJSRv9MMOi 4y2yYdmpA578hwsZxde98AmhBnqVogx20wfwS5PVzaohTIJ4ZAGK7byA3xVC+EQ6JpWBn4Mg ZGe3LuhRRCx8oxwarsbE18d9pTz821zMFZx5FpWCMlzHRut2KbxoKebTUI6+AD8o9WuCJL/O g840PXFj/H0ZWIyApcO7UP7ku/TVVxegI0QFOAtbR21u5hWERcNifM3JL/FfZDgMGtefG0WV uyKv5Ac98d+L8fw7rKbva6TVEINkML36LLGm6/zVcWQwScC706ekZ0vNV9/Sv7ufH2OPhC/Q poVI/1WWHLwdMBVbUI+I5rbZiE8QhU/mS1RQBHckZgAAAAAAAA== --------------ms010902030101040103020602-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 15:03:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22090 for ; Wed, 26 Feb 2003 15:03:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QJrWH25503 for ietf-calendar-bks; Wed, 26 Feb 2003 11:53:32 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QJrVd25499 for ; Wed, 26 Feb 2003 11:53:31 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 5991F8D7B9; Wed, 26 Feb 2003 11:53:32 -0800 (PST) From: "Chris Olds" To: Mark Swanson , "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug Date: Wed, 26 Feb 2003 11:53:32 -0800 Message-Id: <20030226195332.M55471@asitturnsout.org> In-Reply-To: <200302261403.05507.mark@WebServiceSolutions.com> References: <200302232018.26629.mark@WebServiceSolutions.com> <3E5CF359.2060202@centive.com> <3E5D009C.7030204@Royer.com> <200302261403.05507.mark@WebServiceSolutions.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 26 Feb 2003 14:03:05 -0500, Mark Swanson wrote > > But the reason it can not work 100% of the time is exactly because > 2445 does not specify a mandatory property type for the character set. I'm (mostly) still in standard-quoting mode, but I should add that I agree that 2445's punting of the character set question to MIME does cause problems with stored objects. /cco From RFC2445, p45: 4.3.11 Text Value Name: TEXT Purpose This value type is used to identify values that contain human readable text. Formal Definition: The character sets supported by this revision of iCalendar are UTF-8 and US ASCII thereof. The applicability to other character sets is for future work. The value type is defined by the following notation. -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Wed Feb 26 15:11:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22424 for ; Wed, 26 Feb 2003 15:11:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QK6sq25879 for ietf-calendar-bks; Wed, 26 Feb 2003 12:06:54 -0800 (PST) Received: from carwash.centivinc.com (carwash.centive.com [65.220.90.249]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1QK6rd25875 for ; Wed, 26 Feb 2003 12:06:53 -0800 (PST) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by carwash.centivinc.com (NAVGW 2.5.2.11) with SMTP id M2003022615094403245 for ; Wed, 26 Feb 2003 15:09:44 -0500 Received: from centive.com ([10.10.51.177]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 Feb 2003 15:04:44 -0500 Message-ID: <3E5D1DDC.5090007@centive.com> Date: Wed, 26 Feb 2003 15:04:44 -0500 From: John Stracke Organization: Centive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <3E5CF359.2060202@centive.com> <3E5D009C.7030204@Royer.com> <200302261403.05507.mark@WebServiceSolutions.com> <3E5D1508.3040505@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2003 20:04:44.0233 (UTC) FILETIME=[4E0FE390:01C2DDD2] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > For the same reason I was wrong about the .ics file, you could > not read the charset property without first knowing the charset > of the data itself. In general, this is true; however, in practice, taking an approach like XML's directive will work in the majority of cases. iCalendar's current approach will fail in the majority of cases; the only plausible scenarios where it would work would be (a) an integrated CUA/MUA, where the CUA has privileged access to the MIME headers, (b) an integrated CS/MTA, where the MTA gives the CS access to the incoming iMIP (perhaps via IMAP?), and then the CUA accesses the CS via CAP. (It's also theoretically possible that incoming iTIP might be coming in via CAP, but I don't consider that plausible--users don't want to have to keep track of CAP addresses in addition to email addresses, and admins don't want to open up another communications channel into the enterprise.) -- /================================================================\ |John Stracke |jstracke@centive.com | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |================================================================| |"The struggle is always worthwhile, if the end be worthwhile and| |the means honorable; foreknowledge of defeat is not sufficient | |reason to withdraw from the contest." -- Adron e'Kieron, by | |Steven Brust | \================================================================/ From owner-ietf-calendar@mail.imc.org Wed Feb 26 15:27:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23049 for ; Wed, 26 Feb 2003 15:27:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QKICB26399 for ietf-calendar-bks; Wed, 26 Feb 2003 12:18:12 -0800 (PST) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QKIAd26389 for ; Wed, 26 Feb 2003 12:18:10 -0800 (PST) Subject: Re: RFC: UTF-8 iCalendar bug solution To: Mark Swanson Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: pregen@egenconsulting.com Date: Wed, 26 Feb 2003 15:18:09 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 02/26/2003 03:18:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A volunteer!! Thanks. I'll see what I can put together with all the errata and get that to you. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Mark Swanson cc: Sent by: Subject: Re: RFC: UTF-8 iCalendar bug solution owner-ietf-calendar@m ail.imc.org 02/25/03 11:08 PM On February 25, 2003 12:45 pm, pregen@egenconsulting.com wrote: > Yes, we can list the errata. I'd like a volunteer to help us keep it up to Great. > This is the url to the official RFC errata page: > http://www.rfc-editor.org/errata.html. Here's the paragraph that leads off > > Here's a link to a draft with errata and corrections. > http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1-errata-01.txt I notice that there is no errata for 244[5,6,7]. If you post the current errata I volunteer to read it and add to it all of the little nits I have saved. I would also like to stick it up on our public web server and update it with any errata other people send me. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Feb 26 15:30:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23525 for ; Wed, 26 Feb 2003 15:30:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QKDOZ26259 for ietf-calendar-bks; Wed, 26 Feb 2003 12:13:24 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QKDMd26255 for ; Wed, 26 Feb 2003 12:13:23 -0800 (PST) Received: from sflaptop.sfcommerce.com (unknown [66.48.2.195]) by ns1.webservicesolutions.com (Postfix) with ESMTP id A33A44F2C for ; Wed, 26 Feb 2003 15:12:59 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Wed, 26 Feb 2003 15:12:50 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302261403.05507.mark@WebServiceSolutions.com> <3E5D1508.3040505@Royer.com> In-Reply-To: <3E5D1508.3040505@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302261512.50969.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 26, 2003 02:27 pm, Doug Royer wrote: > > But the reason it can not work 100% of the time is exactly because 2445 > > does not specify a mandatory property type for the character set. > > For the same reason I was wrong about the .ics file, you could > not read the charset property without first knowing the charset > of the data itself. It MUST BE external to the iCalendar > BEGIN/END tags. I read the spec differently: I take the formal definition of: BEGIN:VCALENDAR to be ASCII only. A CHARSET property would be ASCII encoded and the value would be from the IANA Charset Registry (which forces ASCII only) http://www.iana.org/assignments/character-sets -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Wed Feb 26 15:36:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24216 for ; Wed, 26 Feb 2003 15:36:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QKUFU26758 for ietf-calendar-bks; Wed, 26 Feb 2003 12:30:15 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QKUCd26746 for ; Wed, 26 Feb 2003 12:30:12 -0800 (PST) In-Reply-To: <200302261512.50969.mark@WebServiceSolutions.com> To: mark@WebServiceSolutions.com Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: RFC: UTF-8 iCalendar bug solution MIME-Version: 1.0 X-Mailer: Lotus Notes Build V601_01232003 January 23, 2003 Message-ID: From: Robert_Ransdell@notesdev.ibm.com Date: Wed, 26 Feb 2003 15:31:21 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/26/2003 03:30:13 PM, Serialize complete at 02/26/2003 03:30:13 PM Content-Type: multipart/alternative; boundary="=_alternative 0070839E85256CD9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0070839E85256CD9_= Content-Type: text/plain; charset="US-ASCII" Notes sets line after BEGIN: VCALENDAR with non-standard Lotus property that contains IANA Charset _____________________ Note: new email address tom_ransdell@notesdev.ibm.com Mark Swanson Sent by: owner-ietf-calendar@mail.imc.org 02/26/2003 03:12 PM To "ietf-calendar@imc.org" cc Subject Re: RFC: UTF-8 iCalendar bug solution On February 26, 2003 02:27 pm, Doug Royer wrote: > > But the reason it can not work 100% of the time is exactly because 2445 > > does not specify a mandatory property type for the character set. > > For the same reason I was wrong about the .ics file, you could > not read the charset property without first knowing the charset > of the data itself. It MUST BE external to the iCalendar > BEGIN/END tags. I read the spec differently: I take the formal definition of: BEGIN:VCALENDAR to be ASCII only. A CHARSET property would be ASCII encoded and the value would be from the IANA Charset Registry (which forces ASCII only) http://www.iana.org/assignments/character-sets -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp --=_alternative 0070839E85256CD9_= Content-Type: text/html; charset="US-ASCII"
Notes sets line after BEGIN: VCALENDAR with non-standard Lotus property that contains IANA Charset
_____________________
Note: new email address

tom_ransdell@notesdev.ibm.com


Mark Swanson <mark@WebServiceSolutions.com>
Sent by: owner-ietf-calendar@mail.imc.org

02/26/2003 03:12 PM

To
"ietf-calendar@imc.org" <ietf-calendar@imc.org>
cc
Subject
Re: RFC: UTF-8 iCalendar bug solution






On February 26, 2003 02:27 pm, Doug Royer wrote:
> > But the reason it can not work 100% of the time is exactly because 2445
> > does not specify a mandatory property type for the character set.
>
> For the same reason I was wrong about the .ics file, you could
> not read the charset property without first knowing the charset
> of the data itself. It MUST BE external to the iCalendar
> BEGIN/END tags.

I read the spec differently: I take the formal definition of:
BEGIN:VCALENDAR
to be ASCII only.

A CHARSET property would be ASCII encoded and the value would be from the IANA
Charset Registry (which forces ASCII only)

http://www.iana.org/assignments/character-sets

--
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
Java Web Start:
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp
--=_alternative 0070839E85256CD9_=-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 16:00:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25177 for ; Wed, 26 Feb 2003 16:00:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QKraF27600 for ietf-calendar-bks; Wed, 26 Feb 2003 12:53:36 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QKrZd27596 for ; Wed, 26 Feb 2003 12:53:35 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1QKrXb2010467 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 26 Feb 2003 12:53:36 -0800 Message-ID: <3E5D2948.8010909@Royer.com> Date: Wed, 26 Feb 2003 13:53:28 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution References: <200302232018.26629.mark@WebServiceSolutions.com> <200302261403.05507.mark@WebServiceSolutions.com> <3E5D1508.3040505@Royer.com> <200302261512.50969.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030502050506000105040802" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030502050506000105040802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > On February 26, 2003 02:27 pm, Doug Royer wrote: > >>>But the reason it can not work 100% of the time is exactly because 2445 >>>does not specify a mandatory property type for the character set. >> >>For the same reason I was wrong about the .ics file, you could >>not read the charset property without first knowing the charset >>of the data itself. It MUST BE external to the iCalendar >>BEGIN/END tags. > > > I read the spec differently: I take the formal definition of: > BEGIN:VCALENDAR > to be ASCII only. No: 2.3 International Considerations In the rest of this document, descriptions of characters are of the form "character name (codepoint)", where "codepoint" is from the US- ASCII character set. The "character name" is the authoritative description; (codepoint) is a reference to that character in US-ASCII or US-ASCII compatible sets (for example the ISO-8859-x family, UTF- 8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set is used, appropriate code-point from that character set MUST be chosen instead. Use of non-US-ASCII-compatible character sets is NOT recommended. So if you don't use a ASCII ~compatable~ character set -> convert. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030502050506000105040802 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjYyMDUzMjhaMCMGCSqGSIb3DQEJBDEWBBTf v4YWc5CW+++3X+sgMpxkbBCyYTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEADC1zdw5Z5Q6I RfiRvoN/rSbCwPUOFOkled+KzVkDrVci85ZKxHfglXJSk4zd3+dWvym/oud8I0t9JZ0xtIu1 1jOsg5tRZrjvjBVTPoN9VjIbUhyTy2J6ffiupU9fStzRdQPGuKUMqe06io53o11Qp0NGOxyG NNf0UyH6gX5kaQh6QpGOOJneM26ozDtYEth3OgOyV40w3ZZ90pkfCd24afb/0Fdn/tS0ocHV EZZ+UszmAy7P/3C8M5WOaHPc6o7MekiXORJazUsPaAPY/F3lsabSjI5F7a3aZKIaYq1WgYVZ Eg7QVQLUObvsRVQnk9PF8snj8+sC/4onfHUZC/DSSAAAAAAAAA== --------------ms030502050506000105040802-- From owner-ietf-calendar@mail.imc.org Wed Feb 26 22:37:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07154 for ; Wed, 26 Feb 2003 22:37:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1R3UHs13530 for ietf-calendar-bks; Wed, 26 Feb 2003 19:30:17 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1R3UEY13526 for ; Wed, 26 Feb 2003 19:30:16 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id BED664F2E for ; Wed, 26 Feb 2003 22:29:51 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Wed, 26 Feb 2003 22:29:45 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302261512.50969.mark@WebServiceSolutions.com> <3E5D2948.8010909@Royer.com> In-Reply-To: <3E5D2948.8010909@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302262229.45914.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 26, 2003 03:53 pm, Doug Royer wrote: > Mark Swanson wrote: > > On February 26, 2003 02:27 pm, Doug Royer wrote: > >>>But the reason it can not work 100% of the time is exactly because 2445 > >>>does not specify a mandatory property type for the character set. > >> > >>For the same reason I was wrong about the .ics file, you could > >>not read the charset property without first knowing the charset > >>of the data itself. It MUST BE external to the iCalendar > >>BEGIN/END tags. No. Too many valid reasons have been posted why this should not be so. How about this: 1. The charset property name is "CHARSET" 2. We may specify the value as "MUST be a (ASCII) value from the IANA Charset Registry (http://www.iana.org/assignments/character-sets). examples of mandating a value type are already in 2445: Section 4.3.3 (Calendar User Address). IANA registered URI ... IANA registered Charset. This way I can save the iCalendar object to disk, serve it up with a web server, have my MUA persist it to disk, and more. > > I read the spec differently: I take the formal definition of: > > BEGIN:VCALENDAR > > to be ASCII only. > > No: > > 2.3 International Considerations > > In the rest of this document, descriptions of characters are of the > form "character name (codepoint)", where "codepoint" is from the US- > ASCII character set. The "character name" is the authoritative > description; (codepoint) is a reference to that character in US-ASCII > or US-ASCII compatible sets (for example the ISO-8859-x family, UTF- > 8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set > is used, appropriate code-point from that character set MUST be > chosen instead. Use of non-US-ASCII-compatible character sets is NOT > recommended. > > So if you don't use a ASCII ~compatable~ character set -> convert. What I meant was that the text: BEGIN:VCALENDAR can only be ASCII. I wasn't talking in the general sense where any property value may be in any character set. I mentioned it as proof that you can read the CHARSET property because you always know the charset of ASCII. Please help me understand paragraph 2.3: A codepoint is US-ASCII. A codepoint is US-ASCII or US-ASCII compatible. A codepoint is an appropriate codepoint from a NON-US-ASCII character set. The last one completely befuddles me! -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Thu Feb 27 00:39:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08902 for ; Thu, 27 Feb 2003 00:39:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1R5UYY16682 for ietf-calendar-bks; Wed, 26 Feb 2003 21:30:34 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1R5UXY16677 for ; Wed, 26 Feb 2003 21:30:33 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 847368D7B9; Wed, 26 Feb 2003 21:30:36 -0800 (PST) From: "Chris Olds" To: Mark Swanson , "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Wed, 26 Feb 2003 21:30:36 -0800 Message-Id: <20030227053036.M42151@asitturnsout.org> In-Reply-To: <200302262229.45914.mark@WebServiceSolutions.com> References: <200302232018.26629.mark@WebServiceSolutions.com> <200302261512.50969.mark@WebServiceSolutions.com> <3E5D2948.8010909@Royer.com> <200302262229.45914.mark@WebServiceSolutions.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.50 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 26 Feb 2003 22:29:45 -0500, Mark Swanson wrote > > What I meant was that the text: > BEGIN:VCALENDAR can only be ASCII. I wasn't talking in the general > sense where any property value may be in any character set. I > mentioned it as proof that you can read the CHARSET property because > you always know the charset of ASCII. > > Please help me understand paragraph 2.3: > > A codepoint is US-ASCII. > A codepoint is US-ASCII or US-ASCII compatible. > A codepoint is an appropriate codepoint from a NON-US-ASCII > character set. > > The last one completely befuddles me! While paragraph 2.3 suggests rather strongly that UTF-8 or ASCII be used, 2445 doesn't mandate any particular character set; as a result, in theory, you could conform to 2445 with EBCDIC (where the ordinal value of the letters and essential punctuation are different from ASCII), or UTF-16 data (16-bit codes, so the ASCII values alternate with NUL bytes). If you were to do such a foolhardy thing, you should use the codepoint that corresponds to the canonical ASCII value in your non-US-ASCII-compatible character set (e.g. an EBCDIC code page). Absent MIME headers, using anything other than UTF-8 for 2445 data objects seems risky; unfortunately, it sounds like people are doing this already. A CHARSET property for VCALENDAR objects seems useful, as does a CHARSET parameter for properties with text values; neither will be of any use if they're not present, so it doesn't fix anything, just suggests how to make things better going forward. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Thu Feb 27 08:00:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29237 for ; Thu, 27 Feb 2003 08:00:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RCoNB04109 for ietf-calendar-bks; Thu, 27 Feb 2003 04:50:23 -0800 (PST) Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RCoLY04104 for ; Thu, 27 Feb 2003 04:50:21 -0800 (PST) Received: from fuzzbox (81-86-188-66.dsl.pipex.com [81.86.188.66]) by colossus.systems.pipex.net (Postfix) with ESMTP id 5D50116000BEE for ; Thu, 27 Feb 2003 12:50:14 +0000 (GMT) Received: from 127.0.0.1 by fuzzbox ([127.0.0.1] running VPOP3) with SMTP for ; Thu, 27 Feb 2003 12:50:12 -0000 Message-ID: <003701c2de5e$c278bd60$0100a8c0@fuzzbox> From: "Mike Higginbottom" To: "Ietf-Calendar@Imc.Org" References: <200302232018.26629.mark@WebServiceSolutions.com> Subject: Re: UTF-8 iCalendar bug solution Date: Thu, 27 Feb 2003 12:50:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Server: VPOP3 Enterprise V1.5.0 - Registered Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, This may be a dumb-ass question but here goes: Assuming I want to support some charset which does not have any representation of US-ASCII characters at all. I want a CUA to be able to send me text using this charset in a property value. Since the only source of info for the charset I'm dealing with is the MIME headers, then this charset is presumably also to be used to interpret the other property values as well. How do I parse BEGIN:VCALENDAR for instance in the context of this charset which has no representation of those characters? The thinking behind this is that in 2445 we have: 4.1.4 Character Set There is not a property parameter to declare the character set used in a property value. The default character set for an iCalendar object is UTF-8 as defined in [RFC 2279]. The "charset" Content-Type parameter can be used in MIME transports to specify any other IANA registered character set. from which I infer that the MIME charset parameter should be applied to the entire body part contents. Am I missing something here? From a practical perspective it seems obvious that 4.1.4 does not apply to BEGIN:VCALENDAR for example but I'm not at all clear how or where 2445 specifies the cases where the charset parameter should be applied and where it should not. Can someone with more experience than I clarify this? Regards Mike Higginbottom P.S. As an aside, I think I missed a step in the discussion of why we want to extend NON-US-ASCII to 0x80-0xFF. UTF-8 specifically precludes use of 0xFE and 0xFF so on that basis we should extend only to 0x80-0xFD. Are we specifying 0xFF to cover the Latin-1 charset that appears to be in common usage? From owner-ietf-calendar@mail.imc.org Thu Feb 27 09:08:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03578 for ; Thu, 27 Feb 2003 09:08:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RDqwA06349 for ietf-calendar-bks; Thu, 27 Feb 2003 05:52:58 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RDqvY06345 for ; Thu, 27 Feb 2003 05:52:57 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id C19DA4F2E for ; Thu, 27 Feb 2003 08:52:32 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: RFC: UTF-8 iCalendar bug solution Date: Thu, 27 Feb 2003 08:52:08 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <200302262229.45914.mark@WebServiceSolutions.com> <20030227053036.M42151@asitturnsout.org> In-Reply-To: <20030227053036.M42151@asitturnsout.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302270852.10734.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 27, 2003 12:30 am, Chris Olds wrote: > While paragraph 2.3 suggests rather strongly that UTF-8 or ASCII be used, > 2445 doesn't mandate any particular character set; as a result, in theory, > you could conform to 2445 with EBCDIC (where the ordinal value of the > letters and essential punctuation are different from ASCII), or UTF-16 > data (16-bit codes, so the ASCII values alternate with NUL bytes). If you > were to do such a foolhardy thing, you should use the codepoint that > corresponds to the canonical ASCII value in your non-US-ASCII-compatible > character set (e.g. an EBCDIC code page). Absent MIME headers, using That's about what I thought. I think it is very wrong that 2445 allows you to do this. This makes it impossible to build a parser that can parse all possible valid ICalendar. Someone could create a system that used UTF-16 characters and conform perfectly with 2445 yet it would be impossible to interoperate with likely all other implementations. > anything other than UTF-8 for 2445 data objects seems risky; unfortunately, > it sounds like people are doing this already. Yes. > A CHARSET property for VCALENDAR objects seems useful, as does a CHARSET > parameter for properties with text values; neither will be of any use if > they're not present, so it doesn't fix anything, just suggests how to make > things better going forward. True. Perhaps it should be modelled after PRODID where: Conformance: The property MUST be specified once in an iCalendar object and it MUST be specified immediately after BEGIN:VCALENDAR. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Thu Feb 27 09:46:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05994 for ; Thu, 27 Feb 2003 09:46:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1REWxJ08123 for ietf-calendar-bks; Thu, 27 Feb 2003 06:32:59 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1REWwY08119 for ; Thu, 27 Feb 2003 06:32:58 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 533E04F2E for ; Thu, 27 Feb 2003 09:31:00 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "Ietf-Calendar@Imc.Org" Subject: Re: UTF-8 iCalendar bug solution Date: Thu, 27 Feb 2003 09:30:35 -0500 User-Agent: KMail/1.5 References: <200302232018.26629.mark@WebServiceSolutions.com> <003701c2de5e$c278bd60$0100a8c0@fuzzbox> In-Reply-To: <003701c2de5e$c278bd60$0100a8c0@fuzzbox> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302270930.35990.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 27, 2003 07:50 am, Mike Higginbottom wrote: > Hello, > > This may be a dumb-ass question but here goes: > > Assuming I want to support some charset which does not have any > representation of US-ASCII characters at all. I want a CUA to be able to > send me text using this charset in a property value. Since the only source > of info for the charset I'm dealing with is the MIME headers, then this > charset is presumably also to be used to interpret the other property > values as well. How do I parse BEGIN:VCALENDAR for instance in the context > of this charset which has no representation of those characters? Yep. Doug also brought up Section 2.3 which allows for BEGIN:VCALENDAR to be recoded in the Russian charset which would break all parsers that expect this to be in ASCII. Perhaps someone will give an explanation for this but atm I think it is a bad bug. > The thinking behind this is that in 2445 we have: > > > > 4.1.4 Character Set > > There is not a property parameter to declare the character set used > in a property value. The default character set for an iCalendar > object is UTF-8 as defined in [RFC 2279]. > > The "charset" Content-Type parameter can be used in MIME transports > to specify any other IANA registered character set. > > > > from which I infer that the MIME charset parameter should be applied to the > entire body part contents. Am I missing something here? From a practical > perspective it seems obvious that 4.1.4 does not apply to BEGIN:VCALENDAR > for example but I'm not at all clear how or where 2445 specifies the cases > where the charset parameter should be applied and where it should not. > > Can someone with more experience than I clarify this? Good point. It seems to be the entire document. This also seems to further support Section 2.3. Having a CHARSET property that states the default character set of the iCalendar document, and CHARSET parameters that can state the character set of individual property values would be the most flexible. > Regards > > Mike Higginbottom > > P.S. As an aside, I think I missed a step in the discussion of why we want > to extend NON-US-ASCII to 0x80-0xFF. UTF-8 specifically precludes use of > 0xFE and 0xFF so on that basis we should extend only to 0x80-0xFD. Are we > specifying 0xFF to cover the Latin-1 charset that appears to be in common > usage? I like it because it covers the Latin-1 charset, which appears to be in common use. I just though of another reason why the definition of NON-US-ASCII is broken: if the MIME charset, or a CHARSET property/parameter, or even making use of Section 2.3 to use whatever charset/codepoints you like requires 0xf9-0xff then you are forced to create illegal iCalendar and will not be able to interoperate. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Thu Feb 27 12:12:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11993 for ; Thu, 27 Feb 2003 12:12:18 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RGvla19775 for ietf-calendar-bks; Thu, 27 Feb 2003 08:57:47 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RGvjY19771 for ; Thu, 27 Feb 2003 08:57:46 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id B13CF8D7B9; Thu, 27 Feb 2003 08:57:46 -0800 (PST) From: "Chris Olds" To: Mark Swanson , "Ietf-Calendar@Imc.Org" Subject: Re: UTF-8 iCalendar bug solution Date: Thu, 27 Feb 2003 08:57:46 -0800 Message-Id: <20030227165746.M46826@asitturnsout.org> In-Reply-To: <200302270930.35990.mark@WebServiceSolutions.com> References: <200302232018.26629.mark@WebServiceSolutions.com> <003701c2de5e$c278bd60$0100a8c0@fuzzbox> <200302270930.35990.mark@WebServiceSolutions.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 27 Feb 2003 09:30:35 -0500, Mark Swanson wrote > On February 27, 2003 07:50 am, Mike Higginbottom wrote: > > > > P.S. As an aside, I think I missed a step in the discussion of why we want > > to extend NON-US-ASCII to 0x80-0xFF. UTF-8 specifically precludes use of > > 0xFE and 0xFF so on that basis we should extend only to 0x80-0xFD. Are we > > specifying 0xFF to cover the Latin-1 charset that appears to be in common > > usage? > > I like it because it covers the Latin-1 charset, which appears to be > in common use. > > I just though of another reason why the definition of NON-US-ASCII > is broken: if the MIME charset, or a CHARSET property/parameter, or > even making use of Section 2.3 to use whatever charset/codepoints > you like requires 0xf9-0xff then you are forced to create illegal > iCalendar and will not be able to interoperate. If you think of the various productions that specify codepoints as abstract, then they can be thought of as giving examples in the default (UTF-8) character set, and as not binding on iCalendar objects in other character sets. However, I find little or no support in 2445 for such an interpretation, which means NON-US-ASCII (and the exclusion of the C0 control set (\0x00-\0x1F) plus DEL) could use some clarifying text. It is my impression that the authors of 2445 found this as complex and annoying an issue as we do, and decided to put it off for later. My evidence for this is in sec. 4.3.11 (quoted in part below); it appears that iCalendar 2.0 only supports latin-1 where it overlaps with 7-bit ASCII. /cco 4.3.11 Text Value Name: TEXT Purpose This value type is used to identify values that contain human readable text. Formal Definition: The character sets supported by this revision of iCalendar are UTF-8 and US ASCII thereof. The applicability to other character sets is for future work. The value type is defined by the following notation. -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Thu Feb 27 12:35:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13346 for ; Thu, 27 Feb 2003 12:35:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RHO1V20887 for ietf-calendar-bks; Thu, 27 Feb 2003 09:24:01 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RHO0Y20882 for ; Thu, 27 Feb 2003 09:24:00 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1RHNub2019644 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 27 Feb 2003 09:23:59 -0800 Message-ID: <3E5E49A6.2030102@Royer.com> Date: Thu, 27 Feb 2003 10:23:50 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: The charset issue Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070009030408050900090009" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070009030408050900090009 Content-Type: multipart/mixed; boundary="------------010508090703030301030404" This is a multi-part message in MIME format. --------------010508090703030301030404 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable (This message sent in UTF-8 - assuming Netscape did not lie to me) > > Yep. Doug also brought up Section 2.3 which allows for BEGIN:VCALENDAR= to be > recoded in the Russian charset which would break all parsers that > expect this to be in ASCII. Perhaps someone will give an explanation > for this but atm I think it is a bad bug. Below I am attempting to describe why this is not an issue. The entire world does not revolve around US-ASCII. Right now someone can e-mail you Russian, Japanese, or Chinese e-mail and modern e-mail tools (MUA) can display it - why? It is NOT because they send US-ASCII, UTF-8, or iso-8859-1. It is because the e-mail headers specify the charset and there have been worked out over the years procedures to charset convert to something your MUA can display. iMIP is the only proposed standard way to transport iCalendar objects - and that is e-mail that the tools already know how to process various charsets. I think that CAP is very close to RFC status at this point. And it also has a way to set the charset and language that will be used. The charset issue is NOT an issue for iCalendar, its an issue for implementations. The problem has been solved for iCalendar. Adding CHARSET to iCalendar will not fix any problem as you can not read 'C' 'H' 'A' 'R' 'S' 'E' 'T' if you do not already know the charset. In e-mail (iMIP) that problem is solved. In CAP that problem is solved. The only area were that is not solved is when someone wants to transport iCalendar objects over a protocol (ftp, http, whatever) where the charset negotiation specifics have not been standardized. And they have been standardized for http but some here I think want to transport iCalendar objects of unknown charset over an http connection= without telling the other endpoint the charset of the data itself. In iCalendar the entire object is 'in one charset'. It is NOT that the string 'VERSION' is in UTF-8 or US-ASCII and the '2.0' in another charset. In other words; iCalendar objects are TEXT objects in some known charset. A mini charset tutorial: Given this iCalendar object in UTF-8 from 2445 section 4.4: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T170000Z DTEND:19970715T035959Z SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR Now the same object in EBCDIC-US (attached) it is binary. Using Linux (I am sure other os's have similar methods) You can from the command line charset convert the EBCDIC-US to UTF-8 so you can parse it with your UTF-8 iCalendar program: iconv -f EBCDIC-US -t UTF-8 input_file > output_file And programmatically you use the standard iconv_open() set of functions. All OS that I know of have these features. If I were to add 'CHARSET:UTF-8' to the above UTF-8 versions of the object and then charset convert it to EBCDIC for my IBM program to understand - it would simply convert 'CHARSET:UTF-8' to the sequence: =C3=83=C3=88=C3=81=C3=99=C3=A2=C3=85=C3=A3z=C3=A4=C3=A3=C3=86`=C3=B8 Which would be utterly useless unless outside of the object itself I knew that it was the EBCDIC-US rendering of the UTF-8 string 'CHARSET:UTF-8'. But then it has no meaning because what good is saying 'CHARSET:UTF-8' in an 'EBCDIC-US' object. Books that I recommend are: Creating Worldwide Software Bill Tuthill David Smallberg Sun Microsystems / Prentice Hall ISBN 0-13-494493-3 And: Programming for the World A Guide to Internationalization Sandra Martin O'Donnel Prentice Hall ISBN 0-13-722190-8 The 2nd (I think) was out of print - but I got it from an online site that will legally sell you copies of out of print books. Sorry I do not remember the URL or name. --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------010508090703030301030404 Content-Type: application/x-java-vm; name="EBCDIC-US" Content-Disposition: inline; filename="EBCDIC-US" Content-Transfer-Encoding: base64 wsXHydV65cPB08XVxMHZJeXF2eLJ1tV68kvwJdfZ1sTJxHpgYWGIgYOSoqZhiIGVhIOBk2Fh 1dbV4sfU00Cl8UvwYWHF1SXCxcfJ1XrlxeXF1eMlxOPi48HZ43rx+fn38Pfx9OPx9/Dw8PDp JcTjxdXEevH5+ffw9/H14/Dz9fn1+ekl4uTU1MHZ6HrCgaKjiZOThUDEgahA14GZo6glxdXE euXF5cXV4yXF1cR65cPB08XVxMHZJQ== --------------010508090703030301030404-- --------------ms070009030408050900090009 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjcxNzIzNTBaMCMGCSqGSIb3DQEJBDEWBBTP s6M4nTtZPfzREy8yczkqYJimbjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAC1ivgZo1m2Sz CH5lTukg5PpHCRXGguoVRz2ayvxH7CgvevOeqZogW/zE42hc4DaTJwjtz7tn3h359HJvQu+L Y7ecJp7FVVs1jGVUkRQTvYnNK5LCStWYvzSZKy4r2cPtVyRGzJhSHxhxL7H9qoaWd2H92GqX O/t11P2H7P939Dk5KU3GxdIIJFBXhgAk2FjerB8Zmkah5pfk1wtWWdc0SPnBQmx3XlvAOYRt ff7W225XUTLpO/3SxJ3ldx5K8uLJ1v3Lh8fOXFgwSKtd97ZOtGBZYqv20Yv0bJljydbfMeFy Odcko9LWs10Bw8eQpiGnfy3u2VE11Fk9GpDyGJwxAgAAAAAAAA== --------------ms070009030408050900090009-- From owner-ietf-calendar@mail.imc.org Thu Feb 27 14:27:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18075 for ; Thu, 27 Feb 2003 14:27:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RJHCX01189 for ietf-calendar-bks; Thu, 27 Feb 2003 11:17:12 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RJHAY01185 for ; Thu, 27 Feb 2003 11:17:10 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id B3CF44F2E for ; Thu, 27 Feb 2003 14:16:46 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Thu, 27 Feb 2003 14:15:53 -0500 User-Agent: KMail/1.5 References: <3E5E49A6.2030102@Royer.com> In-Reply-To: <3E5E49A6.2030102@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302271415.53910.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 27, 2003 12:23 pm, Doug Royer wrote: > iMIP is the only proposed standard way to transport iCalendar > objects - and that is e-mail that the tools already know how to > process various charsets. Doug, I really do understand your MIME argument. But, as others have mentioned (and quoted from 2445) iCalendar objects MUST be able to work outside the MIME environment. I think you are trying to address this in the next paragraph... the format in this memo is equally applicable for use outside of a MIME message content type > The only area were that is not solved is when someone wants > to transport iCalendar objects over a protocol (ftp, http, whatever) > where the charset negotiation specifics have not been standardized. > And they have been standardized for http but some here I think want > to transport iCalendar objects of unknown charset over an http connection > without telling the other endpoint the charset of the data itself. What I was trying to describe was how Apple seems to have set up their iCalendar client/server. They seem to have a web server (and other sites have started to mimick this in a big way) that is serving iCalendar content, and I described how the web server is not capable of setting the proper character set because all iCalendar files would have the same extension. Apple gets by with a web server, and we get by with something different. I can see some major advantages to using the webserver approach and we may switch to it for some uses in the future. I do not like the fact that iCalendar forces me to use CAP or MIME especially when the mandate fo 2445 was for it to work outside of MIME. Forcing me to use CAP or MIME seriously limits its usefulness. >Adding CHARSET to iCalendar will not fix any problem as you >can not read 'C' 'H' 'A' 'R' 'S' 'E' 'T' if you do not already >know the charset. In e-mail (iMIP) that problem is solved. >In CAP that problem is solved. I understand this. I think 2445 is seriously broken in this regard. XML solves this issue by forcing the charset encoding attribute to be in ASCII. 2445 should learn from this and do the same. In order to interoperate, 2445 MUST be able to specify a CHARSET property and its value in ASCII only. Perhaps we need to modify BEGIN:VCALENDAR to: 1. BEGIN:VCALENDAR,CHARSET="UTF-8" 2. allow this line to be in ASCII only 3. bump the VERSION from 2.0 to 2.1. Cheers. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Thu Feb 27 14:33:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18277 for ; Thu, 27 Feb 2003 14:33:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RJNor01430 for ietf-calendar-bks; Thu, 27 Feb 2003 11:23:50 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RJNmY01426 for ; Thu, 27 Feb 2003 11:23:48 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 2B5684F2E for ; Thu, 27 Feb 2003 14:23:25 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Thu, 27 Feb 2003 14:22:32 -0500 User-Agent: KMail/1.5 References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> In-Reply-To: <200302271415.53910.mark@WebServiceSolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302271422.32059.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 27, 2003 02:15 pm, Mark Swanson wrote: > Perhaps we need to modify BEGIN:VCALENDAR to: > > 1. BEGIN:VCALENDAR,CHARSET="UTF-8" > 2. allow this line to be in ASCII only > 3. bump the VERSION from 2.0 to 2.1. OK, after I hit send I realized this isn't exactly a compatible upgrade. What about: 1. BEGIN:VCALENDAR 2. CHARSET:UTF-8 Where these two lines MUST be ASCII only, and they MUST be the first two lines. The CHARSET value must be an IANA registered charset (ASCII). -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Thu Feb 27 15:26:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18074 for ; Thu, 27 Feb 2003 14:27:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RJFYf01150 for ietf-calendar-bks; Thu, 27 Feb 2003 11:15:34 -0800 (PST) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RJFWY01146 for ; Thu, 27 Feb 2003 11:15:32 -0800 (PST) Received: from fuzzbox (81-86-188-66.dsl.pipex.com [81.86.188.66]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 0C95016000936 for ; Thu, 27 Feb 2003 19:15:29 +0000 (GMT) Received: from 127.0.0.1 by fuzzbox ([127.0.0.1] running VPOP3) with SMTP for ; Thu, 27 Feb 2003 19:15:27 -0000 Message-ID: <002301c2de94$928a04c0$0100a8c0@fuzzbox> From: "Mike Higginbottom" To: "Ietf-Calendar@Imc.Org" References: <200302232018.26629.mark@WebServiceSolutions.com> <003701c2de5e$c278bd60$0100a8c0@fuzzbox> <200302270930.35990.mark@WebServiceSolutions.com> <20030227165746.M46826@asitturnsout.org> Subject: Re: UTF-8 iCalendar bug solution Date: Thu, 27 Feb 2003 19:15:20 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Server: VPOP3 Enterprise V1.5.0 - Registered Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Chris Olds" To: "Mark Swanson" ; "Ietf-Calendar@Imc.Org" Sent: Thursday, February 27, 2003 4:57 PM Subject: Re: UTF-8 iCalendar bug solution > It is my impression that the authors of 2445 found this as complex and > annoying an issue as we do, and decided to put it off for later. My evidence > for this is in sec. 4.3.11 (quoted in part below); it appears that iCalendar > 2.0 only supports latin-1 where it overlaps with 7-bit ASCII. > I can well understand this viewpoint (looking at i18n in general is something I've been studiously avoiding up until now) but I think we have come to the stage now, not just in the context of 2445 and calendaring, where the issues do need to be addressed fully and accurately. The vast majority of discussions on the 822 mailing list for example focus on these very issues and they always seem to generate a lot of heat. It's a huge problem for them with the ubiquity of e-mail and the plethora of non-conforming software. It's not something that is easily retrofitted to an existing installed base and the presence of the Latin-1 discussion serves only to highlight this. Even with the (relatively) small number of calendaring apps about today we are already seeing problems emerging. Since I have no expertise, I'm unfortunately able to offer little in the way of a route forward but I suspect the fundamental issues are the usual ones: 1) Define what i18n support we want to provide in the ideal world situation. 2) Identify the scope of existing software which would become broken if we were to implement the 'ideal' solution. 3) Come up with a compromise that comes as close to the ideal as possible whilst not breaking too much of the installed codebase. 4) Make sure the discussions don't just generate heat without light - there's always a tendency for the tricky threads to just peter out without concensus or action. 5) Implement that compromise in the RFC's and drafts. And make sure we don't duck the issues that have caused so much trouble in other application domains. Just my 2c anyway. Mike Higginbottom From owner-ietf-calendar@mail.imc.org Thu Feb 27 15:28:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20712 for ; Thu, 27 Feb 2003 15:28:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RK8Zs03021 for ietf-calendar-bks; Thu, 27 Feb 2003 12:08:35 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RK8XY03014 for ; Thu, 27 Feb 2003 12:08:34 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1RK8Wb2020891 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 27 Feb 2003 12:08:34 -0800 Message-ID: <3E5E703A.2060608@Royer.com> Date: Thu, 27 Feb 2003 13:08:26 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030601020006050301000903" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030601020006050301000903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > > I understand this. I think 2445 is seriously broken in this regard. > XML solves this issue by forcing the charset encoding attribute to be in > ASCII. No. Is what the XML spec says is that most are detectable because the VALUE of the 'encoding' attribute to the 'xml' tag must be in ASCII (however encoded) . However there are some charsets where that is difficult and it can require a hit and miss testing to determine the charset. (see Chris Olds 26-FEB where he quoted from the XML spec) There is an XML-CAL proposal draft-ietf-calsch-many-xcal-02.txt that is in the process of defining a mapping between iCAL format and XML, but that will not come out until after CAP. > 2445 should learn from this and do the same. > > In order to interoperate, 2445 MUST be able to specify a CHARSET property and > its value in ASCII only. > Perhaps we need to modify BEGIN:VCALENDAR to: > > 1. BEGIN:VCALENDAR,CHARSET="UTF-8" > 2. allow this line to be in ASCII only > 3. bump the VERSION from 2.0 to 2.1. Way too late for that as implementations already exist. We could add CHARSET - but it would be usless because the existing implementations charset convert the entire object now. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030601020006050301000903 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjcyMDA4MjZaMCMGCSqGSIb3DQEJBDEWBBTf 5naG2tiqf9kh6jHz5jZ+l5vpizBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAWnzGG819iHQB 3qQkd45PxDYyzFb2ybVdFoM7UGDimhuZs9Gu1r7X720icaL8QjZbBBqzhgpZG97tB0FHZAuA LNkIJ510orcviQ7KkVpAQEVYIEq2OuRw2HYFoz7t0Zmb9grU4nKSf4Av/5EdijWhZ1Wo1lph kXW8xEwOJqbM8YhqUbnXF7EUP1hwJE12k6lCVMrbA6nqCb48SRsZHO+suGPLenZSPHEnh+nL YilWyJn+52HVaHXMAv/mg1q5G/AIrojdgLXjyt/TEZGvHpAPeVvLKlf4M4Aq9xUEgg1y70an 0bBb+/5L6rDO0ICAlvYreS5YowQ5Pqhoj/yIUQu6LgAAAAAAAA== --------------ms030601020006050301000903-- From owner-ietf-calendar@mail.imc.org Thu Feb 27 15:40:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21475 for ; Thu, 27 Feb 2003 15:40:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RKRwv03726 for ietf-calendar-bks; Thu, 27 Feb 2003 12:27:58 -0800 (PST) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RKRvY03722 for ; Thu, 27 Feb 2003 12:27:57 -0800 (PST) Received: from fuzzbox (81-86-188-66.dsl.pipex.com [81.86.188.66]) by pengo.systems.pipex.net (Postfix) with ESMTP id 914B34C00125 for ; Thu, 27 Feb 2003 20:27:53 +0000 (GMT) Received: from 127.0.0.1 by fuzzbox ([127.0.0.1] running VPOP3) with SMTP for ; Thu, 27 Feb 2003 20:27:50 -0000 Message-ID: <003f01c2de9e$b1a0a710$0100a8c0@fuzzbox> From: "Mike Higginbottom" To: References: <3E5E49A6.2030102@Royer.com> Subject: Re: The charset issue Date: Thu, 27 Feb 2003 20:27:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Server: VPOP3 Enterprise V1.5.0 - Registered Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug, Well, something is seriously flawed here. Either it's my understanding of how this is all supposed to fit together or it's the content of 2445. I'm equally prepared to accept either as the result of this discussion ;-) ----- Original Message ----- From: "Doug Royer" To: Sent: Thursday, February 27, 2003 5:23 PM Subject: The charset issue > (This message sent in UTF-8 - assuming Netscape did not lie to me) That's what my MUA tells me it is. >The entire world does not revolve around US-ASCII. Right now someone >can e-mail you Russian, Japanese, or Chinese e-mail and modern >e-mail tools (MUA) can display it - why? > It is NOT because they send US-ASCII, UTF-8, or iso-8859-1. >It is because the e-mail headers specify the charset and there >have been worked out over the years procedures to charset convert >to something your MUA can display. Yes, but you're talking about e-mail here rather than iCalendar and I would anticipate that a Chinese e-mail would have content that was entirely representable using the Chinese character set. If a Chinese person wanted to e-mail the text BEGIN:VCALENDAR how would he do that? My understanding is that he would have to specify a MIME part using a charset that *could* represent those characters (with whatever code points were appropriate). There's no way to mix charsets within a single MIME part and yet we are apparently supposed to mix characters from one charset with characters from another charset in the same body part >iMIP is the only proposed standard way to transport iCalendar >objects - and that is e-mail that the tools already know how to >process various charsets. Fair enough, but the tools don't know how to process two mutually exclusive charsets within the same object. >I think that CAP is very close to RFC status at this point. And it >also has a way to set the charset and language that will be used. Yes, but I remain to be convinced that it has a universally applicable way to set the charset and language that will be used. >The charset issue is NOT an issue for iCalendar, its an issue >for implementations. The problem has been solved for iCalendar. Still not convinced.... >Adding CHARSET to iCalendar will not fix any problem as you >can not read 'C' 'H' 'A' 'R' 'S' 'E' 'T' if you do not already >know the charset. In e-mail (iMIP) that problem is solved. >In CAP that problem is solved. Yes, but my understanding of this propsed scheme was that (for example) you specify the charset in the MIME headers that is to be used for the parsing of the iCalendar object as a whole. It would have to be mandatory for that charset to support a representation of the characters used in the 'structural' text specified in 2445 (e.g. BEGIN:VCALENDAR). The CHARSET parameter would be present only in those properties that explicitly supported NON-US-ASCII text (e.g. the value of an ATTENDEE property) and would be applied only to the NON-US-ASCII portion of the property text. The text 'CHARSET' would be represented in the MIME specified charset (US-ASCII or UTF-8 for example) that could represent the characters C, H, A, R, S, E, T correctly and unambigously. It's ugly and kludgy but in the absence of anything better I think it would work. >The only area were that is not solved is when someone wants >to transport iCalendar objects over a protocol (ftp, http, whatever) >where the charset negotiation specifics have not been standardized. >And they have been standardized for http but some here I think want >to transport iCalendar objects of unknown charset over an http connection >without telling the other endpoint the charset of the data itself. Agreed. >In iCalendar the entire object is 'in one charset'. It is NOT >that the string 'VERSION' is in UTF-8 or US-ASCII and the '2.0' in >another charset. In other words; iCalendar objects are >TEXT objects in some known charset. >A mini charset tutorial: >Given this iCalendar object in UTF-8 from 2445 section 4.4: > BEGIN:VCALENDAR > VERSION:2.0 > PRODID:-//hacksw/handcal//NONSGML v1.0//EN > BEGIN:VEVENT > DTSTART:19970714T170000Z > DTEND:19970715T035959Z > SUMMARY:Bastille Day Party > END:VEVENT > END:VCALENDAR >Now the same object in EBCDIC-US (attached) it is binary. Sure, that's fine, but how would you approach this in some Chinese charset rather than EBCDIC? I think I'm still holding on to the issues involved here but please feel free to tell me I'm talking rubbish....... Mike Higginbottom From owner-ietf-calendar@mail.imc.org Thu Feb 27 16:25:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24425 for ; Thu, 27 Feb 2003 16:25:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RLILn05990 for ietf-calendar-bks; Thu, 27 Feb 2003 13:18:21 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RLIJY05984 for ; Thu, 27 Feb 2003 13:18:19 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1RLIHb2021435 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 27 Feb 2003 13:18:20 -0800 Message-ID: <3E5E8094.8050507@Royer.com> Date: Thu, 27 Feb 2003 14:18:12 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Reading NON UTF-8 References: <200302232018.26629.mark@WebServiceSolutions.com> <003701c2de5e$c278bd60$0100a8c0@fuzzbox> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060307090001040600030300" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060307090001040600030300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mike Higginbottom wrote: > Hello, > > This may be a dumb-ass question but here goes: > > Assuming I want to support some charset which does not have any > representation of US-ASCII characters at all. I want a CUA to be able to > send me text using this charset in a property value. Since the only source > of info for the charset I'm dealing with is the MIME headers, then this > charset is presumably also to be used to interpret the other property values > as well. How do I parse BEGIN:VCALENDAR for instance in the context of this > charset which has no representation of those characters? You can charset convert from and to any charset. So in UTF-8 'BEGIN:VCALENDAR' has the following TEXT and OCTAL values: UTF-8 B E G I N : V C A L E N D A R 102 105 107 111 116 072 126 103 101 114 105 116 104 101 122 And the octal values in UTF-16: 177377 000102 000105 000107 000111 000116 000072 000126 000103 000101 000114 000105 000116 000104 000101 000122 So in this case there is a 1:1 mapping to values (same number of printable characters) and a 1:2 mapping to octet values (each UTF-8 octet in THIS example is 1 octet and it results in 2 octets in UTF-16) + 2 leading octets (The 2 lead octets for UTF-16). Not all charsets are this easy, some a multiple and a varying number of octets in length for each printable character (multibyte). So for any blob of data if you want to parse it in a charset that is native to your program then you charset convert it from the PROVIDED charset to your charset (See 'iconv' - in previous e-mail), something like: convert(blob1 in X-CHARSET to blob2 in UTF-8) At some level is the core blob of data. And many XML implementations can guess the charset of MOST XML data, not even XML or its implementations can guess all charsets that can be used to encode XML data. I have read books that tell the reader ways to make that guess - however it only works some to most of the time. And until the correct charset is guessed and *tried* even XML in an unknown charset is a blob of data. The way we solved this in iCalendar is to pass the problem (the name of the charset) to the transport layer then 100% of the time we know the correct charset and the only limitation is that the endpoints must be able to handle the named charset. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060307090001040600030300 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjcyMTE4MTJaMCMGCSqGSIb3DQEJBDEWBBTG 2x7aF6/Er1m4O6LAuomXd7LUPjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAoJkiwv6h2Vzi ehjgtJLcGNf3pZLiEq8E47xjM+8LJU6rZLegS2dFne4xDv5cVHHjtM04ItppjdGoRQrd8RaA 3fz6tBRwUSMqZOTRYNi+5zhnYEXSHsk4z1HIyPG8H49GpwNqF2XUrmUZWxmRKT1365QHO5gE LKCk0AnAT8sCvyuj036MBd5iTO5uniSyFHY/FNUUI6v2ozxpBIqdUH3mvxoS8PcVI+4FcQZP G4ot1QSTNGnTQrVbvlok6fMmfjdoX/ZUh6EBRkpd6/SeO4apCNF920k6QxOqOuWUr+pczZtw Ew9XzyR1n59r1MXlmYPHnJYyPPvXRGmH94fcVU2cbAAAAAAAAA== --------------ms060307090001040600030300-- From owner-ietf-calendar@mail.imc.org Thu Feb 27 16:43:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25132 for ; Thu, 27 Feb 2003 16:43:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RLTMM06421 for ietf-calendar-bks; Thu, 27 Feb 2003 13:29:22 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RLTLY06414 for ; Thu, 27 Feb 2003 13:29:21 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1RLTJb2021502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 27 Feb 2003 13:29:22 -0800 Message-ID: <3E5E832A.5040001@Royer.com> Date: Thu, 27 Feb 2003 14:29:14 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <200302271422.32059.mark@WebServiceSolutions.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060707080305030705040004" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060707080305030705040004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mark Swanson wrote: > On February 27, 2003 02:15 pm, Mark Swanson wrote: > >>Perhaps we need to modify BEGIN:VCALENDAR to: >> >>1. BEGIN:VCALENDAR,CHARSET="UTF-8" >>2. allow this line to be in ASCII only >>3. bump the VERSION from 2.0 to 2.1. > > > OK, after I hit send I realized this isn't exactly a compatible upgrade. > > What about: > 1. BEGIN:VCALENDAR > 2. CHARSET:UTF-8 > > Where these two lines MUST be ASCII only, and they MUST be the first two > lines. The CHARSET value must be an IANA registered charset (ASCII). The problems is that existing implementations already convert the entire BEGIN/END VCALENDAR to the target charset. So if you are going to interoperate with them you are going to have to do that work anyway. In iCalendar we already solved this problem by having the charset name in a layer above the blob of data. So iCalendar objects are not restricted to the XML limitation of having only MOST charsets guessable. CAP uses BEEP and iMIP uses e-mail. If you want to propose another transport - you can submit one. But there is going to be a HUGE amount of resistance in making incompatible iCalendar objects. And you will have incompatible iCalendar objects with the proposal above. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms060707080305030705040004 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjcyMTI5MTRaMCMGCSqGSIb3DQEJBDEWBBTd UiP1I6IRd+qzM3/dMLBJedBh2DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAjaVuylX4f/0X cgSi+Qdsi9ABwCL6T6dmokW5j8RNuKcSdYd+jA5c1BvoxtzKQjsVVtbK9RITCRqKht4MTMkd 5LIJMdxQ5f5V/9LHfs9b0GbSpLwAg2D2pWUCQPFsdaMvjins6+qOFrqIZmKypjTf/R2U5A4n Mn/sn3Y+jTXP7SYJAyL864n17/2vixzzI4yelEUG9F3+zLnT9TLFaL1mq29Xjh5wxbhwgZIH 9cWMC/TsT/5/CooRY1sP93YnuhShVlF/N04HYKu+sjG+GnuxX7W4HaqW3wmgJod+VEA5NNUO D+slZC4BIuvVryxGWiMQCh06BZSM0aJ/W2fofWQx/QAAAAAAAA== --------------ms060707080305030705040004-- From owner-ietf-calendar@mail.imc.org Thu Feb 27 17:11:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26085 for ; Thu, 27 Feb 2003 17:11:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RM4En08475 for ietf-calendar-bks; Thu, 27 Feb 2003 14:04:14 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RM4DY08471 for ; Thu, 27 Feb 2003 14:04:13 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id A3F308D7B9; Thu, 27 Feb 2003 14:04:15 -0800 (PST) From: "Chris Olds" To: Mark Swanson , "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Thu, 27 Feb 2003 14:04:15 -0800 Message-Id: <20030227220415.M57190@asitturnsout.org> In-Reply-To: <200302271422.32059.mark@WebServiceSolutions.com> References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <200302271422.32059.mark@WebServiceSolutions.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 27 Feb 2003 14:22:32 -0500, Mark Swanson wrote > On February 27, 2003 02:15 pm, Mark Swanson wrote: > > Perhaps we need to modify BEGIN:VCALENDAR to: > > > > 1. BEGIN:VCALENDAR,CHARSET="UTF-8" > > 2. allow this line to be in ASCII only > > 3. bump the VERSION from 2.0 to 2.1. > > OK, after I hit send I realized this isn't exactly a compatible upgrade. > > What about: > 1. BEGIN:VCALENDAR > 2. CHARSET:UTF-8 > > Where these two lines MUST be ASCII only, and they MUST be the first > two lines. The CHARSET value must be an IANA registered charset > (ASCII). This could be relaxed a bit without losing anything. As long as the charset used supports the invariant portion of the ISO 646 charset (as defined in RFC1345[1]) all of the tokens (keywords, x-names, iana-names and punctuation) used in 2445 will be intelligible. Obviously, this leaves out EBCDIC charsets and charsets with more than 8 bits in the default state, but those charsets don't work with 2445 as it is now either (absent a MIME wrapper). /cco [1] ftp://ftp.isi.edu/in-notes/rfc1345.txt -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Thu Feb 27 17:23:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26280 for ; Thu, 27 Feb 2003 17:23:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RMK3i09123 for ietf-calendar-bks; Thu, 27 Feb 2003 14:20:03 -0800 (PST) Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RMK2Y09119 for ; Thu, 27 Feb 2003 14:20:02 -0800 (PST) Received: from fuzzbox (81-86-188-66.dsl.pipex.com [81.86.188.66]) by colossus.systems.pipex.net (Postfix) with ESMTP id 2547F160002CC for ; Thu, 27 Feb 2003 22:19:59 +0000 (GMT) Received: from 127.0.0.1 by fuzzbox ([127.0.0.1] running VPOP3) with SMTP for ; Thu, 27 Feb 2003 22:19:57 -0000 Message-ID: <009b01c2deae$5b749d00$0100a8c0@fuzzbox> From: "Mike Higginbottom" To: References: <200302232018.26629.mark@WebServiceSolutions.com> <003701c2de5e$c278bd60$0100a8c0@fuzzbox> <3E5E8094.8050507@Royer.com> Subject: Re: Reading NON UTF-8 Date: Thu, 27 Feb 2003 22:19:22 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Server: VPOP3 Enterprise V1.5.0 - Registered Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Doug Royer" To: Sent: Thursday, February 27, 2003 9:18 PM Subject: Re: Reading NON UTF-8 > You can charset convert from and to any charset. So in UTF-8 > 'BEGIN:VCALENDAR' has the following TEXT and OCTAL values: > > UTF-8 > > B E G I N : V C A L E N D A R > 102 105 107 111 116 072 126 103 101 114 105 116 104 101 122 > > And the octal values in UTF-16: > > 177377 000102 000105 000107 000111 000116 000072 000126 > 000103 000101 000114 000105 000116 000104 000101 000122 > Ahhhhh. I see! In other words it's the responsibility of the implementation to produce the right octet stream regardless of local character representation. In that case, please ignore my next message which as far as I can tell hasn't reached the list as yet. Thanks for the clarification. Mike Higginbottom From owner-ietf-calendar@mail.imc.org Thu Feb 27 19:43:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28925 for ; Thu, 27 Feb 2003 19:43:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S0eAd12341 for ietf-calendar-bks; Thu, 27 Feb 2003 16:40:10 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S0e8Y12336 for ; Thu, 27 Feb 2003 16:40:08 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h1S0e7b2022852 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 27 Feb 2003 16:40:10 -0800 Message-ID: <3E5EAFE1.7050709@Royer.com> Date: Thu, 27 Feb 2003 17:40:01 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <200302271422.32059.mark@WebServiceSolutions.com> <20030227220415.M57190@asitturnsout.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000406000503080708020909" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000406000503080708020909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > This could be relaxed a bit without losing anything. As long as the charset > used supports the invariant portion of the ISO 646 charset (as defined in > RFC1345[1]) all of the tokens (keywords, x-names, iana-names and punctuation) > used in 2445 will be intelligible. Obviously, this leaves out EBCDIC charsets > and charsets with more than 8 bits in the default state, but those charsets > don't work with 2445 as it is now either (absent a MIME wrapper). Multitbyte will work when you know the charset type - as in CAP or when the endpoints have agreed to the charset in advance of using the object outside of MIME. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000406000503080708020909 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAyMjgwMDQwMDJaMCMGCSqGSIb3DQEJBDEWBBRe isWpWLTm8nwSXBa1fSCObVJYgTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAD8aGQzFoIiEP QBguBXu0EPWTOSyvaAOZvL0ofRcIP+GlTqnBMUCTKjLBruqfzWAc5qp816H4L2IvocnwjWqD OKMUxV20T3aarQkDlbP20Accc1xUZkYyxVphTiTZ2mivWcgBr0TvyfPI455TQnurHd7bCpF+ qNyHpMh3F2/yZHIHd7fPJDrWvEaf8uQa/W2HJFvqmjAZHp6xcvre7x+3m0Q1wr9N+5aybGO/ X/pP13uzUxDPe+ptzhmTF7lqND/YD/9zQE06bdCLBfDMmvbjigXk3Rh50EQ0uPZ0QV459v+M GZdNoDM+zOT5+R3STCClNH/NIg4jaEgyAVEQHTKGwgAAAAAAAA== --------------ms000406000503080708020909-- From owner-ietf-calendar@mail.imc.org Thu Feb 27 22:01:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01652 for ; Thu, 27 Feb 2003 22:01:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S2pdr15710 for ietf-calendar-bks; Thu, 27 Feb 2003 18:51:39 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S2pcY15706 for ; Thu, 27 Feb 2003 18:51:38 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 635634F2F for ; Thu, 27 Feb 2003 21:51:16 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Thu, 27 Feb 2003 21:49:42 -0500 User-Agent: KMail/1.5 References: <3E5E49A6.2030102@Royer.com> <200302271422.32059.mark@WebServiceSolutions.com> <3E5E832A.5040001@Royer.com> In-Reply-To: <3E5E832A.5040001@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302272149.42366.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > What about: > > 1. BEGIN:VCALENDAR > > 2. CHARSET:UTF-8 > > > > Where these two lines MUST be ASCII only, and they MUST be the first two > > lines. The CHARSET value must be an IANA registered charset (ASCII). > > The problems is that existing implementations already convert > the entire BEGIN/END VCALENDAR to the target charset. So if you > are going to interoperate with them you are going to have to do that > work anyway. If implementations stick to the default recommended UTF-8 charset this will never be an issue, and a very minor one if they don't. Doug, please let me know if you think differently. I am pushing for a CHARSET proposal but I do not want to impose any burden on existing or future systems based on the MIME or CAP transport. I also do not want to propose anything that will break compatibility. > In iCalendar we already solved this problem by having the > charset name in a layer above the blob of data. So iCalendar > objects are not restricted to the XML limitation of having > only MOST charsets guessable. Which prevents iCalendar objects from working 100% of the time outside of MIME/CAP environments. > CAP uses BEEP and iMIP uses e-mail. If you want to propose > another transport - you can submit one. But there is going to be > a HUGE amount of resistance in making incompatible iCalendar > objects. And you will have incompatible iCalendar objects > with the proposal above. 2445 is broken. It should be fixed. If you want to keep things the way they are then I think it would be fair to say you should propose we remove all wording like, "the format in this memo is equally applicable for use outside of a MIME message content type" Here is a further modified proposal: The first two properties MUST be: 1. BEGIN:VCALENDAR 2. CHARSET:UTF-8 With the following conditions: 1. Both of these properties are in a character set encoding that is ASCII-compatible. I think that was what Chris was saying about "supports the invariant portion of the ISO 646 charset". Chris: please speak up if I misunderstood you. 2. CHARSET is optional. There is a single default charset: UTF-8. Put another way: if CHARSET is not specified the character encoding MUST be UTF-8. I believe this should be completely compatible with version 2.0 of ICalendar specification. If there are no major problems with this I will expand this into a formal request which will include a list of all of the good points made by the people on this list over the past few days. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Thu Feb 27 22:09:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01836 for ; Thu, 27 Feb 2003 22:09:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S349d16056 for ietf-calendar-bks; Thu, 27 Feb 2003 19:04:09 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S348Y16052 for ; Thu, 27 Feb 2003 19:04:08 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 753DC4F2F for ; Thu, 27 Feb 2003 22:03:46 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Thu, 27 Feb 2003 22:02:12 -0500 User-Agent: KMail/1.5 References: <3E5E49A6.2030102@Royer.com> <3E5E832A.5040001@Royer.com> <200302272149.42366.mark@WebServiceSolutions.com> In-Reply-To: <200302272149.42366.mark@WebServiceSolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302272202.12272.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I believe this should be completely compatible with version 2.0 of > ICalendar specification. Yep, hit send too quickly. Compatible as long as the CHARSET property isn't used... :-) I don't think an X- property should be used for this though that wouldn't break any existing parsers... -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Fri Feb 28 02:02:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08507 for ; Fri, 28 Feb 2003 02:02:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S6siw23016 for ietf-calendar-bks; Thu, 27 Feb 2003 22:54:44 -0800 (PST) Received: from albert.asitturnsout.org (postfix@dsl-156-051.atm02.sea.blarg.net [206.124.156.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S6shY23012 for ; Thu, 27 Feb 2003 22:54:43 -0800 (PST) Received: from webmail.asitturnsout.org (localhost [127.0.0.1]) by albert.asitturnsout.org (Postfix) with ESMTP id 5DC6C8D7B9; Thu, 27 Feb 2003 22:54:46 -0800 (PST) From: "Chris Olds" To: Mark Swanson , "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Thu, 27 Feb 2003 22:54:46 -0800 Message-Id: <20030228065446.M87759@asitturnsout.org> In-Reply-To: <200302272149.42366.mark@WebServiceSolutions.com> References: <3E5E49A6.2030102@Royer.com> <200302271422.32059.mark@WebServiceSolutions.com> <3E5E832A.5040001@Royer.com> <200302272149.42366.mark@WebServiceSolutions.com> X-Mailer: Open WebMail 1.81 20021127 X-OriginatingIP: 206.124.156.51 (cco) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 27 Feb 2003 21:49:42 -0500, Mark Swanson wrote > > 2445 is broken. It should be fixed. If you want to keep things the > way they are then I think it would be fair to say you should propose > we remove all wording like, "the format in this memo is equally > applicable for use outside of a MIME message content type" > > Here is a further modified proposal: > > The first two properties MUST be: > 1. BEGIN:VCALENDAR > 2. CHARSET:UTF-8 > > With the following conditions: > > 1. Both of these properties are in a character set encoding that is > ASCII-compatible. I think that was what Chris was saying about > "supports the invariant portion of the ISO 646 charset". Chris: > please speak up if I misunderstood you. What I said is weaker than 'US-ASCII compatible', but your understanding is correct. (and yet, here I am speaking up...) > 2. CHARSET is optional. There is a single default charset: UTF-8. > Put another way: if CHARSET is not specified the character encoding > MUST be UTF-8. > > I believe this should be completely compatible with version 2.0 of > ICalendar specification. If there are no major problems with this I > will expand this into a formal request which will include a list of > all of the good points made by the people on this list over the past > few days. I think this proposal is a good idea. I'd lke to offer some suggestions: 1) 2445 already says that the first line of an iCalendar object MUST contain a delimiter string (sec 4.4, p50), so all you need to say is that an iCalendar object (equiv. icalbody) MAY contain a CHARSET property, and if it does, the CHARSET property MUST immediately follow the opening delimiter string ("BEGIN" ":" "VCALENDAR" CRLF) 2) It may be clearer to specify the CHARSET property without using 'UTF-8' in the example; something like: the CHARSET property is defined as "CHARSET" ":" iana-token and then note that the iana-token should be a charset name. CHARSET should be specified so that it MUST NOT have any parameters, I think. 3) There is already precedent for a property in the iCalendar object having to match the MIME headers (METHOD: sec 3.2, sec 4.7.2), and I think that it would be good to follow this pattern for CHARSET. Sec 4.7.2 says, in part: Description: When used in a MIME message entity, the value of this property MUST be the same as the Content-Type "method" parameter value. This property can only appear once within the iCalendar object. If either the "METHOD" property or the Content-Type "method" parameter is specified, then the other MUST also be specified. Obviously, it isn't possible to use such strong wording for CHARSET, but something along the lines of: Description: When used in a MIME message entity, the value of this property MUST be the same as the Content-Type "charset" parameter value. This property can only appear once within the iCalendar object, and MUST be precede any other properties or components. If either the "CHARSET" property or the Content-Type "charset" parameter is specified, then the other SHOULD also be specified. A suggestion that programs that store or transmit iCalendar objects without MIMI-encapsulation should add a CHARSET property (if none is present and the charset is known) seems in order too. It's too bad that 2445 doesn't include the 'iana-prop' production (it looks like CAP adds that); if it did, a CHARSET property on iCalendar objects would be completely compatible as soon as it was written up. CAP-aware software might not understand CHARSET, but it certainly shouldn't choke on it. +1 for Mark's proposal. /cco -- GPG Key Fingerprint: B375 A4E7 752B DB8C 4359 852E C3CF BF64 379A E9B2 Debian Project (http://www.debian.org) From owner-ietf-calendar@mail.imc.org Fri Feb 28 06:48:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21309 for ; Fri, 28 Feb 2003 06:48:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SBNt102747 for ietf-calendar-bks; Fri, 28 Feb 2003 03:23:55 -0800 (PST) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SBNsY02741 for ; Fri, 28 Feb 2003 03:23:54 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id BCABB155C6; Fri, 28 Feb 2003 12:23:46 +0100 (CET) Date: Fri, 28 Feb 2003 12:23:46 +0100 From: Andrea Campi To: Mark Swanson Cc: "ietf-calendar@imc.org" Subject: Re: The charset issue Message-ID: <20030228112346.GA44508@inet.it> References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302271415.53910.mark@WebServiceSolutions.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.3i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Feb 27, 2003 at 02:15:53PM -0500, Mark Swanson wrote: > > The only area were that is not solved is when someone wants > > to transport iCalendar objects over a protocol (ftp, http, whatever) > > What I was trying to describe was how Apple seems to have set up their > iCalendar client/server. They seem to have a web server (and other sites have Since the discussion has reached (IMO) a dead end, I'll voice my opinion. I am 1000% of Doug's opinion. Mark, you are presenting a non-compliant implementation as reason for changing RFC2445. Like it or not, an http uses MIME, so everything you know about MIME applies - including provisions set forth in RFC2445. Without getting into too many details, here's an example: brian% telnet www.webcom.it 80 GET /test.ics HTTP/1.1 Host: www.webcom.it HTTP/1.1 200 OK Date: Fri, 28 Feb 2003 11:19:49 GMT [...] Content-Length: 30 Content-Type: text/calendar; charset=utf-8 BEGIN:VCALENDAR END:VCALENDAR If Apple or any other websites get this wrong, well, that's their problem, and they have to either fix it or face the incompatibilities that will arise. And as far as I know, it might take some time, but they WILL fix it. So if I have to cast a vote, I am completely against changing RFC2445. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Feb 28 09:01:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29001 for ; Fri, 28 Feb 2003 09:01:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SDrBW12317 for ietf-calendar-bks; Fri, 28 Feb 2003 05:53:11 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SDr9Y12313 for ; Fri, 28 Feb 2003 05:53:09 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id CF3EE4F2E; Fri, 28 Feb 2003 08:52:44 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: Andrea Campi Subject: Re: The charset issue Date: Fri, 28 Feb 2003 08:50:26 -0500 User-Agent: KMail/1.5 Cc: "ietf-calendar@imc.org" References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> In-Reply-To: <20030228112346.GA44508@inet.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302280850.26773.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 28, 2003 06:23 am, Andrea Campi wrote: > brian% telnet www.webcom.it 80 > GET /test.ics HTTP/1.1 > Host: www.webcom.it > > HTTP/1.1 200 OK > Date: Fri, 28 Feb 2003 11:19:49 GMT > [...] > Content-Length: 30 > Content-Type: text/calendar; charset=utf-8 > > BEGIN:VCALENDAR > END:VCALENDAR Perhaps you missed the discussion about this. There is a big problem with it: if test1.ics is in utf-8 and test2.ics is in latin1 the web server will serve both as latin1. This can not work. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Fri Feb 28 09:27:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29636 for ; Fri, 28 Feb 2003 09:27:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SEJog13318 for ietf-calendar-bks; Fri, 28 Feb 2003 06:19:50 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SEJmY13313 for ; Fri, 28 Feb 2003 06:19:48 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id C28F24F2E; Fri, 28 Feb 2003 09:19:23 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: Andrea Campi Subject: Re: The charset issue Date: Fri, 28 Feb 2003 09:17:04 -0500 User-Agent: KMail/1.5 Cc: "ietf-calendar@imc.org" References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> In-Reply-To: <20030228112346.GA44508@inet.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302280917.04804.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On February 28, 2003 06:23 am, Andrea Campi wrote: > > Since the discussion has reached (IMO) a dead end, I'll voice my opinion. > I am 1000% of Doug's opinion. Mark, you are presenting a non-compliant > implementation as reason for changing RFC2445. Like it or not, an http No Andrea. This is not why I am doing this at all. Perhaps a summary of reasons will help: 1. MIME is not the universe (to steal a phrase from John Stacke :-). 2445 states iCalendar objects are to work fine outside the MIME environment. To quote from 2445, "the format in this memo is equally applicable for use outside of a MIME message content type.". There are the obvious examples of using an iCalendar object outside the MIME environment: http/ftp/custom protocols - even copying the iCalendar object as presented by Outlook (in text format, which does not show the MIME headers as part of the iCalendar object) to the clipboard. John Strake has stated that no MIME implementations (MUA or HTTP) include the MIME headers when it saves a MIME body-part. I believe a lot more examples will surface as time goes on. 2445 will likely last for decades, why not fix it now? Lastly, I believe 2445 MUST be fixed. If people do NOT agree with the CHARSET property then they MUST agree to change the wording of 2445 to something like, "the format of this memo is only applicable for use in a MIME message content type". -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Fri Feb 28 13:58:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08956 for ; Fri, 28 Feb 2003 13:58:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SIh8D29821 for ietf-calendar-bks; Fri, 28 Feb 2003 10:43:08 -0800 (PST) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SIh6Y29816 for ; Fri, 28 Feb 2003 10:43:07 -0800 (PST) Received: from penguin.andrew.cmu.edu (PENGUIN.andrew.cmu.edu [128.2.121.100]) by smtp6.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1SIh7pZ030984; Fri, 28 Feb 2003 13:43:07 -0500 Date: Fri, 28 Feb 2003 13:43:07 -0500 Message-Id: <200302281843.h1SIh7pZ030984@smtp6.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Andrea Campi , Mark Swanson Cc: "ietf-calendar@imc.org" In-reply-to: <200302280917.04804.mark@WebServiceSolutions.com> Subject: Re: The charset issue References: <3E5E49A6.2030102@Royer.com> <200302271415.53910.mark@WebServiceSolutions.com> <20030228112346.GA44508@inet.it> <200302280917.04804.mark@WebServiceSolutions.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Mark Swanson Date: Fri, 28 Feb 2003 09:17:04 -0500 There are the obvious examples of using an iCalendar object outside the MIME environment: http/ftp/custom protocols - even copying the iCalendar object as presented by Outlook (in text format, which does not show the MIME headers as part of the iCalendar object) to the clipboard. John Strake has stated that no MIME implementations (MUA or HTTP) include the MIME headers when it saves a MIME body-part. Of course not. They should save objects in the local charset, doing conversions if necessary. I believe a lot more examples will surface as time goes on. 2445 will likely last for decades, why not fix it now? Lastly, I believe 2445 MUST be fixed. If people do NOT agree with the CHARSET property then they MUST agree to change the wording of 2445 to something like, "the format of this memo is only applicable for use in a MIME message content type". Simply stating that an iCalendar parser must know the charset before interpreting an iCalendar object would be fine. If you want to give some guide to implementors, we can even say "Implementations may want to interpret byte sequences matching legal UTF-8 sequences as UTF-8 and all other byte sequences as their local character set." or something of the sort. Larry From owner-ietf-calendar@mail.imc.org Fri Feb 28 14:27:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09703 for ; Fri, 28 Feb 2003 14:27:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJMHA04190 for ietf-calendar-bks; Fri, 28 Feb 2003 11:22:17 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.168.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJMGY04181 for ; Fri, 28 Feb 2003 11:22:16 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 61A3A4F2E for ; Fri, 28 Feb 2003 14:21:52 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: "ietf-calendar@imc.org" Subject: Re: The charset issue Date: Fri, 28 Feb 2003 14:19:07 -0500 User-Agent: KMail/1.5 References: <3E5E49A6.2030102@Royer.com> <200302280917.04804.mark@WebServiceSolutions.com> <200302281843.h1SIh7pZ030984@smtp6.andrew.cmu.edu> In-Reply-To: <200302281843.h1SIh7pZ030984@smtp6.andrew.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302281419.07923.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > There are the obvious examples of using an iCalendar object outside > the MIME environment: http/ftp/custom protocols - even copying the > iCalendar object as presented by Outlook (in text format, which > does not show the MIME headers as part of the iCalendar object) to > the clipboard. John Strake has stated that no MIME implementations > (MUA or HTTP) include the MIME headers when it saves a MIME > body-part. > > Of course not. They should save objects in the local charset, doing > conversions if necessary. This is impossible because you can not always convert to the local character set (F.E. UTF-8 -> 8859-1). > I believe a lot more examples will surface as time goes on. 2445 > will likely last for decades, why not fix it now? > > Lastly, I believe 2445 MUST be fixed. If people do NOT agree with > the CHARSET property then they MUST agree to change the wording of > 2445 to something like, "the format of this memo is only applicable > for use in a MIME message content type". > > Simply stating that an iCalendar parser must know the charset before > interpreting an iCalendar object would be fine. If you want to give You are basically stating my solution, which is basically: an ICalendar parser must know the charset before interpreting an iCalendar object because of the existence of a CHARSET property. > some guide to implementors, we can even say "Implementations may want > to interpret byte sequences matching legal UTF-8 sequences as UTF-8 > and all other byte sequences as their local character set." or > something of the sort. No. This ignores the fact that the local character set may not be able to represent the encoded iCalendar characters. -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ Java Web Start: http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp From owner-ietf-calendar@mail.imc.org Fri Feb 28 15:02:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11031 for ; Fri, 28 Feb 2003 15:02:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SJpcD06741 for ietf-calendar-bks; Fri, 28 Feb 2003 11:51:38 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SJpbY06737 for ; Fri, 28 Feb 2003 11:51:37 -0800 (PST) In-Reply-To: <3E5A6B4B.9080901@Royer.com> To: ietf-calendar@imc.org Subject: Re: Proposed changed GET-CAPABILITY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 28 Feb 2003 14:51:35 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/28/2003 02:51:40 PM, Serialize complete at 02/28/2003 02:51:40 PM Content-Type: multipart/alternative; boundary="=_alternative 006CEA8185256CDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CEA8185256CDB_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 02/24/2003 01:58:19 PM: > > 1: It should not require any great number of cycles for any > > implementation to actually implement and perform compared to most other > > commands. > > I don't follow (not that I agree or disagree). The text as of the Jan-2003 draft was that it was optional for CUAs to implement and the argument by some was that it was for performance reasons. The GET-CAPABILITY command should be very quick to perform compared to something like the SEARCH command or GENERATE-UIDs. The command should not take tons of time to perform either so bounded latency should not be an issue here. In the interest of simplifying the command I suggested that we remove bounded latency from it as well. > > 2: It needs to be done before any other commands are done and once done > > does not need to be performed again (after authentication that is). > > Not true it says (And has said for a while): > > 10.3 ... > > The "GET-CAPABILITY" command returns information about the Calendar > other end of the session given the current state of the connection. > The values returned may differ depending on current user identify and > the security level of the connection. > > So the values reutured AFTER authentication and INDENTIFY might > be more or less restrictive than before authentication and change > of identity. That citation does NOT require or strongly suggest that GET-CAPABILITY be performed both before and certainly after authentication. Nor does it say that GET-CAPABILITY SHOULD be performed before other commands like DELETE or SEARCH. I was trying to tighten up the design so that it really SHOULD be done before ANY other commands (except perhaps IDENTIFY). The real changes though were to the lead in text of the command and so far I dont see any complaints about that (since we already all agreed in principal to them). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006CEA8185256CDB_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 02/24/2003 01:58:19 PM:
> > 1: It should not require any great number of cycles for any
> > implementation to actually implement and perform compared to most other
> > commands.
>
> I don't follow (not that I agree or disagree).
The text as of the Jan-2003 draft was that it was optional for CUAs to implement and the argument by some was that it was for performance reasons.  

The GET-CAPABILITY command should be very quick to perform compared to something like the SEARCH command or GENERATE-UIDs.  The command should not take tons of time to perform either so bounded latency should not be an issue here.  In the interest of simplifying the command I suggested that we remove bounded latency from it as well.

> > 2: It needs to be done before any other commands are done and once done
> > does not need to be performed again (after authentication that is).
>
> Not true it says (And has said for a while):
>
> 10.3 ...
>
>     The "GET-CAPABILITY" command returns information about the Calendar
>     other end of the session given the current state of the connection.
>     The values returned may differ depending on current user identify and
>     the security level of the connection.
>
> So the values reutured AFTER authentication and INDENTIFY might
> be more or less restrictive than before authentication and change
> of identity.
That citation does NOT require or strongly suggest that GET-CAPABILITY be performed both before and certainly after authentication.   Nor does it say that GET-CAPABILITY SHOULD be performed before other commands like DELETE or SEARCH.  

I was trying to tighten up the design so that it really SHOULD be done before ANY other commands (except perhaps IDENTIFY).  The real changes though were to the lead in text of the command and so far I dont see any complaints about that (since we already all agreed in principal to them).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006CEA8185256CDB_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 28 15:37:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12531 for ; Fri, 28 Feb 2003 15:37:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SKTqY08098 for ietf-calendar-bks; Fri, 28 Feb 2003 12:29:52 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SKTpY08094 for ; Fri, 28 Feb 2003 12:29:51 -0800 (PST) In-Reply-To: <20030225100754.GA35811@inet.it> To: ietf-calendar@imc.org Subject: Re: Proposed changed GET-CAPABILITY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 28 Feb 2003 15:29:51 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0.1NP|February 04, 2003) at 02/28/2003 03:29:52 PM, Serialize complete at 02/28/2003 03:29:52 PM Content-Type: multipart/alternative; boundary="=_alternative 00706B3785256CDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00706B3785256CDB_= Content-Type: text/plain; charset="US-ASCII" Andrea Campi wrote on 02/25/2003 05:07:54 AM: > > A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial > > connection. Another "GET-CAPABILITY" command subsequent to successful > > authentiation MAY be useful in case the CS alters the options allowed > > based on the authentication credentials provided. > > I'm not sure I follow you here. We don't have a CAP (application-layer) > authentication phase, rather, we rely on SASL as mandated by BEEP. So > basically this means, when a channel is established and the peers are > able to exchange commands, authentication has already occurred in all > cases (even if the peer is anonymous). > You are thinking of INDENTIFY, right? so the sentence above is still > relevant but should probably be reworded as: > > A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial > connection. Another "GET-CAPABILITY" command subsequent to a change of > credentials MAY be useful in case the CS alters the options allowed > based on the authorization credentials provided. This may happen when > an IDENTIFY command is sent. I used that text pretty much as is from the Jan 2003 draft but I did juggle some bits from later in the section. I combined: A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. and the bit under "Response" that says: The "GET-CAPABILITY" command returns information about the Calendar other end of the session given the current state of the connection. The values returned may differ depending on current user identify and the security level of the connection. into the block you questioned. Since there is no credentials on the intiail connection Im not sure your phrasing is accurate. However I think we all agree on the intent: the values returned in response to GET-CAPABILITIY MAY change based on the "authentication credentials" (See Section 4.1. Calendar User and UPNs of the 12-Jan-2003 draft) in effect when the command is issued. I leave it to Dougs wordsmithing skills to hone this text as necessary (assuming its not already covered in the latest 17-Feb-2003 draft). > > The CS MUST send a "GET-CAPABILITY" command to a CUA after the initial > > connection. Multiple "GET-CAPABILITY" commands to the CUA SHOULD NOT be > > necessary. > > Now that I look at this more closely: you still explicitely identify > exchanges as going from the CUA to the CS or from the CS to the CUA. Is > this right? I thought what you had in mind was more like: > > A CUA MUST send a "GET-CAPABILITY" command after the initial ... > > The CS MUST send a "GET-CAPABILITY" command after the initial Mea culpa. I did not change all references and remove them. I did this because A) we do not yet have the context of CS<->CS over CAP (at least the WG isnt focused on it) and B) in the current CUA<->CS context we have no way to distinguish a CUA from a CS on an end point. As such I couldn't easily remove all references to CUA or CS in the lead in "Purpose" area. I did however clean it from the response property blocks. > > MULTIPART 1 A comma separated list of lower cased MIME > > multipart subtypes that the sender supports. > > If multipart is not supported then the property > > has no value (ie: an empty list). Example: > > MULTIPART:related,alternate > > How would an empty list appear? > > MULTIPART: > > Is this even allowed by the ABNF? Should we use an explicit `none' instead? I only changed this bit very minorly from the original: MULTIPART 1 A comma separated list of MIME multipart the sender supports in lower case. The default is no multipart support (empty list). Example: MULTIPART:related,alternate to be consistant w/my other prose format. If you look at the ABNF for 2445, you will see that an empty value is 100% legal for type text (which is what the comma separated list is here): text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) The * Rule is defined in RFC 2234 as: 3.6 Variable Repetition *Rule The operator "*" preceding an element indicates repetition. The full form is: *element where and are optional decimal values, indicating at least and at most occurrences of element. Default values are 0 and infinity so that * allows any number, including zero; 1* requires at least one; 3*3 allows exactly 3 and 1*2 allows one or two. Therefore any property of type TEXT can have an empty value legally. Your MULTIPART example is therefore accurate. By the way, this is how you can get NULL properties as described in the iTIP restriction tables ("Can be NULL"). > > RECUR-ACCEPTED 1 A boolean value to indicate whether recurrence > > rules are acceptable. > > You have this twice. Sorry, it was that way in the original 12Jan2003 draft and I didnt notice it. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00706B3785256CDB_= Content-Type: text/html; charset="US-ASCII"
Andrea Campi <a.campi@inet.it> wrote on 02/25/2003 05:07:54 AM:
> > A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial
> > connection.  Another "GET-CAPABILITY" command subsequent to successful
> > authentiation MAY be useful in case the CS alters the options allowed
> > based on the authentication credentials provided.
>
> I'm not sure I follow you here. We don't have a CAP (application-layer)
> authentication phase, rather, we rely on SASL as mandated by BEEP. So
> basically this means, when a channel is established and the peers are
> able to exchange commands, authentication has already occurred in all
> cases (even if the peer is anonymous).
> You are thinking of INDENTIFY, right? so the sentence above is still
> relevant but should probably be reworded as:
>
>   A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial
>   connection.  Another "GET-CAPABILITY" command subsequent to a change of
>   credentials MAY be useful in case the CS alters the options allowed
>   based on the authorization credentials provided. This may happen when
>   an IDENTIFY command is sent.
I used that text pretty much as is from the Jan 2003 draft but I did juggle some bits from later in the section.  I combined:

A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection.

and the bit under "Response" that says:

The "GET-CAPABILITY" command returns information about the Calendar other end of the session given the current state of the connection. The values returned may differ depending on current user identify and the security level of the connection.

into the block you questioned.   Since there is no credentials on the intiail connection Im not sure your phrasing is accurate.  

However I think we all agree on the intent: the values returned in response to GET-CAPABILITIY MAY change based on the "authentication credentials" (See Section 4.1. Calendar User and UPNs of the 12-Jan-2003 draft) in effect when the command is issued.  I leave it to Dougs wordsmithing skills to hone this text as necessary (assuming its not already covered in the latest 17-Feb-2003 draft).

> > The CS MUST send a "GET-CAPABILITY" command to a CUA after the initial
> > connection.  Multiple "GET-CAPABILITY" commands to the CUA SHOULD NOT be
> > necessary.
>
> Now that I look at this more closely: you still explicitely identify
> exchanges as going from the CUA to the CS or from the CS to the CUA. Is
> this right? I thought what you had in mind was more like:
>
>   A CUA MUST send a "GET-CAPABILITY" command after the initial  ...
>
>   The CS MUST send a "GET-CAPABILITY" command after the initial

Mea culpa.  I did not change all references and remove them.  I did this because A) we do not yet have the context of CS<->CS over CAP (at least the WG isnt focused on it) and B) in the current CUA<->CS context we have no way to distinguish a CUA from a CS on an end point.  As such I couldn't easily remove all references to CUA or CS in the lead in "Purpose" area.  I did however clean it from the response property blocks.

> >    MULTIPART         1     A comma separated list of lower cased MIME
> >                            multipart subtypes that the sender supports.
> >                            If multipart is not supported then the property
> >                            has no value (ie: an empty list). Example:
> >                            MULTIPART:related,alternate
>
> How would an empty list appear?
>
> MULTIPART:
>
> Is this even allowed by the ABNF? Should we use an explicit `none' instead?
I only changed this bit very minorly from the original:

   MULTIPART         1     A comma separated list of MIME multipart
                          the sender supports in lower case. The
                          default is no multipart support (empty
                          list). Example: MULTIPART:related,alternate
to be consistant w/my other prose format.  If you look at the ABNF for 2445, you will see that an empty value is 100% legal for type text (which is what the comma separated list is here):

     text       = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)

The * Rule is defined in RFC 2234 as:

3.6  Variable Repetition                                *Rule

  The operator "*" preceding an element indicates repetition. The full
  form is:

       <a>*<b>element

  where <a> and <b> are optional decimal values, indicating at least
  <a> and at most <b> occurrences of element.

  Default values are 0 and infinity so that *<element> allows any
  number, including zero; 1*<element> requires at  least  one;
  3*3<element> allows exactly 3 and 1*2<element> allows one or two.
Therefore any property of type TEXT can have an empty value legally.  Your MULTIPART example is therefore accurate.  By the way, this is how you can get NULL properties as described in the iTIP restriction tables ("Can be NULL").

> >    RECUR-ACCEPTED    1     A boolean value to indicate whether recurrence
> >                            rules are acceptable.
>
> You have this twice.
Sorry, it was that way in the original 12Jan2003 draft and I didnt notice it.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00706B3785256CDB_=-- From owner-ietf-calendar@mail.imc.org Fri Feb 28 19:34:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18338 for ; Fri, 28 Feb 2003 19:34:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h210OaJ17139 for ietf-calendar-bks; Fri, 28 Feb 2003 16:24:36 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h210OZY17133 for ; Fri, 28 Feb 2003 16:24:35 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h210OWb2000836 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 28 Feb 2003 16:24:36 -0800 Message-ID: <3E5FFDBA.3000703@Royer.com> Date: Fri, 28 Feb 2003 17:24:26 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Push of CAP to ietf Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010805080304070106090100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010805080304070106090100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I am sending the 17-FEB-2003 version + some changes to the IETF list tonight. I know there are some issues still, but by sending it to the IETF it can be discussed in S.F. I'll post a URL to the diffs. - -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010805080304070106090100 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDEwMDI0MjZaMCMGCSqGSIb3DQEJBDEWBBTC U1LbLTjZ3LbBGP4hlF6A8Z2q3DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEApNYubIiSs4V7 Jm+qqieSFVNS+b+zpav87+zyefbqziH1TT5JZpbz+pt+BQXuGuwSxCdb7Kmr+oSCKge6aMzJ 9zgXi8Cgx6FmBkgK+1oaYJvPN1hOyoH+tHVg3B50qFzu21HtZUdW7xjr02I1f9Xb4BZX7aFF lLerQOHTqNmNl3NmhOoCmiG+lD3pRk6BjdrsF4o2ythPhUeMblKD0XSPJ2rCLWkRF1/jCD9+ 3WAh0AKOZ6ieckeiXwf3pIOYDqxyFMm/vRzalhnhbgCM9/O6aNf6Z0V621n0I1cQu8bGqsOn 0riWIc7IIBFepohqKTBrHIt+yeyXlfUbgG1uEWmeOwAAAAAAAA== --------------ms010805080304070106090100-- From owner-ietf-calendar@mail.imc.org Fri Feb 28 19:54:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18840 for ; Fri, 28 Feb 2003 19:54:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h210nSb17807 for ietf-calendar-bks; Fri, 28 Feb 2003 16:49:28 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h210nRY17803 for ; Fri, 28 Feb 2003 16:49:27 -0800 (PST) Received: from Royer.com (inet-products.com [12.110.12.238]) by royer.com (8.12.2/8.12.2) with ESMTP id h210nQb2001114 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 28 Feb 2003 16:49:29 -0800 Message-ID: <3E600391.5090707@Royer.com> Date: Fri, 28 Feb 2003 17:49:21 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: draft-ietf-calsch-cap-10 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050705030006020704050403" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050705030006020704050403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have submitted draft-ietf-calsch-cap-10 (the deadline is tomorrow). I placed copies at: http://INET-Consulting.com/draft-ietf-calsch-cap-10.txt http://INET-Consulting.com/draft-ietf-calsch-cap-10.html http://INET-Consulting.com/draft-ietf-calsch-cap-10.xml The difference between cap-17-FEB-2003.txt and what was submitted today: http://INET-Consulting.com/draft-ietf-calsch-cap-10.17-FEB.diff The difference between draft-ietf-calsch-cap-09.txt and what was submitted today: http://INET-Consulting.com/draft-ietf-calsch-cap-10.cap-09.diff -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050705030006020704050403 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSDCC A2YwggLPoAMCAQICEA2LT+6q0hhb9HVqnSnhf/swDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbQwgbEwEQYJYIZIAYb4QgEBBAQDAgEGMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL3BjYTEuMS4xLmNybDBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEB MC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwDwYDVR0T BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAQnwO34x5TKy/COxN VS9QiaDFXk4uXpUym3mtZRELHEpSxNWoMSGO3hCbbAjFB+YDuefINHgJCfK8BkL4WoyD0Yre qiL12eMh0s9ljAYzsM0gsjPNCr0+4Z3BNalksKelJFvp8WjrE8R8N/SUZA2axb0zF++DM6A+ 5ao+rthzH60wggTrMIIEVKADAgECAhAejFNQR/pY9ailMryViTyhMA0GCSqGSIb3DQEBBAUA MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkx ODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNz IDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkq hkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv43FbjoxKdvfMSpimkqD5mOFrqU34 1TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2YlebpkqpRiBMF+rtoNpX4SSBtZwGA gCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jPD7x876t4BohIOJI1figvqXmSwfWK YrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn0W6r37zHFCnc0bm9xfxjbw4LunXd SaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgKbpWFSSSpJGUWmQIDAQABo4IBBjCC AQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdkOPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq 1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiWyFDnFIqKJoHmHPNXBn0dXYlje5p2 TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIwggTrMIIEVKADAgECAhAejFNQR/pY9ail MryViTyhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNv bS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UE AxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBO b3QgVmFsaWRhdGVkMB4XDTAyMDkxODAwMDAwMFoXDTAzMDkxODIzNTk1OVowggELMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJl Zi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYD VQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNV BAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdAcm95ZXIuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwxBHUCJd14lkzkJJKSLcpUSNqym8VYNSM5HEKWdv 43FbjoxKdvfMSpimkqD5mOFrqU341TL6G3I/KkvQ9TzGWprYryi/qJveMah6Pz7HPQOe4m2Y lebpkqpRiBMF+rtoNpX4SSBtZwGAgCLaQSV7jA6QyAiEv5/QPYY5KcA9N3I4PemEoC5kS1jP D7x876t4BohIOJI1figvqXmSwfWKYrhBcd/tXNk68VpOqUOZSuSrn+RHHKEuIS2eOj285IAn 0W6r37zHFCnc0bm9xfxjbw4LunXdSaudrVa5UdYSxkTgxF4WgXwh3JfZM8ioRCVESN3DpsgK bpWFSSSpJGUWmQIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtg hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQ UzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BT IGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZI AYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAoIZ4BrBjrJxUvZW7bAmWyHrGWv+oBfdk OPGBvbbcEmJ1bBz0tT3Iy8Ri+YEq1sTdRlTWp1XTKo8/hfCudzbRqUN2CNcojkBAy0zH3hiW yFDnFIqKJoHmHPNXBn0dXYlje5p2TRbl2WbW/hvpM1DstHIhyOB5WadIC14xmrS66eIxggO1 MIIDsQIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRl ZAIQHoxTUEf6WPWopTK8lYk8oTAJBgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMDEwMDQ5MjFaMCMGCSqGSIb3DQEJBDEWBBTx 0JkGxkmOSZRluvc9idJus7Ny4zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB9AYL KoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEBBQAEggEAcBWifqkDcmMM 0Nu+P/6hyEmd+3k631W9iw0wRtt47jFSY4cJBIZ2Nt1CZVtXvmj+Gywg/Xul2bXcwYQCLVTP E/V8gbVgdK57PUu7yAETtJ6EkwRLIuFxci/XX1n2KPYowotiwEek7xZxpJMuvXPk8FPKohr7 9Z3tiHENqE8vOjyIfd3OXgt5xi54/t38zUxIg7QJQTrDobEhfqRTDWwQtQyxtdBJnwD/s1WS /ykTv1NdMQNRoO6eTZBD66LM+99ykobyGtUILi29aSWnpb4D04NbaroEg74oQPTGZIXci8zm qOkhsSEnRTzwg2vZRvrSRrrkyqfB0YjgqQChfR7WbwAAAAAAAA== --------------ms050705030006020704050403--