From owner-ietf-calendar@mail.imc.org Mon Jun 3 13:22:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24668 for ; Mon, 3 Jun 2002 13:22:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53H52Z08319 for ietf-calendar-bks; Mon, 3 Jun 2002 10:05:02 -0700 (PDT) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53H50g08315 for ; Mon, 3 Jun 2002 10:05:01 -0700 (PDT) Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g53H5Fc06037 for ; Mon, 3 Jun 2002 10:05:15 -0700 (PDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail1.oracle.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g53H5EX06021 for ; Mon, 3 Jun 2002 10:05:14 -0700 (PDT) Received: from oracle.com (insn049a.idc.oracle.com [152.69.168.49]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g53H4rF22625; Mon, 3 Jun 2002 11:04:54 -0600 (MDT) Message-ID: <3CFBEFDB.8905AE1F@oracle.com> Date: Mon, 03 Jun 2002 22:38:19 +0000 From: suchet singh khalsa Reply-To: Suchet Singh Khalsa X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en, fr MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: To show Busy OR not to show Busy Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit  
Hi All,
     I have joined late in the game... So answers needed for some fundamental questions. Any help will be greatly appreciated.

(I have formatted my questions in HTML Table. Hope it does not get garbled...)
 
Sr. No. Reference Background for the Question Q. No. Question
1. iTIP / FreeBusy Mary has REQUESTed a vevent with Tom as attendee. The REQUESTed vevent has STATUS set to CONFIRMED.
Another Calendar User Bill wants to see FreeBusy of Mary and Tom for the period of Mary's meeting.		 1. Should Mary be shown to be BUSY as she is the ORGANIZER and she is by default expected to attend the meeting? 
(Assume that she has not set role to non-participant)
2. Case 1: PartStat for Tom is still NEEDS-ACTION:
Should Tom be shown to be BUSY ?
3. Case 2: PartStat for Tom is DECLINED:
Should Mary be shown BUSY now or since all attendees have declined to attend, she should be shown FREE?
2. iTIP / FreeBusy Mary has REQUESTed a vevent with Tom as attendee. The REQUESTed vevent has STATUS set to TENTATIVE.
Another Calendar User Bill wants to see FreeBusy of Mary and Tom for the period of Mary's meeting.		 1. Should Mary be shown to be BUSY even though she has created the vevent with status TENTATIVE ?
2. If PartStat for Tom is NEEDS-ACTION should he be shown BUSY ?
3. iTIP / REPLY, CANCEL Restriction Table for these methods allows 0+ occurrences of the following properties:
RRULE , RDATE, EXRULE, EXDATE,
CONTACT, ATTACH,
RELATED-TO		 1. What significance do these properties have in the MIME object having these methods ?

Is it that the RRULE received in REPLY method should be interpreted like this :  if attendee is ACCEPTing then he means to ACCEPT only for those instances determined by the RRULE in the REPLY ?
2. I cannot make sense of an ATTACH property in a MIME object with method REPLY or CANCEL.
Similarly for the properties CONTACT and RELATED-TO.
4. CAP / VCAR There are 2 VCARs defined with TARGET as calendar id "CAL-PARENT".

There are 3 VCARs defined with TARGET as calendar id "CAL-CHILD".

The Calendar "CAL-CHILD" is contained in the calendar "CAL-PARENT"

The word "calendar" in the above three statements means VAGENDA as defined by CAP.

 1. Whenever any operation is to be done on the calendar "CAL-CHILD" should the VCARs defined on calendar "CAL-PARENT" also be considered ?
2. For e.g.: A REQUEST is received for a vevent with TARGET as "CAL-CHILD". This operation does not violate any VCARs defined on "CAL-CHILD" but one of the VCARs defined on "CAL-PARENT" is violated. Should this operation be allowed or not ?

Thanks in advance,
Suchet Singh Khalsa
Oracle Corporation

Disclaimer : The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation.
 
 
 
 
 
 
 
 
 
  From owner-ietf-calendar@mail.imc.org Mon Jun 3 14:06:17 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25828 for ; Mon, 3 Jun 2002 14:06:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53HwmI10031 for ietf-calendar-bks; Mon, 3 Jun 2002 10:58:48 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Hwkg10022 for ; Mon, 3 Jun 2002 10:58:46 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g53HwjQX011689 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 3 Jun 2002 10:58:48 -0700 Message-ID: <3CFBADAC.8423DC2A@Royer.com> Date: Mon, 03 Jun 2002 11:55:56 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: INET-Consulting X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: To show Busy OR not to show Busy References: <3CFBEFDB.8905AE1F@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms80B0713248FF5C822F2F0BF6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms80B0713248FF5C822F2F0BF6 Content-Type: multipart/mixed; boundary="------------97E019F17C510D42A564E923" This is a multi-part message in MIME format. --------------97E019F17C510D42A564E923 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit suchet singh khalsa wrote: > > > Hi All, > I have joined late in the game... So answers needed for some > fundamental questions. Any help will be greatly appreciated. > > (I have formatted my questions in HTML Table. Hope it does not get > garbled...) HTML is not a good thing to send to most (all?) ietf lists. (1-2): Busy time is determined by the attendee, not the iTIP object. I could have the same entries in my calendar - and not plan to attend. So I would not mark them as busy time. (3): [I am not sure which table your are referring to here and in which draft. iTIP? CAP?] I think this may help: Your can CANCEL instances of an object. So they would exist in the object when an instance or specific instances are being canceled / acknowledges / ... (4): No and No. There is no VCAR inheritance. Each calendar is independent. The only exception being that they can not violate any decreed VCARs. --------------97E019F17C510D42A564E923 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;-29152 fn:Doug Royer end:vcard --------------97E019F17C510D42A564E923-- --------------ms80B0713248FF5C822F2F0BF6 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MDMxNzU1NTlaMCMGCSqGSIb3DQEJ BDEWBBTpLcA9UtxoYmAc0AGCZwKUxPHR4jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgKrVr6JDmj7fcz3GlMtiRGAar/wQiV017qmDm0XOeF987dJ+ zu5yCb5LaUdGXVzZv92/jPwP2kh5+RhoJK5zKMTe1NgwSe0u5pogWU7VGt2gm4C3RWiyWOGl mUEqppBHgf6JsbTe2tFBB8lrNwWRenC8xI13MFpwbjo6712dcEY3 --------------ms80B0713248FF5C822F2F0BF6-- From owner-ietf-calendar@mail.imc.org Mon Jun 3 14:15:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26081 for ; Mon, 3 Jun 2002 14:15:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53I8f810471 for ietf-calendar-bks; Mon, 3 Jun 2002 11:08:41 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53I8dg10467 for ; Mon, 3 Jun 2002 11:08:39 -0700 (PDT) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id g53I8Z614075 for ; Mon, 3 Jun 2002 11:08:35 -0700 (PDT) Received: from netscape.com ([10.169.59.204]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GX56EB00.LFT; Mon, 3 Jun 2002 11:08:35 -0700 Message-ID: <3CFBB023.A2787FFD@netscape.com> Date: Mon, 03 Jun 2002 11:06:27 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Suchet Singh Khalsa CC: CalSched IETF Subject: Re: To show Busy OR not to show Busy References: <3CFBEFDB.8905AE1F@oracle.com> Content-Type: multipart/mixed; boundary="------------51D5F2AD2AC64C7D4FD3A887" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------51D5F2AD2AC64C7D4FD3A887 Content-Type: multipart/alternative; boundary="------------85F474ACBF50A5D9507EC988" --------------85F474ACBF50A5D9507EC988 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's my opinion: Sr. No. 1 1. Mary should be shown as busy 2. Tom should be shown as busy 3. Mary should be shown as busy, Tom should be shown as free Sr. No. 2 1. Mary should be shown as busy 2. Tom should be shown as busy Sr. No 3 1. In the case you describe, I think the REPLY would apply only to those instances called out in the RRULE(s). 2. We believe them to be harmless. Do you see a reason that should cause us to preclude them from the reply? I'll respond to the CAP questions later. -Steve suchet singh khalsa wrote: > > Hi All, > I have joined late in the game... So answers needed for some > fundamental questions. Any help will be greatly appreciated. > > (I have formatted my questions in HTML Table. Hope it does not get > garbled...) > > Sr. Background for Q. No. Reference the Question No. Question Mary has REQUESTed a vevent with Tom as attendee. The Should Mary be REQUESTed shown to be BUSY as vevent has she is the STATUS set to ORGANIZER and she 1. iTIP / CONFIRMED. 1. is by default FreeBusy Another expected to attend Calendar User the meeting? Bill wants to (Assume that she see FreeBusy has not set role to of Mary and non-participant) Tom for the period of Mary's meeting. Case 1: PartStat for Tom is still 2. NEEDS-ACTION: Should Tom be shown to be BUSY ? Case 2: PartStat for Tom is DECLINED: Should Mary be 3. shown BUSY now or since all attendees have declined to attend, she should be shown FREE? Mary has REQUESTed a vevent with Tom as attendee. The REQUESTed vevent has Should Mary be STATUS set to shown to be BUSY 2. iTIP / TENTATIVE. 1. even though she has FreeBusy Another created the vevent Calendar User with status Bill wants to TENTATIVE ? see FreeBusy of Mary and Tom for the period of Mary's meeting. If PartStat for Tom 2. is NEEDS-ACTION should he be shown BUSY ? What significance do these properties Restriction have in the MIME Table for object having these these methods methods ? allows 0+ occurrences of Is it that the iTIP / the following RRULE received in 3. REPLY, properties: 1. REPLY method should CANCEL RRULE , RDATE, be interpreted like EXRULE, this : if attendee EXDATE, is ACCEPTing then CONTACT, he means to ACCEPT ATTACH, only for those RELATED-TO instances determined by the RRULE in the REPLY ? I cannot make sense of an ATTACH property in a MIME 2. object with method REPLY or CANCEL. Similarly for the properties CONTACT and RELATED-TO. There are 2 VCARs defined with TARGET as calendar id "CAL-PARENT". There are 3 VCARs defined with TARGET as calendar id Whenever any "CAL-CHILD". operation is to be done on the calendar 4. CAP / The Calendar 1. "CAL-CHILD" should VCAR "CAL-CHILD" is contained in the VCARs defined the calendar on calendar "CAL-PARENT" "CAL-PARENT" also be considered ? The word "calendar" in the above three statements means VAGENDA as defined by CAP. For e.g.: A REQUEST is received for a vevent with TARGET as "CAL-CHILD". This operation does not violate any 2. VCARs defined on "CAL-CHILD" but one of the VCARs defined on "CAL-PARENT" is violated. Should this operation be allowed or not ? > > Thanks in advance, > Suchet Singh Khalsa > Oracle Corporation > > Disclaimer : The statements and opinions expressed here are my own and > do not necessarily represent those of Oracle Corporation. > > > > > > > > > > --------------85F474ACBF50A5D9507EC988 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Here's my opinion:

Sr. No. 1
1. Mary should be shown as busy
2. Tom should be shown as busy
3. Mary should be shown as busy, Tom should be shown as free

Sr. No. 2
1. Mary should be shown as busy
2. Tom should be shown as busy

Sr. No 3
1. In the case you describe, I think the REPLY would apply only to those instances called out in the RRULE(s).
2. We believe them to be harmless. Do you see a reason that should cause us to preclude them from the reply?

I'll respond to the CAP questions later.

-Steve

suchet singh khalsa wrote:

 
Hi All,
     I have joined late in the game... So answers needed for some fundamental questions. Any help will be greatly appreciated.

(I have formatted my questions in HTML Table. Hope it does not get garbled...)
 
Sr. No. Reference Background for the Question Q. No. Question
1. iTIP / FreeBusy Mary has REQUESTed a vevent with Tom as attendee. The REQUESTed vevent has STATUS set to CONFIRMED.
Another Calendar User Bill wants to see FreeBusy of Mary and Tom for the period of Mary's meeting.		 1. Should Mary be shown to be BUSY as she is the ORGANIZER and she is by default expected to attend the meeting? 
(Assume that she has not set role to non-participant)
2. Case 1: PartStat for Tom is still NEEDS-ACTION:
Should Tom be shown to be BUSY ?
3. Case 2: PartStat for Tom is DECLINED:
Should Mary be shown BUSY now or since all attendees have declined to attend, she should be shown FREE?
2. iTIP / FreeBusy Mary has REQUESTed a vevent with Tom as attendee. The REQUESTed vevent has STATUS set to TENTATIVE.
Another Calendar User Bill wants to see FreeBusy of Mary and Tom for the period of Mary's meeting.		 1. Should Mary be shown to be BUSY even though she has created the vevent with status TENTATIVE ?
2. If PartStat for Tom is NEEDS-ACTION should he be shown BUSY ?
3. iTIP / REPLY, CANCEL Restriction Table for these methods allows 0+ occurrences of the following properties:
RRULE , RDATE, EXRULE, EXDATE,
CONTACT, ATTACH,
RELATED-TO		 1. What significance do these properties have in the MIME object having these methods ?

Is it that the RRULE received in REPLY method should be interpreted like this :  if attendee is ACCEPTing then he means to ACCEPT only for those instances determined by the RRULE in the REPLY ?
2. I cannot make sense of an ATTACH property in a MIME object with method REPLY or CANCEL.
Similarly for the properties CONTACT and RELATED-TO.
4. CAP / VCAR There are 2 VCARs defined with TARGET as calendar id "CAL-PARENT".

There are 3 VCARs defined with TARGET as calendar id "CAL-CHILD".

The Calendar "CAL-CHILD" is contained in the calendar "CAL-PARENT"

The word "calendar" in the above three statements means VAGENDA as defined by CAP.

 1. Whenever any operation is to be done on the calendar "CAL-CHILD" should the VCARs defined on calendar "CAL-PARENT" also be considered ?
2. For e.g.: A REQUEST is received for a vevent with TARGET as "CAL-CHILD". This operation does not violate any VCARs defined on "CAL-CHILD" but one of the VCARs defined on "CAL-PARENT" is violated. Should this operation be allowed or not ?

Thanks in advance,
Suchet Singh Khalsa
Oracle Corporation

Disclaimer : The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation.
 
 
 
 
 
 
 
 
 
 

--------------85F474ACBF50A5D9507EC988-- --------------51D5F2AD2AC64C7D4FD3A887 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:650.937.3351 x-mozilla-html:FALSE org:AOL / Netscape adr:;;;;;; version:2.1 title:Director of Engineering fn:Steve Mansour end:vcard --------------51D5F2AD2AC64C7D4FD3A887-- From owner-ietf-calendar@mail.imc.org Mon Jun 3 16:44:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00412 for ; Mon, 3 Jun 2002 16:44:54 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g53Karf17019 for ietf-calendar-bks; Mon, 3 Jun 2002 13:36:53 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Kapg17014 for ; Mon, 3 Jun 2002 13:36:51 -0700 (PDT) Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id g53KalX03514 for ; Mon, 3 Jun 2002 13:36:47 -0700 (PDT) Received: from netscape.com ([10.169.59.204]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GX5D9C00.5LO; Mon, 3 Jun 2002 13:36:48 -0700 Message-ID: <3CFBD2DF.5DC70F9D@netscape.com> Date: Mon, 03 Jun 2002 13:34:39 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Royer , CalSched IETF Subject: Re: To show Busy OR not to show Busy References: <3CFBEFDB.8905AE1F@oracle.com> <3CFBB023.A2787FFD@netscape.com> <3CFBB9A0.5BB15992@Royer.com> Content-Type: multipart/mixed; boundary="------------7B833F04A8EC3509CAEEE1F7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------7B833F04A8EC3509CAEEE1F7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Royer wrote: > Steve Mansour wrote: > > > > Here's my opinion: > > > > Sr. No. 1 > > 1. Mary should be shown as busy > > 2. Tom should be shown as busy > > 3. Mary should be shown as busy, Tom should be shown as free > > > > Sr. No. 2 > > 1. Mary should be shown as busy > > 2. Tom should be shown as busy > > It's up to the CU/CUA to decide if they want there time > marked as BUSY, not the protocol. Correct? yep. that's why I indicated that it's my opinion. My take is that when a person has been requested to show up at a meeting, you should show their time as busy (that is, if you only have a choice between 'free' or 'busy'; there's no option like 'pending'). As an example, assume that I've been invited to a meeting Monday from 10:00a to 11:00a. If other people see me as busy at that time (even though I've not actually accepted the meeting) they can invite me to their meeting at some other time when I'm completely free. On the other hand, if my time on Monday from 10:00 - 11:00 was marked as free, then other people might invite me to a meeting from 10-11. I would only be able to accept one of the invitations, and I would decline the others. Similar double-bookings would be sure to happen with other attendees. I believe that the overall amount of hassle and swirl associated with getting the meeting scheduled will greatly increase if "needs action" time is shown as free rather than busy. iTIP provides capability to indicate whatever is appropriate, but not the policy. -Steve --------------7B833F04A8EC3509CAEEE1F7 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;work:650.937.3351 x-mozilla-html:FALSE org:AOL / Netscape adr:;;;;;; version:2.1 title:Director of Engineering fn:Steve Mansour end:vcard --------------7B833F04A8EC3509CAEEE1F7-- From owner-ietf-calendar@mail.imc.org Mon Jun 3 16:50:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00562 for ; Mon, 3 Jun 2002 16:50:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53KihH17221 for ietf-calendar-bks; Mon, 3 Jun 2002 13:44:43 -0700 (PDT) Received: from plexus.steltor.com (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Kigg17217 for ; Mon, 3 Jun 2002 13:44:42 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g53Kidpf012586 for ; Mon, 3 Jun 2002 16:44:39 -0400 Received: from c-1241.in.steltor.com (c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g53Kiar03471 for ; Mon, 3 Jun 2002 16:44:36 -0400 (EDT) Subject: Re: To show Busy OR not to show Busy From: Patrice Lapierre To: ietf-calendar@imc.org In-Reply-To: <3CFBEFDB.8905AE1F@oracle.com> References: <3CFBEFDB.8905AE1F@oracle.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 03 Jun 2002 16:44:13 -0400 Message-Id: <1023137053.1351.72.camel@c-1241.in.steltor.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit My opinions: Sr.No. 1 Q.No. 1) No, since Mary is not an ATTENDEE. The ORGANIZER is not by default expected to attend the meeting. Q.No. 2) No, since Tom hasn't accepted the meeting. Q.No. 3) Yes, since she is not an attendee, and not because Tom declined. Sr.No. 2 Q.No. 1) If Mary is not an attendee, then no. Q.No. 2) No, since Tom hasn't accepted the meeting. Note: Tentative intervals in you agenda should have the value "BUSY-TENTATIVE". Sr.No. 3 Q.No 1 and 2) My guess is that an almost complete component might be useful to allow a simple MUA/CUA to display information about the subject of reply/cancellation without accessing a database. For question 1) the RECURRENCE-ID should be used to identify a single instance of a recurring event (not RRULE). Sr.No. 4 VAGENDA hierarchy and VCAR inheritance were removed from CAP. Q.No. 1) No. Q.No. 2) Yes. -- Patrice On Mon, 2002-06-03 at 18:38, suchet singh khalsa wrote: Hi All, I have joined late in the game... So answers needed for some fundamental questions. Any help will be greatly appreciated. (I have formatted my questions in HTML Table. Hope it does not get garbled...) Sr. No. Reference Background for the Question Q. No. Question 1. iTIP / FreeBusy Mary has REQUESTed a vevent with Tom as attendee. The REQUESTed vevent has STATUS set to CONFIRMED. Another Calendar User Bill wants to see FreeBusy of Mary and Tom for the period of Mary's meeting. 1. Should Mary be shown to be BUSY as she is the ORGANIZER and she is by default expected to attend the meeting? (Assume that she has not set role to non-participant) 2. Case 1: PartStat for Tom is still NEEDS-ACTION: Should Tom be shown to be BUSY ? 3. Case 2: PartStat for Tom is DECLINED: Should Mary be shown BUSY now or since all attendees have declined to attend, she should be shown FREE? 2. iTIP / FreeBusy Mary has REQUESTed a vevent with Tom as attendee. The REQUESTed vevent has STATUS set to TENTATIVE. Another Calendar User Bill wants to see FreeBusy of Mary and Tom for the period of Mary's meeting. 1. Should Mary be shown to be BUSY even though she has created the vevent with status TENTATIVE ? 2. If PartStat for Tom is NEEDS-ACTION should he be shown BUSY ? 3. iTIP / REPLY, CANCEL Restriction Table for these methods allows 0+ occurrences of the following properties: RRULE , RDATE, EXRULE, EXDATE, CONTACT, ATTACH, RELATED-TO 1. What significance do these properties have in the MIME object having these methods ? Is it that the RRULE received in REPLY method should be interpreted like this : if attendee is ACCEPTing then he means to ACCEPT only for those instances determined by the RRULE in the REPLY ? 2. I cannot make sense of an ATTACH property in a MIME object with method REPLY or CANCEL. Similarly for the properties CONTACT and RELATED-TO. 4. CAP / VCAR There are 2 VCARs defined with TARGET as calendar id "CAL-PARENT". There are 3 VCARs defined with TARGET as calendar id "CAL-CHILD". The Calendar "CAL-CHILD" is contained in the calendar "CAL-PARENT" The word "calendar" in the above three statements means VAGENDA as defined by CAP. 1. Whenever any operation is to be done on the calendar "CAL-CHILD" should the VCARs defined on calendar "CAL-PARENT" also be considered ? 2. For e.g.: A REQUEST is received for a vevent with TARGET as "CAL-CHILD". This operation does not violate any VCARs defined on "CAL-CHILD" but one of the VCARs defined on "CAL-PARENT" is violated. Should this operation be allowed or not ? Thanks in advance, Suchet Singh Khalsa Oracle Corporation Disclaimer : The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. From owner-ietf-calendar@mail.imc.org Tue Jun 11 11:52:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00191 for ; Tue, 11 Jun 2002 11:52:57 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5BFfqm12176 for ietf-calendar-bks; Tue, 11 Jun 2002 08:41:52 -0700 (PDT) Received: from mail.samsungcontact.com ([195.89.159.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BFfon12169 for ; Tue, 11 Jun 2002 08:41:51 -0700 (PDT) Received: from mail.samsungcontact.com (root@localhost) by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g5BFfo615935 for ; Tue, 11 Jun 2002 16:41:51 +0100 Received: from samsungcontact.com ( 195.89.159.62) by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0) via ESMTP; Tue, 11 Jun 2002 16:41:51 +0100 (BST) Message-ID: <3D061A3E.5020703@samsungcontact.com> Date: Tue, 11 Jun 2002 16:41:50 +0100 From: Mark Davidson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: draft-07 - XML Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have read in the archives that XML has been removed since draft 07, but I am unsure about the new form of the commands. Is CAP now sending text/calendar objects directly via BEEP? If so, are there any extra properties for the commands? What format are the replies in? Particuarly for the generate-uid and get-capability commands. Thanks, Mark Davidson PS I have been reading this list for a couple of months getting up to speed. I am currently working on a calendar server. From owner-ietf-calendar@mail.imc.org Tue Jun 11 13:30:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04278 for ; Tue, 11 Jun 2002 13:30:17 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5BHO6A16600 for ietf-calendar-bks; Tue, 11 Jun 2002 10:24:06 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BHO5n16596 for ; Tue, 11 Jun 2002 10:24:05 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5BHO2pf014661 for ; Tue, 11 Jun 2002 13:24:02 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5BHO1B22865 for ; Tue, 11 Jun 2002 13:24:01 -0400 (EDT) Message-ID: <3D063326.7FFD3D16@steltor.com> Date: Tue, 11 Jun 2002 13:28:06 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: draft-07 - XML References: <3D061A3E.5020703@samsungcontact.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Davidson wrote: > > What format are the replies in? Particuarly for the generate-uid and > get-capability commands. Hi Mark, There is currently no consensus on the format of the results for these commands. My guess is that we'll have to create new components to hold the results of these commands to avoid breaking RFC 2445. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Tue Jun 11 17:39:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13863 for ; Tue, 11 Jun 2002 17:39:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5BLS5u28491 for ietf-calendar-bks; Tue, 11 Jun 2002 14:28:05 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BLS4n28487 for ; Tue, 11 Jun 2002 14:28:04 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5BLS4QX006447 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 11 Jun 2002 14:28:07 -0700 Message-ID: <3D066AA2.854D412E@Royer.com> Date: Tue, 11 Jun 2002 15:24:50 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: draft-07 - XML References: <3D061A3E.5020703@samsungcontact.com> Content-Type: multipart/mixed; boundary="------------4EC7EC8520CD7CE53C95E29E" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------4EC7EC8520CD7CE53C95E29E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Davidson wrote: > > I have read in the archives that XML has been removed since draft 07, > but I am unsure about the new form of the commands. We have not yet published all of those changes. They will look like the 05 (I think) draft with CMD and the other CAP commands inside the iCalendar objects. > Is CAP now sending text/calendar objects directly via BEEP? Yes. In fact I think that we will be able to just send all (most?) iTIP objects down 'as is' (when you don't want to do multiple parallel commands), and as they are self-defining, the CS will know what to do with them - store them in the unprocessed state. BEEP knows what MIME is, so there is no need for another wrapper. We will get send and get text/calendar MIME types. All other (non-iTIP) iCalendar objects are unique to CAP built on iCalendar. So there should be zero to minimum impact on the other RFCs in most areas. > If so, are there any extra properties for the commands? Yes. The target has been moved back into the object. And the command has been moved into the object. These are optional for iTIP objects in CAP as iTIP objects already contain that implied information in the METHOD property. All CAP objects are pure iCalendar compliant objects. The CMD property for example is not defined in RFC244[567], however it can be easily added without impacting the iCalendar "2.0" object format. We will have to add 'or iana registered' to some of the places they were lacking in 244[567], but there is no structure change so the 'VERSION' property will still be "2.0". > What format are the replies in? Particuarly for the generate-uid and > get-capability commands. In iCalendar format. Queries can come back in any iCalendar format depending on the query. It is not possible to define every possible contents for all queries. Same with generate-uid and get-capability. They will be in the same format as a query reply. No reason to invent a wrapper for each reply type - the CUA knew what it asked for, it will need to be able to know what it gets back. There will be new properties and a reply container. Nothing new that has not been discussed on this list. But perhaps not exactly the way it was discussed on this list. > Thanks, > Mark Davidson > > PS I have been reading this list for a couple of months getting up to > speed. I am currently working on a calendar server. Awesome! I have been doing some edits and expect to check in the edits so the other editors can see them by Monday of next week (apx Jun 17). Then we hope to send out a draft as soon as they double check my work for typos and errors (and as they also work it may not be a quick turn arround). I also suspect they will make more tweaks before the next push. --------------4EC7EC8520CD7CE53C95E29E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------4EC7EC8520CD7CE53C95E29E-- From owner-ietf-calendar@mail.imc.org Wed Jun 12 10:04:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28705 for ; Wed, 12 Jun 2002 10:04:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CDx7Y27748 for ietf-calendar-bks; Wed, 12 Jun 2002 06:59:07 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CDx6n27743 for ; Wed, 12 Jun 2002 06:59:06 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5CDx1pf026955 for ; Wed, 12 Jun 2002 09:59:02 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5CDx1623832 for ; Wed, 12 Jun 2002 09:59:01 -0400 (EDT) Message-ID: <3D07549A.E2038E70@steltor.com> Date: Wed, 12 Jun 2002 10:03:06 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: draft-07 - XML References: <3D061A3E.5020703@samsungcontact.com> <3D066AA2.854D412E@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > Mark Davidson wrote: > > > > Is CAP now sending text/calendar objects directly via BEEP? > > Yes. In fact I think that we will be able to just send > all (most?) iTIP objects down 'as is' (when you don't want > to do multiple parallel commands), and as they are self-defining, > the CS will know what to do with them - store them in the > unprocessed state. iTIP objects will require at a minimum the addition of a TARGET property, which is not allowed per RFC 2446. > > If so, are there any extra properties for the commands? > > Yes. The target has been moved back into the object. > And the command has been moved into the object. These > are optional for iTIP objects in CAP as iTIP objects > already contain that implied information in the METHOD property. > > All CAP objects are pure iCalendar compliant objects. > > The CMD property for example is not defined in RFC244[567], > however it can be easily added without impacting the > iCalendar "2.0" object format. > > We will have to add 'or iana registered' to some of the places > they were lacking in 244[567], but there is no structure change > so the 'VERSION' property will still be "2.0". What you are proposing here violates RFC 2445. Here's how RFC 2445 defines the VERSION property: 4.7.4 Version Property Name: VERSION Purpose: This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to interpret the iCalendar object. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be specified by an iCalendar object, but MUST only be specified once. Description: A value of "2.0" corresponds to this memo. So, basically, VERSION:2.0 means that the iCalendar object is fully compliant with RFC 2445, not that it is simply following the format specified in RFC 2445. It would seem that any change to the ABNF in RFC 2445 would require a VERSION change. > > What format are the replies in? Particuarly for the generate-uid and > > get-capability commands. > > In iCalendar format. > > Queries can come back in any iCalendar format depending on > the query. It is not possible to define every possible > contents for all queries. > > Same with generate-uid and get-capability. They will be in the same > format as a query reply. No reason to invent a wrapper for each > reply type - the CUA knew what it asked for, it will need > to be able to know what it gets back. There will be new > properties and a reply container. If this is what you mean: BEGIN:VCALENDAR VERSION:2.0 UID:uid1 UID:uid2 UID:uid3 END:VCALENDAR then you are violating RFC 2445, since an iCalendar object MUST include at least one calendar component. On the other hand, the following construct would obey RFC 2445: BEGIN:VCALENDAR PRODID:-//ACME//DesktopCalendar//EN VERSION:2.0 BEGIN:VUIDLIST UID:uid1 UID:uid2 UID:uid3 END:VUIDLIST END:VCALENDAR Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Jun 12 11:06:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00607 for ; Wed, 12 Jun 2002 11:06:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CEvS802174 for ietf-calendar-bks; Wed, 12 Jun 2002 07:57:28 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CEvRn02170 for ; Wed, 12 Jun 2002 07:57:27 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5CEvIpf027953 for ; Wed, 12 Jun 2002 10:57:18 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5CEvI600859 for ; Wed, 12 Jun 2002 10:57:18 -0400 (EDT) Message-ID: <3D076243.80B16170@steltor.com> Date: Wed, 12 Jun 2002 11:01:23 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Full proposal for current issue (i.e., Where to store METHOD info) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit It has been more than two weeks since I gave answers to the questions that, I believe, need to be addressed in order to solve the current issue, and there is no other proposal that obeys to RFC 2445 and RFC 2446, so I propose that the following text be added to the current draft, and that all the examples be changed accordingly. I volunteer to do the editing! Here are some hightlights of the proposal: - Allow us to obey to RFC 2445 and RFC 2446 by making use of additional components (as was done in draft 05). This will avoid the hassle of changing the VERSION number; - Make the model clear. Commands are sent in VCOMMAND compoents, and results returned in VRESULT components. No more commands returned as a result to a command! - The use of a VITIP component doesn't make query for iTIP objects a special case (no change required to CAP-QL); - Querying on VERSION, PRODID, METHOD as well as X-PROP in iTIP objects will be possible, yet straightforward; - The proposed model can easily be documented with ABNF (as in RFC 2445) and restriction tables (as in RFC 2446) (i.e., to assert whether a property is required, is optional and the number of times it may appear in a VCOMMAND component given the value of its CMD property). I truly believe that my proposal will allow us to move forward and to start addressing the other issues in the pipeline. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 ------------------------------------------------------------------------ X.1 Command Component Component Name: "VCOMMAND" Purpose: Provide a grouping of component properties that describe a CAP command. Format Definition: A "VCOMMAND" calendar component is defined by the following notation: commandc = "BEGIN" ":" "VCOMMAND" CRLF commandprop [ component ] ; Defined in RFC 2445 "END" ":" "VCOMMAND" CRLF commandprop = *( ; the following are REQUIRED, ; and MUST NOT occur more than once cmd / cmdid / ; the following are OPTIONAL, ; and MUST NOT occur more than once latency / destination / ; Used with CMD:MOVE uidcount / ; Used with CMD:GENERATE-UID identity / ; Used with CMD:IDENTIFY ; the following are OPTIONAL, ; and MAY occur more than once target / x-prop / iana-prop ) Description: A "VCOMMAND" calendar component is a grouping of component properties, and possibly including other calendar components, that represents a CAP command. Example: The following is an example of the "VCOMMAND" calendar component used to create a meeting in a calendar: BEGIN:VCOMMAND CMD:CREATE CMDID:abcd1234 LATENCY;ACTION=ABORT:10 TARGET:cap://cal.host.com/mary-relcalid BEGIN:VEVENT UID:20010919T103000Z-123401@host.com ORGAGNIZER:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid DTSTART:20010920T180000Z DTEND:20010920T190000Z SUMMARY:Mary invites Bob END:VEVENT END:VCOMMAND The following is an example of the "VCOMMAND" calendar component used to search for a specific meeting in a calendar: BEGIN:VCOMMAND CMD:SEARCH CMDID:abcd1235 TARGET:cap://cal.host.com/mary-relcalid BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = '20010919T103000Z-123401@host.com' END:VQUERY END:VCOMMAND ------------------------------------------------------------------------ X.2 Result Component Component Name: "VRESULT" Purpose: Provide a grouping of component properties that describe the result of a command. Format Definition: A "VRESULT" calendar component is defined by the following notation: resultc = "BEGIN" ":" "VRESULT" CRLF resultprop component ; Defined in RFC 2445 "END" ":" "VRESULT" CRLF resultprop = *( ; the following are REQUIRED, ; and MUST NOT occur more than once cmdid / request-status ; the following are OPTIONAL, ; and MAY occur more than once target / x-prop / iana-prop ) Description: A "VRESULT" calendar component is a grouping of component properties, and possibly including other calendar components, that represents the result of a CAP command. Multiple VRESULT components may be returned as a result of a single VCOMMAND (e.g., one VRESULT component for each TARGET property specified in the submitted VCOMMAND component). Example: The following is an example of the "VRESULT" calendar component return after a successful creation of a new VEVENT in a calendar: BEGIN:VRESULT CMDID:abcd1234 REQUEST-STATUS:2.0 TARGET:cap://cal.host.com/mary-relcalid BEGIN:VEVENT UID:20010919T103000Z-123401@host.com END:VEVENT END:VRESULT The following is an example of the "VRESULT" calendar component returned after a successful search command for a specific VEVENT: BEGIN:VRESULT CMDID:abcd1235 REQUEST-STATUS:2.0 TARGET:cap://cal.host.com/mary-relcalid BEGIN:VEVENT UID:20010919T103000Z-123401@host.com ORGAGNIZER:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid DTSTART:20010920T180000Z DTEND:20010920T190000Z SUMMARY:Mary invites Bob END:VEVENT END:VRESULT ------------------------------------------------------------------------ X.3 iTIP Component Component Name: "VITIP" Purpose: Provide a grouping of component properties that describe an iTIP message. Format Definition: A "VITIP" calendar component is defined by the following notation: vitipc = "BEGIN" ":" "VITIP" CRLF icalbody ; Defined in RFC 2445 "END" ":" "VITIP" CRLF Description: A "VITIP" calendar component is a grouping of component properties, and possibly including other calendar components, that represents an iTIP message. Example: The following is an example of the "VITIP" calendar component return after a successful creation of a new VEVENT in a calendar: BEGIN:VITIP VERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST BEGIN:VEVENT UID:20010919T103000Z-123401@host.com ORGAGNIZER:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid DTSTART:20010920T180000Z DTEND:20010920T190000Z SUMMARY:Mary invites Bob END:VEVENT END:VITIP ------------------------------------------------------------------------ X.4 Command Property Property Name: CMD Purpose: This property identifies the command in the VCOMMAND component. Value Type: TEXT Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property MUST be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify the command to be performed by the CUA or the CS. Format Definition: The property is defined by the following notation: cmd = "CMD" cmdparam ":" cmdvalue CRLF cmdparam = *( ";" xparam ) cmdvalue = ( "GENERATE-UID" / "GET-CAPABILITY" / "IDENTIFY" / "NOOP" / "CREATE" / "MOVE" / "DELETE" / "MODIFY" / "SEARCH" / "ABORT" / "CONTINUE" / x-name / iana-token ) Example: The following are examples of this property: CMD:CREATE CMD:MOVE ------------------------------------------------------------------------ X.5 Command Identifier Property Property Name: CMDID Purpose: This property specifies the identifier for a command calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify an identifier. Format Definition: The property is defined by the following notation: cmdid = "CMDID" cmdidparam ":" text CRLF cmdidparam = *( ";" xparam ) Example: The following is an example of this property: CMDID:abcd-123 ------------------------------------------------------------------------ X.6 Command Latency Property Property Name: LATENCY Purpose: This property specifies the maximum latency time in seconds for a CAP command. Value Type: INTEGER Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MAY be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify the maximum latency time in seconds for a CAP command. Format Definition: The property is defined by the following notation: latency = "LATENCY" latencyparam ":" integer CRLF latencyparam = *( ; the following is optional, ; but MUST NOT occur more than once ( ";" actionparam ) / ; the following is optional, ; and MAY occur more than once ( ";" xparam ) ) Example: The following are examples of this property: LATENCY:10 LATENCY;ACTION=ASK:5 ------------------------------------------------------------------------ X.7 Action Parameter Parameter Name: ACTION Purpose: To specify the action that should be taken when the maximum latency time is exceeded. Format Definition: The property parameter is defined by the following notation: actionparam = "ACTION" "=" ( "ABORT" / "ASK" / x-name / iana-token ) Description: This parameter can be specified on the "LATENCY" property. The parameter specifies whether a command should be aborted when the maximum latency time is exceed or if the remote peer (e.g., CUA) should be prompted to find out if the command should be continued or aborted. ------------------------------------------------------------------------ X.8 Destination Property Property Name: DESTINATION Purpose: This property specifies the address of a calendar to which components should be moved. Value Type: CAL-ADDRESS Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MAY be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify the address of a calendar to which components should be moved as a result of a MOVE command. Format Definition: The property is defined by the following notation: destination = "DESTINATION" destinationparam ":" integer CRLF destinationparam = *( ";" xparam ) Example: The following is an example of this property: DESTINATION:cap://cal.host.com/mary-relcalid ------------------------------------------------------------------------ X.9 Unique Identifier Count Property Property Name: UIDCOUNT Purpose: This property specifies the number of UID properties requested as part of a GENERATE-UID command. Value Type: INTEGER Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MAY be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify the number of UID properties that must be returned as a result of a GENERATE-UID command. Format Definition: The property is defined by the following notation: uidcount = "UIDCOUNT" uidcountparam ":" integer CRLF uidcountparam = *( ";" xparam ) Example: The following is an example of this property: UIDCOUNT:42 ------------------------------------------------------------------------ X.10 Identity Property Property Name: IDENTITY Purpose: This property specifies a new identity for a CAP session. Value Type: UPN Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MAY be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify a new identity for a CAP session. Format Definition: The property is defined by the following notation: identity = "IDENTITY" identityparam ":" upn CRLF identityparam = *( ";" xparam ) Example: The following are examples of this property: IDENTITY:bill@cal.example.com IDENTITY:@ ------------------------------------------------------------------------ From owner-ietf-calendar@mail.imc.org Wed Jun 12 11:22:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01146 for ; Wed, 12 Jun 2002 11:22:54 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5CFDvZ02738 for ietf-calendar-bks; Wed, 12 Jun 2002 08:13:57 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CFDun02734 for ; Wed, 12 Jun 2002 08:13:56 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5CFDtQX013345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 12 Jun 2002 08:13:57 -0700 Message-ID: <3D076468.E7D0985D@Royer.com> Date: Wed, 12 Jun 2002 09:10:32 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: draft-07 - XML References: <3D061A3E.5020703@samsungcontact.com> <3D066AA2.854D412E@Royer.com> <3D07549A.E2038E70@steltor.com> Content-Type: multipart/mixed; boundary="------------3F83C5D289347B2F1C6BE61D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------3F83C5D289347B2F1C6BE61D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > We will have to add 'or iana registered' to some of the places > > they were lacking in 244[567], but there is no structure change > > so the 'VERSION' property will still be "2.0". After this I will ignore ALL of these three points. WE ARE ALLOWED TO CHANGE THINGS - AND IT IS IN OUR CHARTER. WE ARE ALLOWED TO ADD THINGS. VERSION 2.0 REFERS TO THE FORMAT, NOT THE CONTENT. To anyone interested, look to the archives and you will see that the chairs have issues statments with regard to the above three facts. These are closed issues. --------------3F83C5D289347B2F1C6BE61D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------3F83C5D289347B2F1C6BE61D-- From owner-ietf-calendar@mail.imc.org Wed Jun 12 13:44:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06581 for ; Wed, 12 Jun 2002 13:44:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CHVk411642 for ietf-calendar-bks; Wed, 12 Jun 2002 10:31:46 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CHVfn11630 for ; Wed, 12 Jun 2002 10:31:42 -0700 (PDT) To: Bernard Desruisseaux Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Full proposal for current issue (i.e., Where to store METHOD info) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 12 Jun 2002 13:31:37 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/12/2002 01:31:44 PM, Serialize complete at 06/12/2002 01:31:44 PM Content-Type: multipart/alternative; boundary="=_alternative 006047B585256BD6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006047B585256BD6_= Content-Type: text/plain; charset="us-ascii" Bernard, I thought there were some major issues with Version 05. Will putting these comments back in bring back those issues? Bernard Desruisseaux Sent by: owner-ietf-calendar@mail.imc.org 06/12/02 11:01 To: ietf-calendar@imc.org cc: Subject: Full proposal for current issue (i.e., Where to store METHOD info) It has been more than two weeks since I gave answers to the questions that, I believe, need to be addressed in order to solve the current issue, and there is no other proposal that obeys to RFC 2445 and RFC 2446, so I propose that the following text be added to the current draft, and that all the examples be changed accordingly. I volunteer to do the editing! Here are some hightlights of the proposal: - Allow us to obey to RFC 2445 and RFC 2446 by making use of additional components (as was done in draft 05). This will avoid the hassle of changing the VERSION number; - Make the model clear. Commands are sent in VCOMMAND compoents, and results returned in VRESULT components. No more commands returned as a result to a command! - The use of a VITIP component doesn't make query for iTIP objects a special case (no change required to CAP-QL); - Querying on VERSION, PRODID, METHOD as well as X-PROP in iTIP objects will be possible, yet straightforward; - The proposed model can easily be documented with ABNF (as in RFC 2445) and restriction tables (as in RFC 2446) (i.e., to assert whether a property is required, is optional and the number of times it may appear in a VCOMMAND component given the value of its CMD property). I truly believe that my proposal will allow us to move forward and to start addressing the other issues in the pipeline. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 ------------------------------------------------------------------------ X.1 Command Component Component Name: "VCOMMAND" Purpose: Provide a grouping of component properties that describe a CAP command. Format Definition: A "VCOMMAND" calendar component is defined by the following notation: commandc = "BEGIN" ":" "VCOMMAND" CRLF commandprop [ component ] ; Defined in RFC 2445 "END" ":" "VCOMMAND" CRLF commandprop = *( ; the following are REQUIRED, ; and MUST NOT occur more than once cmd / cmdid / ; the following are OPTIONAL, ; and MUST NOT occur more than once latency / destination / ; Used with CMD:MOVE uidcount / ; Used with CMD:GENERATE-UID identity / ; Used with CMD:IDENTIFY ; the following are OPTIONAL, ; and MAY occur more than once target / x-prop / iana-prop ) Description: A "VCOMMAND" calendar component is a grouping of component properties, and possibly including other calendar components, that represents a CAP command. Example: The following is an example of the "VCOMMAND" calendar component used to create a meeting in a calendar: BEGIN:VCOMMAND CMD:CREATE CMDID:abcd1234 LATENCY;ACTION=ABORT:10 TARGET:cap://cal.host.com/mary-relcalid BEGIN:VEVENT UID:20010919T103000Z-123401@host.com ORGAGNIZER:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid DTSTART:20010920T180000Z DTEND:20010920T190000Z SUMMARY:Mary invites Bob END:VEVENT END:VCOMMAND The following is an example of the "VCOMMAND" calendar component used to search for a specific meeting in a calendar: BEGIN:VCOMMAND CMD:SEARCH CMDID:abcd1235 TARGET:cap://cal.host.com/mary-relcalid BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE UID = '20010919T103000Z-123401@host.com' END:VQUERY END:VCOMMAND ------------------------------------------------------------------------ X.2 Result Component Component Name: "VRESULT" Purpose: Provide a grouping of component properties that describe the result of a command. Format Definition: A "VRESULT" calendar component is defined by the following notation: resultc = "BEGIN" ":" "VRESULT" CRLF resultprop component ; Defined in RFC 2445 "END" ":" "VRESULT" CRLF resultprop = *( ; the following are REQUIRED, ; and MUST NOT occur more than once cmdid / request-status ; the following are OPTIONAL, ; and MAY occur more than once target / x-prop / iana-prop ) Description: A "VRESULT" calendar component is a grouping of component properties, and possibly including other calendar components, that represents the result of a CAP command. Multiple VRESULT components may be returned as a result of a single VCOMMAND (e.g., one VRESULT component for each TARGET property specified in the submitted VCOMMAND component). Example: The following is an example of the "VRESULT" calendar component return after a successful creation of a new VEVENT in a calendar: BEGIN:VRESULT CMDID:abcd1234 REQUEST-STATUS:2.0 TARGET:cap://cal.host.com/mary-relcalid BEGIN:VEVENT UID:20010919T103000Z-123401@host.com END:VEVENT END:VRESULT The following is an example of the "VRESULT" calendar component returned after a successful search command for a specific VEVENT: BEGIN:VRESULT CMDID:abcd1235 REQUEST-STATUS:2.0 TARGET:cap://cal.host.com/mary-relcalid BEGIN:VEVENT UID:20010919T103000Z-123401@host.com ORGAGNIZER:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid DTSTART:20010920T180000Z DTEND:20010920T190000Z SUMMARY:Mary invites Bob END:VEVENT END:VRESULT ------------------------------------------------------------------------ X.3 iTIP Component Component Name: "VITIP" Purpose: Provide a grouping of component properties that describe an iTIP message. Format Definition: A "VITIP" calendar component is defined by the following notation: vitipc = "BEGIN" ":" "VITIP" CRLF icalbody ; Defined in RFC 2445 "END" ":" "VITIP" CRLF Description: A "VITIP" calendar component is a grouping of component properties, and possibly including other calendar components, that represents an iTIP message. Example: The following is an example of the "VITIP" calendar component return after a successful creation of a new VEVENT in a calendar: BEGIN:VITIP VERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST BEGIN:VEVENT UID:20010919T103000Z-123401@host.com ORGAGNIZER:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid DTSTART:20010920T180000Z DTEND:20010920T190000Z SUMMARY:Mary invites Bob END:VEVENT END:VITIP ------------------------------------------------------------------------ X.4 Command Property Property Name: CMD Purpose: This property identifies the command in the VCOMMAND component. Value Type: TEXT Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property MUST be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify the command to be performed by the CUA or the CS. Format Definition: The property is defined by the following notation: cmd = "CMD" cmdparam ":" cmdvalue CRLF cmdparam = *( ";" xparam ) cmdvalue = ( "GENERATE-UID" / "GET-CAPABILITY" / "IDENTIFY" / "NOOP" / "CREATE" / "MOVE" / "DELETE" / "MODIFY" / "SEARCH" / "ABORT" / "CONTINUE" / x-name / iana-token ) Example: The following are examples of this property: CMD:CREATE CMD:MOVE ------------------------------------------------------------------------ X.5 Command Identifier Property Property Name: CMDID Purpose: This property specifies the identifier for a command calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify an identifier. Format Definition: The property is defined by the following notation: cmdid = "CMDID" cmdidparam ":" text CRLF cmdidparam = *( ";" xparam ) Example: The following is an example of this property: CMDID:abcd-123 ------------------------------------------------------------------------ X.6 Command Latency Property Property Name: LATENCY Purpose: This property specifies the maximum latency time in seconds for a CAP command. Value Type: INTEGER Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MAY be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify the maximum latency time in seconds for a CAP command. Format Definition: The property is defined by the following notation: latency = "LATENCY" latencyparam ":" integer CRLF latencyparam = *( ; the following is optional, ; but MUST NOT occur more than once ( ";" actionparam ) / ; the following is optional, ; and MAY occur more than once ( ";" xparam ) ) Example: The following are examples of this property: LATENCY:10 LATENCY;ACTION=ASK:5 ------------------------------------------------------------------------ X.7 Action Parameter Parameter Name: ACTION Purpose: To specify the action that should be taken when the maximum latency time is exceeded. Format Definition: The property parameter is defined by the following notation: actionparam = "ACTION" "=" ( "ABORT" / "ASK" / x-name / iana-token ) Description: This parameter can be specified on the "LATENCY" property. The parameter specifies whether a command should be aborted when the maximum latency time is exceed or if the remote peer (e.g., CUA) should be prompted to find out if the command should be continued or aborted. ------------------------------------------------------------------------ X.8 Destination Property Property Name: DESTINATION Purpose: This property specifies the address of a calendar to which components should be moved. Value Type: CAL-ADDRESS Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MAY be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify the address of a calendar to which components should be moved as a result of a MOVE command. Format Definition: The property is defined by the following notation: destination = "DESTINATION" destinationparam ":" integer CRLF destinationparam = *( ";" xparam ) Example: The following is an example of this property: DESTINATION:cap://cal.host.com/mary-relcalid ------------------------------------------------------------------------ X.9 Unique Identifier Count Property Property Name: UIDCOUNT Purpose: This property specifies the number of UID properties requested as part of a GENERATE-UID command. Value Type: INTEGER Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MAY be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify the number of UID properties that must be returned as a result of a GENERATE-UID command. Format Definition: The property is defined by the following notation: uidcount = "UIDCOUNT" uidcountparam ":" integer CRLF uidcountparam = *( ";" xparam ) Example: The following is an example of this property: UIDCOUNT:42 ------------------------------------------------------------------------ X.10 Identity Property Property Name: IDENTITY Purpose: This property specifies a new identity for a CAP session. Value Type: UPN Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MAY be specified once in a "VCOMMAND" calendar component. Description: This property is used in the "VCOMMAND" calendar component to specify a new identity for a CAP session. Format Definition: The property is defined by the following notation: identity = "IDENTITY" identityparam ":" upn CRLF identityparam = *( ";" xparam ) Example: The following are examples of this property: IDENTITY:bill@cal.example.com IDENTITY:@ ------------------------------------------------------------------------ --=_alternative 006047B585256BD6_= Content-Type: text/html; charset="us-ascii"
Bernard, I thought there were some major issues with Version 05.  Will putting these comments back in bring back those issues?


Bernard Desruisseaux <bernard@steltor.com>
Sent by: owner-ietf-calendar@mail.imc.org

06/12/02 11:01

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Full proposal for current issue (i.e., Where to store METHOD info)




It has been more than two weeks since I gave answers to the
questions that, I believe, need to be addressed in order to
solve the current issue, and there is no other proposal that
obeys to RFC 2445 and RFC 2446, so I propose that the following
text be added to the current draft, and that all the examples
be changed accordingly.  I volunteer to do the editing!

Here are some hightlights of the proposal:

- Allow us to obey to RFC 2445 and RFC 2446 by making use
 of additional components (as was done in draft 05). This
 will avoid the hassle of changing the VERSION number;

- Make the model clear.  Commands are sent in VCOMMAND
 compoents, and results returned in VRESULT components.
 No more commands returned as a result to a command!

- The use of a VITIP component doesn't make query for iTIP
 objects a special case (no change required to CAP-QL);

- Querying on VERSION, PRODID, METHOD as well as X-PROP
 in iTIP objects will be possible, yet straightforward;

- The proposed model can easily be documented with ABNF
 (as in RFC 2445) and restriction tables (as in RFC 2446)
 (i.e., to assert whether a property is required, is optional
 and the number of times it may appear in a VCOMMAND component
 given the value of its CMD property).

I truly believe that my proposal will allow us to move forward
and to start addressing the other issues in the pipeline.

Cheers,
Bernard
--
Bernard Desruisseaux                    mailto:bernard@steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

------------------------------------------------------------------------
X.1 Command Component

  Component Name: "VCOMMAND"

  Purpose: Provide a grouping of component properties that describe a
  CAP command.

  Format Definition: A "VCOMMAND" calendar component is defined by the
  following notation:

       commandc = "BEGIN" ":" "VCOMMAND" CRLF
                  commandprop
                  [ component ]      ; Defined in RFC 2445
                  "END" ":" "VCOMMAND" CRLF

       commandprop = *(

                   ; the following are REQUIRED,
                   ; and MUST NOT occur more than once

                   cmd / cmdid /

                   ; the following are OPTIONAL,
                   ; and MUST NOT occur more than once

                   latency /
                   destination /   ; Used with CMD:MOVE
                   uidcount /      ; Used with CMD:GENERATE-UID
                   identity /      ; Used with CMD:IDENTIFY

                   ; the following are OPTIONAL,
                   ; and MAY occur more than once

                   target / x-prop / iana-prop

                   )

  Description: A "VCOMMAND" calendar component is a grouping of
  component properties, and possibly including other calendar
  components, that represents a CAP command.

  Example: The following is an example of the "VCOMMAND" calendar
  component used to create a meeting in a calendar:

    BEGIN:VCOMMAND
    CMD:CREATE
    CMDID:abcd1234
    LATENCY;ACTION=ABORT:10
    TARGET:cap://cal.host.com/mary-relcalid
    BEGIN:VEVENT
    UID:20010919T103000Z-123401@host.com
    ORGAGNIZER:cap://cal.host.com/mary-relcalid
    ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid
   
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid
    DTSTART:20010920T180000Z
    DTEND:20010920T190000Z
    SUMMARY:Mary invites Bob
    END:VEVENT
    END:VCOMMAND

  The following is an example of the "VCOMMAND" calendar component used
  to search for a specific meeting in a calendar:

    BEGIN:VCOMMAND
    CMD:SEARCH
    CMDID:abcd1235
    TARGET:cap://cal.host.com/mary-relcalid
    BEGIN:VQUERY
    QUERY:SELECT * FROM VEVENT
     WHERE UID = '20010919T103000Z-123401@host.com'
    END:VQUERY
    END:VCOMMAND

------------------------------------------------------------------------
X.2 Result Component

  Component Name: "VRESULT"

  Purpose: Provide a grouping of component properties that describe the
  result of a command.

  Format Definition: A "VRESULT" calendar component is defined by the
  following notation:

       resultc = "BEGIN" ":" "VRESULT" CRLF
                 resultprop
                 component          ; Defined in RFC 2445
                 "END" ":" "VRESULT" CRLF

       resultprop = *(

                  ; the following are REQUIRED,
                  ; and MUST NOT occur more than once

                  cmdid / request-status

                  ; the following are OPTIONAL,
                  ; and MAY occur more than once

                  target / x-prop / iana-prop

                  )

  Description: A "VRESULT" calendar component is a grouping of
  component properties, and possibly including other calendar
  components, that represents the result of a CAP command.  Multiple
  VRESULT components may be returned as a result of a single VCOMMAND
  (e.g., one VRESULT component for each TARGET property specified in
   the submitted VCOMMAND component).

  Example: The following is an example of the "VRESULT" calendar
  component return after a successful creation of a new VEVENT
  in a calendar:

    BEGIN:VRESULT
    CMDID:abcd1234
    REQUEST-STATUS:2.0
    TARGET:cap://cal.host.com/mary-relcalid
    BEGIN:VEVENT
    UID:20010919T103000Z-123401@host.com
    END:VEVENT
    END:VRESULT

  The following is an example of the "VRESULT" calendar component
  returned after a successful search command for a specific VEVENT:

    BEGIN:VRESULT
    CMDID:abcd1235
    REQUEST-STATUS:2.0
    TARGET:cap://cal.host.com/mary-relcalid
    BEGIN:VEVENT
    UID:20010919T103000Z-123401@host.com
    ORGAGNIZER:cap://cal.host.com/mary-relcalid
    ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid
   
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid
    DTSTART:20010920T180000Z
    DTEND:20010920T190000Z
    SUMMARY:Mary invites Bob
    END:VEVENT
    END:VRESULT

------------------------------------------------------------------------
X.3 iTIP Component

  Component Name: "VITIP"

  Purpose: Provide a grouping of component properties that describe an
  iTIP message.

  Format Definition: A "VITIP" calendar component is defined by the
  following notation:

       vitipc = "BEGIN" ":" "VITIP" CRLF
                icalbody        ; Defined in RFC 2445
                "END" ":" "VITIP" CRLF

  Description: A "VITIP" calendar component is a grouping of component
  properties, and possibly including other calendar components, that
  represents an iTIP message.

  Example: The following is an example of the "VITIP" calendar
  component return after a successful creation of a new VEVENT
  in a calendar:

    BEGIN:VITIP
    VERSION:2.0
    PRODID:-//ACME/DesktopCalendar//EN
    METHOD:REQUEST
    BEGIN:VEVENT
    UID:20010919T103000Z-123401@host.com
    ORGAGNIZER:cap://cal.host.com/mary-relcalid
    ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.host.com/mary-relcalid
   
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.host.com/bob-relcalid
    DTSTART:20010920T180000Z
    DTEND:20010920T190000Z
    SUMMARY:Mary invites Bob
    END:VEVENT
    END:VITIP

------------------------------------------------------------------------
X.4 Command Property

  Property Name: CMD

  Purpose: This property identifies the command in the VCOMMAND
  component.

  Value Type: TEXT

  Property Parameters: Only non-standard property parameters can be
  specified on this property.

  Conformance: This property MUST be specified once in a "VCOMMAND"
  calendar component.

  Description: This property is used in the "VCOMMAND" calendar
  component to specify the command to be performed by the CUA or
  the CS.

  Format Definition: The property is defined by the following notation:

       cmd     = "CMD" cmdparam ":" cmdvalue CRLF

       cmdparam  = *( ";" xparam )

       cmdvalue = ( "GENERATE-UID" /
                    "GET-CAPABILITY" /
                    "IDENTIFY" /
                    "NOOP" /
                    "CREATE" /
                    "MOVE" /
                    "DELETE" /
                    "MODIFY" /
                    "SEARCH" /
                    "ABORT" /
                    "CONTINUE" /
                    x-name /
                    iana-token )

  Example: The following are examples of this property:

       CMD:CREATE

       CMD:MOVE

------------------------------------------------------------------------
X.5 Command Identifier Property

  Property Name: CMDID

  Purpose: This property specifies the identifier for a command
  calendar component.

  Value Type: TEXT

  Property Parameters: Non-standard property parameters can be
  specified on this property.

  Conformance: This property MUST be specified once in a "VCOMMAND"
  calendar component.

  Description: This property is used in the "VCOMMAND" calendar
  component to specify an identifier.


  Format Definition: The property is defined by the following notation:

       cmdid      = "CMDID" cmdidparam ":" text CRLF

       cmdidparam = *( ";" xparam )

  Example: The following is an example of this property:

       CMDID:abcd-123

------------------------------------------------------------------------
X.6 Command Latency Property

  Property Name: LATENCY

  Purpose: This property specifies the maximum latency time in seconds
  for a CAP command.

  Value Type: INTEGER

  Property Parameters: Non-standard property parameters can be
  specified on this property.

  Conformance: This property MAY be specified once in a "VCOMMAND"
  calendar component.

  Description: This property is used in the "VCOMMAND" calendar
  component to specify the maximum latency time in seconds for a
  CAP command.

  Format Definition: The property is defined by the following notation:

       latency      = "LATENCY" latencyparam ":" integer CRLF

       latencyparam = *(

                    ; the following is optional,
                    ; but MUST NOT occur more than once

                    ( ";" actionparam ) /

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

                    ( ";" xparam )

                    )


  Example: The following are examples of this property:

       LATENCY:10

       LATENCY;ACTION=ASK:5

------------------------------------------------------------------------
X.7 Action Parameter

  Parameter Name: ACTION

  Purpose: To specify the action that should be taken when the maximum
  latency time is exceeded.

  Format Definition: The property parameter is defined by the following
  notation:

    actionparam  = "ACTION" "=" ( "ABORT" /
                                  "ASK" /
                                  x-name /
                                  iana-token )

  Description: This parameter can be specified on the "LATENCY"
  property.  The parameter specifies whether a command should
  be aborted when the maximum latency time is exceed or if the
  remote peer (e.g., CUA) should be prompted to find out if
  the command should be continued or aborted.

------------------------------------------------------------------------
X.8 Destination Property

  Property Name: DESTINATION

  Purpose: This property specifies the address of a calendar to
  which components should be moved.

  Value Type: CAL-ADDRESS

  Property Parameters: Non-standard property parameters can be
  specified on this property.

  Conformance: This property MAY be specified once in a "VCOMMAND"
  calendar component.

  Description: This property is used in the "VCOMMAND" calendar
  component to specify the address of a calendar to which components
  should be moved as a result of a MOVE command.

  Format Definition: The property is defined by the following notation:

       destination = "DESTINATION" destinationparam ":" integer CRLF

       destinationparam = *( ";" xparam )

  Example: The following is an example of this property:

       DESTINATION:cap://cal.host.com/mary-relcalid

------------------------------------------------------------------------
X.9 Unique Identifier Count Property

  Property Name: UIDCOUNT

  Purpose: This property specifies the number of UID properties
  requested as part of a GENERATE-UID command.

  Value Type: INTEGER

  Property Parameters: Non-standard property parameters can be
  specified on this property.

  Conformance: This property MAY be specified once in a "VCOMMAND"
  calendar component.

  Description: This property is used in the "VCOMMAND" calendar
  component to specify the number of UID properties that must be
  returned as a result of a GENERATE-UID command.

  Format Definition: The property is defined by the following notation:

       uidcount      = "UIDCOUNT" uidcountparam ":" integer CRLF

       uidcountparam = *( ";" xparam )

  Example: The following is an example of this property:

       UIDCOUNT:42

------------------------------------------------------------------------
X.10 Identity Property

  Property Name: IDENTITY

  Purpose: This property specifies a new identity for a CAP session.

  Value Type: UPN

  Property Parameters: Non-standard property parameters can be
  specified on this property.

  Conformance: This property MAY be specified once in a "VCOMMAND"
  calendar component.

  Description: This property is used in the "VCOMMAND" calendar
  component to specify a new identity for a CAP session.

  Format Definition: The property is defined by the following notation:

       identity     = "IDENTITY" identityparam ":" upn CRLF

       identityparam = *( ";" xparam )

  Example: The following are examples of this property:

       IDENTITY:bill@cal.example.com

       IDENTITY:@

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

--=_alternative 006047B585256BD6_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 12 13:54:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06903 for ; Wed, 12 Jun 2002 13:54:02 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5CHl6F12160 for ietf-calendar-bks; Wed, 12 Jun 2002 10:47:06 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CHl5n12156 for ; Wed, 12 Jun 2002 10:47:05 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5CHl2pf030725 for ; Wed, 12 Jun 2002 13:47:02 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5CHl1620363 for ; Wed, 12 Jun 2002 13:47:01 -0400 (EDT) Message-ID: <3D078A0B.DA4BF18C@steltor.com> Date: Wed, 12 Jun 2002 13:51:07 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: draft-07 - XML References: <3D061A3E.5020703@samsungcontact.com> <3D066AA2.854D412E@Royer.com> <3D07549A.E2038E70@steltor.com> <3D076468.E7D0985D@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doug Royer wrote: > > After this I will ignore ALL of these three points. > > WE ARE ALLOWED TO CHANGE THINGS - AND IT IS IN OUR CHARTER. Of course we are! I never said otherwise. > > WE ARE ALLOWED TO ADD THINGS. Of course we are! I never said otherwise. > > VERSION 2.0 REFERS TO THE FORMAT, NOT THE CONTENT. Correct, and here's what RFC 2445 says (Section 2): This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. The notation used in this memo is the ABNF notation of [RFC 2234]. Readers intending on implementing this format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. It is my understanding that RFC 2445 makes use of ABNF "for defining the calendaring and scheduling format" and that you want to change the ABNF, which in turn will change... the format! Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Jun 12 14:08:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07440 for ; Wed, 12 Jun 2002 14:08:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CI1BW12517 for ietf-calendar-bks; Wed, 12 Jun 2002 11:01:11 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CI19n12513 for ; Wed, 12 Jun 2002 11:01:09 -0700 (PDT) To: Bernard Desruisseaux Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: draft-07 - XML MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 12 Jun 2002 14:01:06 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/12/2002 02:01:12 PM, Serialize complete at 06/12/2002 02:01:12 PM Content-Type: multipart/alternative; boundary="=_alternative 0062FA6E85256BD6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0062FA6E85256BD6_= Content-Type: text/plain; charset="us-ascii" I might be wrong, but if we are suggesting changing the format of the ABNF, then, indeed, we need to update the version of previous RFC's. But, I think we may have to do that anyway. There are things coming out of the interop testing that need to go into iCalendar. Should we not try to get them in and incorporate any other "matters that arise". Since it's an established RFC, and if we can prove that the changes are required and won't break (but rather fix) vendor implementations, and ... we get the list to approve them, then getting the RFC's through should not be that long of a process. I believe the "getting the list to approve" will be the hard part. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Bernard Desruisseaux Sent by: owner-ietf-calendar@mail.imc.org 06/12/02 13:51 To: ietf-calendar@imc.org cc: Subject: Re: draft-07 - XML Doug Royer wrote: > > After this I will ignore ALL of these three points. > > WE ARE ALLOWED TO CHANGE THINGS - AND IT IS IN OUR CHARTER. Of course we are! I never said otherwise. > > WE ARE ALLOWED TO ADD THINGS. Of course we are! I never said otherwise. > > VERSION 2.0 REFERS TO THE FORMAT, NOT THE CONTENT. Correct, and here's what RFC 2445 says (Section 2): This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. The notation used in this memo is the ABNF notation of [RFC 2234]. Readers intending on implementing this format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. It is my understanding that RFC 2445 makes use of ABNF "for defining the calendaring and scheduling format" and that you want to change the ABNF, which in turn will change... the format! Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 --=_alternative 0062FA6E85256BD6_= Content-Type: text/html; charset="us-ascii"
I might be wrong, but if we are suggesting changing the format of the ABNF, then, indeed, we need to update the version of previous RFC's.  But, I think we may have to do that anyway.  There are things coming out of the interop testing that need to go into iCalendar.  Should we not try to get them in and incorporate any other "matters that arise".  Since it's an established RFC, and if we can prove that the changes are required and won't break (but rather fix) vendor implementations, and ... we get the list to approve them, then getting the RFC's through should not be that long of a process.  I believe the "getting the list to approve" will be the hard part.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Bernard Desruisseaux <bernard@steltor.com>
Sent by: owner-ietf-calendar@mail.imc.org

06/12/02 13:51

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: draft-07 - XML




Doug Royer wrote:
>
> After this I will ignore ALL of these three points.
>
>         WE ARE ALLOWED TO CHANGE THINGS - AND IT IS IN OUR CHARTER.

Of course we are!  I never said otherwise.

>
>         WE ARE ALLOWED TO ADD THINGS.

Of course we are!  I never said otherwise.

>
>         VERSION 2.0 REFERS TO THE FORMAT, NOT THE CONTENT.

Correct, and here's what RFC 2445 says (Section 2):

  This memo makes use of both a descriptive prose and a more formal
  notation for defining the calendaring and scheduling format.

  The notation used in this memo is the ABNF notation of [RFC 2234].
  Readers intending on implementing this format defined in this memo
  should be familiar with this notation in order to properly interpret
  the specifications of this memo.


It is my understanding that RFC 2445 makes use of ABNF "for
defining the calendaring and scheduling format" and that you want
to change the ABNF, which in turn will change... the format!

Cheers,
Bernard
--
Bernard Desruisseaux                    mailto:bernard@steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

--=_alternative 0062FA6E85256BD6_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 12 14:10:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07523 for ; Wed, 12 Jun 2002 14:10:37 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5CI33n12574 for ietf-calendar-bks; Wed, 12 Jun 2002 11:03:03 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CI32n12570 for ; Wed, 12 Jun 2002 11:03:03 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5CI2upf031092; Wed, 12 Jun 2002 14:02:56 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5CI2u622471; Wed, 12 Jun 2002 14:02:56 -0400 (EDT) Message-ID: <3D078DC5.B524B32@steltor.com> Date: Wed, 12 Jun 2002 14:07:01 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: pregen@egenconsulting.com CC: ietf-calendar@imc.org Subject: Re: Full proposal for current issue (i.e., Where to store METHOD info) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > Bernard, I thought there were some major issues with Version 05. Will > putting these comments back in bring back those issues? Hi Pat, Draft 05 was defining a new iCalendar component, VCOMMAND, to specify CAP commands. In draft 06 the use of XML allowed use to get rid of the VCOMMAND component, since the information contained in this component was now stored in the XML portion. Following the removal of XML in CAP it is only normal to bring it back! Other than the VCOMMAND component, I'm not bringing back anything else from draft 05. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Jun 12 14:10:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07554 for ; Wed, 12 Jun 2002 14:10:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CI4Bg12660 for ietf-calendar-bks; Wed, 12 Jun 2002 11:04:11 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CI49n12656 for ; Wed, 12 Jun 2002 11:04:10 -0700 (PDT) To: Bernard Desruisseaux Cc: ietf-calendar@imc.org Subject: Re: Full proposal for current issue (i.e., Where to store METHOD info) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 12 Jun 2002 14:04:06 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/12/2002 02:04:12 PM, Serialize complete at 06/12/2002 02:04:12 PM Content-Type: multipart/alternative; boundary="=_alternative 006340F685256BD6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006340F685256BD6_= Content-Type: text/plain; charset="us-ascii" Cool. Just checking. There are so many draft numbers running around, I wanted to make sure we were not opening any worm cans. Glad to see activity back on the list - the last thing I want to do is stop it. Keep up the good work!!!! ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Bernard Desruisseaux 06/12/02 14:07 To: pregen@egenconsulting.com cc: ietf-calendar@imc.org Subject: Re: Full proposal for current issue (i.e., Where to store METHOD info) pregen@egenconsulting.com wrote: > > Bernard, I thought there were some major issues with Version 05. Will > putting these comments back in bring back those issues? Hi Pat, Draft 05 was defining a new iCalendar component, VCOMMAND, to specify CAP commands. In draft 06 the use of XML allowed use to get rid of the VCOMMAND component, since the information contained in this component was now stored in the XML portion. Following the removal of XML in CAP it is only normal to bring it back! Other than the VCOMMAND component, I'm not bringing back anything else from draft 05. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 --=_alternative 006340F685256BD6_= Content-Type: text/html; charset="us-ascii"
Cool. Just checking.  There are so many draft numbers running around, I wanted to make sure we were not opening any worm cans.  Glad to see activity back on the list - the last thing I want to do is stop it.  Keep up the good work!!!!
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Bernard Desruisseaux <bernard@steltor.com>

06/12/02 14:07

       
        To:        pregen@egenconsulting.com
        cc:        ietf-calendar@imc.org
        Subject:        Re: Full proposal for current issue (i.e., Where to store METHOD info)



pregen@egenconsulting.com wrote:
>
> Bernard, I thought there were some major issues with Version 05.  Will
> putting these comments back in bring back those issues?

Hi Pat,

Draft 05 was defining a new iCalendar component, VCOMMAND,
to specify CAP commands.

In draft 06 the use of XML allowed use to get rid of the
VCOMMAND component, since the information contained in
this component was now stored in the XML portion.

Following the removal of XML in CAP it is only normal to
bring it back!

Other than the VCOMMAND component, I'm not bringing back
anything else from draft 05.

Cheers,
Bernard
--
Bernard Desruisseaux                    mailto:bernard@steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

--=_alternative 006340F685256BD6_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 12 14:36:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08580 for ; Wed, 12 Jun 2002 14:36:31 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5CIOtf13148 for ietf-calendar-bks; Wed, 12 Jun 2002 11:24:55 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIOsn13144 for ; Wed, 12 Jun 2002 11:24:54 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5CIOnpf031450; Wed, 12 Jun 2002 14:24:49 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5CIOn624943; Wed, 12 Jun 2002 14:24:49 -0400 (EDT) Message-ID: <3D0792E6.20E97E1E@steltor.com> Date: Wed, 12 Jun 2002 14:28:54 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: pregen@egenconsulting.com CC: ietf-calendar@imc.org Subject: Re: draft-07 - XML References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > > I might be wrong, but if we are suggesting changing the format of the > ABNF, then, indeed, we need to update the version of previous RFC's. > But, I think we may have to do that anyway. There are things coming > out of the interop testing that need to go into iCalendar. Should we > not try to get them in and incorporate any other "matters that arise". > Since it's an established RFC, and if we can prove that the changes > are required and won't break (but rather fix) vendor implementations, > and ... we get the list to approve them, then getting the RFC's > through should not be that long of a process. I believe the "getting > the list to approve" will be the hard part. Given that there are ways to implement CAP without having to change RFC 2445 and RFC 2446, I believe that we should stay focused on CAP and not work on these RFCs for now. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Wed Jun 12 14:38:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08723 for ; Wed, 12 Jun 2002 14:38:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CITu013254 for ietf-calendar-bks; Wed, 12 Jun 2002 11:29:56 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CITsn13250 for ; Wed, 12 Jun 2002 11:29:54 -0700 (PDT) To: Bernard Desruisseaux Cc: ietf-calendar@imc.org Subject: Re: draft-07 - XML MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 12 Jun 2002 14:29:51 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/12/2002 02:29:57 PM, Serialize complete at 06/12/2002 02:29:57 PM Content-Type: multipart/alternative; boundary="=_alternative 00659C7F85256BD6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00659C7F85256BD6_= Content-Type: text/plain; charset="us-ascii" Agreed Bernard. That's what we, the chairs have been saying! Glad to hear you have been listening. My point, though, was that we will eventually need to make changes to the existing RFC's - and my suggestion was that we incorporate them all at the same time. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Bernard Desruisseaux 06/12/02 14:28 To: pregen@egenconsulting.com cc: ietf-calendar@imc.org Subject: Re: draft-07 - XML pregen@egenconsulting.com wrote: > > I might be wrong, but if we are suggesting changing the format of the > ABNF, then, indeed, we need to update the version of previous RFC's. > But, I think we may have to do that anyway. There are things coming > out of the interop testing that need to go into iCalendar. Should we > not try to get them in and incorporate any other "matters that arise". > Since it's an established RFC, and if we can prove that the changes > are required and won't break (but rather fix) vendor implementations, > and ... we get the list to approve them, then getting the RFC's > through should not be that long of a process. I believe the "getting > the list to approve" will be the hard part. Given that there are ways to implement CAP without having to change RFC 2445 and RFC 2446, I believe that we should stay focused on CAP and not work on these RFCs for now. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 --=_alternative 00659C7F85256BD6_= Content-Type: text/html; charset="us-ascii"
Agreed Bernard. That's what we, the chairs have been saying! Glad to hear you have been listening.  My point, though, was that we will eventually need to make changes to the existing RFC's - and my suggestion was that we incorporate them all at the same time.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Bernard Desruisseaux <bernard@steltor.com>

06/12/02 14:28

       
        To:        pregen@egenconsulting.com
        cc:        ietf-calendar@imc.org
        Subject:        Re: draft-07 - XML



pregen@egenconsulting.com wrote:
>
> I might be wrong, but if we are suggesting changing the format of the
> ABNF, then, indeed, we need to update the version of previous RFC's.
>  But, I think we may have to do that anyway.  There are things coming
> out of the interop testing that need to go into iCalendar.  Should we
> not try to get them in and incorporate any other "matters that arise".
>  Since it's an established RFC, and if we can prove that the changes
> are required and won't break (but rather fix) vendor implementations,
> and ... we get the list to approve them, then getting the RFC's
> through should not be that long of a process.  I believe the "getting
> the list to approve" will be the hard part.

Given that there are ways to implement CAP without having to
change RFC 2445 and RFC 2446, I believe that we should stay
focused on CAP and not work on these RFCs for now.

Cheers,
Bernard
--
Bernard Desruisseaux                    mailto:bernard@steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

--=_alternative 00659C7F85256BD6_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 12 14:58:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09505 for ; Wed, 12 Jun 2002 14:58:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CIqCI13824 for ietf-calendar-bks; Wed, 12 Jun 2002 11:52:12 -0700 (PDT) Received: from postman.incentivesystems.com ([65.220.90.244]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIqAn13815 for ; Wed, 12 Jun 2002 11:52:10 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: draft-07 - XML MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 12 Jun 2002 14:54:26 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.10 |March 22, 2002) at 06/12/2002 02:55:03 PM, Serialize complete at 06/12/2002 02:55:03 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Given that there are ways to implement CAP without having to >change RFC 2445 and RFC 2446, I believe that we should stay >focused on CAP and not work on these RFCs for now. We should do the Right Thing for CAP. Obsoleting 2445 would be a lot of work (it'd open up the chance for people to suggest "just one more thing"), but we can issue a small interim RFC that updates 2445. Or we might be able to have the CAP RFC update 2445; but I'd guess it'd be simpler to isolate the update into a separate document. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |Reality is what refuses to go away when I stop believing in it.| \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jun 12 15:01:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09636 for ; Wed, 12 Jun 2002 15:01:10 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5CIrxI13899 for ietf-calendar-bks; Wed, 12 Jun 2002 11:53:59 -0700 (PDT) Received: from postman.incentivesystems.com ([65.220.90.244]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIrvn13892 for ; Wed, 12 Jun 2002 11:53:57 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: draft-07 - XML MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 12 Jun 2002 14:56:15 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.10 |March 22, 2002) at 06/12/2002 02:56:50 PM, Serialize complete at 06/12/2002 02:56:50 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >My point, though, was that we will eventually need to make changes to >the existing RFC's - and my suggestion was that we incorporate them >all at the same time. But, if CAP requires a change to 2445, then doing all the changes at once will mean putting off CAP until we have consensus on all the 2445 changes. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |Reality is what refuses to go away when I stop believing in it.| \===============================================================/ From owner-ietf-calendar@mail.imc.org Wed Jun 12 17:11:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13189 for ; Wed, 12 Jun 2002 17:11:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CL5b119251 for ietf-calendar-bks; Wed, 12 Jun 2002 14:05:37 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CL5Zn19242 for ; Wed, 12 Jun 2002 14:05:35 -0700 (PDT) To: "John Stracke" Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: draft-07 - XML MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 12 Jun 2002 17:05:32 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/12/2002 05:05:38 PM, Serialize complete at 06/12/2002 05:05:38 PM Content-Type: multipart/alternative; boundary="=_alternative 0073DD5E85256BD6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073DD5E85256BD6_= Content-Type: text/plain; charset="us-ascii" Ah, true. Don't want to do that. So, maybe a mini draft is a thought. "John Stracke" Sent by: owner-ietf-calendar@mail.imc.org 06/12/02 14:56 To: ietf-calendar@imc.org cc: Subject: Re: draft-07 - XML >My point, though, was that we will eventually need to make changes to >the existing RFC's - and my suggestion was that we incorporate them >all at the same time. But, if CAP requires a change to 2445, then doing all the changes at once will mean putting off CAP until we have consensus on all the 2445 changes. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |Reality is what refuses to go away when I stop believing in it.| \===============================================================/ --=_alternative 0073DD5E85256BD6_= Content-Type: text/html; charset="us-ascii"
Ah, true.  Don't want to do that.  So, maybe a mini draft is a thought.


"John Stracke" <jstracke@incentivesystems.com>
Sent by: owner-ietf-calendar@mail.imc.org

06/12/02 14:56

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: draft-07 - XML




>My point, though, was that we will eventually need to make changes to
>the existing RFC's - and my suggestion was that we incorporate them
>all at the same time.

But, if CAP requires a change to 2445, then doing all the changes at once
will mean putting off CAP until we have consensus on all the 2445 changes.

/===============================================================\
|John Stracke                    |Principal Engineer            |
|jstracke@incentivesystems.com   |Incentive Systems, Inc.       |
|http://www.incentivesystems.com |My opinions are my own.       |
|===============================================================|
|Reality is what refuses to go away when I stop believing in it.|
\===============================================================/

--=_alternative 0073DD5E85256BD6_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 12 17:11:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13216 for ; Wed, 12 Jun 2002 17:11:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CL55K19226 for ietf-calendar-bks; Wed, 12 Jun 2002 14:05:05 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CL53n19216 for ; Wed, 12 Jun 2002 14:05:03 -0700 (PDT) To: "John Stracke" Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: draft-07 - XML MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 12 Jun 2002 17:05:00 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/12/2002 05:05:07 PM, Serialize complete at 06/12/2002 05:05:07 PM Content-Type: multipart/alternative; boundary="=_alternative 0073D0A685256BD6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0073D0A685256BD6_= Content-Type: text/plain; charset="us-ascii" Ok, I'm confused (easy to do). So, list, help me out here. I think what Doug is saying is that what he wants to do is add another property. And, if you read RFC2445 and the others, it says you can use either the properties defined in the three drafts (iCal, iTIP and iMIP) or any other IANA defined property. So, if we do what you suggest, a mini draft to update RFC2445, wouldn't that work? I think so, but want to make sure I'm reading this right. Any other lurkers on the list are welcome to respond! 8-) ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 "John Stracke" Sent by: owner-ietf-calendar@mail.imc.org 06/12/02 14:54 To: ietf-calendar@imc.org cc: Subject: Re: draft-07 - XML >Given that there are ways to implement CAP without having to >change RFC 2445 and RFC 2446, I believe that we should stay >focused on CAP and not work on these RFCs for now. We should do the Right Thing for CAP. Obsoleting 2445 would be a lot of work (it'd open up the chance for people to suggest "just one more thing"), but we can issue a small interim RFC that updates 2445. Or we might be able to have the CAP RFC update 2445; but I'd guess it'd be simpler to isolate the update into a separate document. /===============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===============================================================| |Reality is what refuses to go away when I stop believing in it.| \===============================================================/ --=_alternative 0073D0A685256BD6_= Content-Type: text/html; charset="us-ascii"
Ok, I'm confused (easy to do). So, list, help me out here.  I think what Doug is saying is that what he wants to do is add another property.  And, if you read RFC2445 and the others, it says you can use either the properties defined in the three drafts (iCal, iTIP and iMIP) or any other IANA defined property.  So, if we do what you suggest, a mini draft to update RFC2445, wouldn't that work?  I think so, but want to make sure I'm reading this right. Any other lurkers on the list are welcome to respond! 8-)
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


"John Stracke" <jstracke@incentivesystems.com>
Sent by: owner-ietf-calendar@mail.imc.org

06/12/02 14:54

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: draft-07 - XML




>Given that there are ways to implement CAP without having to
>change RFC 2445 and RFC 2446, I believe that we should stay
>focused on CAP and not work on these RFCs for now.

We should do the Right Thing for CAP.  Obsoleting 2445 would be a lot of
work (it'd open up the chance for people to suggest "just one more
thing"), but we can issue a small interim RFC that updates 2445.  Or we
might be able to have the CAP RFC update 2445; but I'd guess it'd be
simpler to isolate the update into a separate document.

/===============================================================\
|John Stracke                    |Principal Engineer            |
|jstracke@incentivesystems.com   |Incentive Systems, Inc.       |
|http://www.incentivesystems.com |My opinions are my own.       |
|===============================================================|
|Reality is what refuses to go away when I stop believing in it.|
\===============================================================/

--=_alternative 0073D0A685256BD6_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 12 17:32:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13772 for ; Wed, 12 Jun 2002 17:32:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLQvv19898 for ietf-calendar-bks; Wed, 12 Jun 2002 14:26:57 -0700 (PDT) Received: from postman.incentivesystems.com ([65.220.90.244]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLQun19889 for ; Wed, 12 Jun 2002 14:26:56 -0700 (PDT) To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: draft-07 - XML MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Wed, 12 Jun 2002 17:29:06 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.10 |March 22, 2002) at 06/12/2002 05:29:49 PM, Serialize complete at 06/12/2002 05:29:49 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >And, if you read RFC2445 and the others, it says you can use either >the properties defined in the three drafts (iCal, iTIP and iMIP) or >any other IANA defined property. So, if we do what you suggest, a >mini draft to update RFC2445, wouldn't that work? Yes, that should work, provided the update revs the version number. The problem is that we have an inconsistency in 2445: the semantics of VERSION imply that any change to the definition of text/calendar requires a change the version number; but the Method Reviewer process permits changes to the definition without any RFC. As you know, I am not without an opinion on this subject. I maintain that iCalendar properties are interdependent, and cannot be defined in isolation, which means that the Method Reviewer process is inappropriate. Only a new standards-track RFC should be able to define iCalendar properties. Similarly, if the VERSION property is to be useful, it must be updated whenever the spec is updated. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |E pui muove! -- Galileo | \========================================================/ From owner-ietf-calendar@mail.imc.org Thu Jun 13 11:01:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16345 for ; Thu, 13 Jun 2002 11:01:52 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DEjE522388 for ietf-calendar-bks; Thu, 13 Jun 2002 07:45:14 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DEjDn22384 for ; Thu, 13 Jun 2002 07:45:13 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5DEjCfX006658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 13 Jun 2002 07:45:13 -0700 Message-ID: <3D08AEB5.BB6BC4FA@Royer.com> Date: Thu, 13 Jun 2002 08:39:49 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: draft-07 - XML References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD2423F1EE231EBD9AA0A7CCF" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msD2423F1EE231EBD9AA0A7CCF Content-Type: multipart/mixed; boundary="------------8E263A4ED6348ABAAFF7889E" This is a multi-part message in MIME format. --------------8E263A4ED6348ABAAFF7889E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > >And, if you read RFC2445 and the others, it says you can use either > >the properties defined in the three drafts (iCal, iTIP and iMIP) or > >any other IANA defined property. So, if we do what you suggest, a > >mini draft to update RFC2445, wouldn't that work? > > Yes, that should work, provided the update revs the version number. > > The problem is that we have an inconsistency in 2445: the semantics of > VERSION imply that any change to the definition of text/calendar requires > a change the version number; but the Method Reviewer process permits > changes to the definition without any RFC. VERSION "1.0" (vCalendar) objects look like this: BEGIN:VCALENDAR VERSION:1.0 property;parameterValue;parameterValue:propertyValue ... END:VCALENDAR VERSION "2.0" (iCalendar) objects look like this: BEGIN:VCALENDAR VERSION:2.0 property;parameter=value;parameger=value:propertyValue ... END:VCALENDAR We are NOT proposing changing from the "2.0" format. --------------8E263A4ED6348ABAAFF7889E Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------8E263A4ED6348ABAAFF7889E-- --------------msD2423F1EE231EBD9AA0A7CCF 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTMxNDM5NDlaMCMGCSqGSIb3DQEJ BDEWBBQ3bkKYF4HR4VPaDQpqdRYRlrv5wjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgKpjbFbAWvLas4bKCKOFPtLeuk+w+z5W3nfv2my0KYOlVXPd mVdCd0ZDBYZUWp6HrHAr+1sANNqaCd7NkTpwq4NcqxbHAG2Ja0PyXnu/g+oE9/vQz1/ySfQz jXWR7pf7tLCj4cuS7/dvrkRK8SQ2t9jK/vrlmRAz9Ed6o+WLVIXu --------------msD2423F1EE231EBD9AA0A7CCF-- From owner-ietf-calendar@mail.imc.org Thu Jun 13 11:54:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18700 for ; Thu, 13 Jun 2002 11:54:21 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5DFf6M25599 for ietf-calendar-bks; Thu, 13 Jun 2002 08:41:06 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DFf5n25594 for ; Thu, 13 Jun 2002 08:41:05 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5DFf1pf008108 for ; Thu, 13 Jun 2002 11:41:02 -0400 Received: from c-2856.steltor.com (c-2856.in.steltor.com [101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5DFf1623994; Thu, 13 Jun 2002 11:41:01 -0400 (EDT) Message-Id: <5.1.0.14.0.20020613110256.034e2610@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Jun 2002 11:44:40 -0400 To: ietf-calendar@imc.org, "ietf-calendar@imc.org" From: Alan Davies Subject: Re: draft-07 - XML In-Reply-To: <3D08AEB5.BB6BC4FA@Royer.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not sure where you got this information from, but in my copy of the vCalendar Specification, there are properties that look like this: ATTENDEE;ROLE=OWNER;STATUS=CONFIRMED:John Smith Surely that's "parameter=value" ? There's a copy online here if you don't have one to hand: http://www.memorystick.org/mseasy/eng/ref/vcal-10.pdf Of course, this discussion might be helped along by actually looking at the relevant parts of the vCalendar and iCalendar Specifications: vCalendar Version 1.0 states: 2.2.5 Version This property specifies the identifier corresponding to the highest version number of the vCalendar Specification supported by the implementation that created the vCalendar object. The value of this property must be 1.0 to correspond to this specification.. RFC2445 states: 4.7.4 Version Purpose: This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to interpret the iCalendar object. [...] Description: A value of "2.0" corresponds to this memo Even though the language is a bit vague, it does seem to refer to the fact that each memo uses a different version, not whether the structure has changed (not that the structure changed in the way that you said it did, of course). --Alan At 10:39 AM 13/06/2002, Doug Royer wrote: >John Stracke wrote: > > > > >And, if you read RFC2445 and the others, it says you can use either > > >the properties defined in the three drafts (iCal, iTIP and iMIP) or > > >any other IANA defined property. So, if we do what you suggest, a > > >mini draft to update RFC2445, wouldn't that work? > > > > Yes, that should work, provided the update revs the version number. > > > > The problem is that we have an inconsistency in 2445: the semantics of > > VERSION imply that any change to the definition of text/calendar requires > > a change the version number; but the Method Reviewer process permits > > changes to the definition without any RFC. > > >VERSION "1.0" (vCalendar) objects look like this: > > > BEGIN:VCALENDAR > VERSION:1.0 > property;parameterValue;parameterValue:propertyValue > ... > END:VCALENDAR > >VERSION "2.0" (iCalendar) objects look like this: > > BEGIN:VCALENDAR > VERSION:2.0 > property;parameter=value;parameger=value:propertyValue > ... > END:VCALENDAR > >We are NOT proposing changing from the "2.0" format. From owner-ietf-calendar@mail.imc.org Thu Jun 13 20:25:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05741 for ; Thu, 13 Jun 2002 20:25:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5E0J2n14057 for ietf-calendar-bks; Thu, 13 Jun 2002 17:19:02 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5E0J1n14052 for ; Thu, 13 Jun 2002 17:19:01 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA29289 for ; Thu, 13 Jun 2002 20:19:04 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA23675 for ; Thu, 13 Jun 2002 20:19:03 -0400 (EDT) Received: from [66.92.67.186] (airport.bobmah.com [66.92.67.186]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id UAA06148 for ; Thu, 13 Jun 2002 20:19:02 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Thu, 13 Jun 2002 20:19:00 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Focus attempt: Do new properties force a change in VERSION? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I asked Doug Royer to craft a concrete example that could explain his understanding of the competing viewpoints around the question of the need to change the VERSION property. His example follows. Thoughtful and dispassionate discussion is preferred... :-) If you have an alternate understanding, please include your version of this example object, so that we can compare apples and apples. Thanks -Bob -- Question: Does adding new properties force a change in the VERSION property value? (currently 2445 is version "2.0") My reasoning that it does not change: It would be like bumping the MIME-Version number in e-mail from the current 1.0 each time someone added a new header or mime body type. How many mime types have been added since MIME 1.0 was released? And MIME is still at 1.0 because the format of the MIME object has not changed. The implication of updating the VERSION number would be that ALL implementation of VERSION X.Y would have to implement ALL features in A.B through X.Y, when in fact they can be parallel an not interacting with each other. Example: If we were to add properties that allowed Hertz to track cars and called that version 2.3 . Then later added properties that allowed conference room tracking and called it 2.4 . Now all conference room implementation would have to implement car tracking to be compliant. When in fact the two can coexist and not interact with each other. How this effects the CAP design: Some folks on the list are saying that because we have to bump the version number (and we don't), then we MUST have a new iCalendar wrapper object EACH time we add a property. Not only that, but they are saying that in addition to making the wrapper object, we ALSO have to bump the version number of the object. Here is a silly example of how far that can go: BEGIN:VCALENDAR VERSION:X.Y BEGIN:WRAPPER-3 favorite-hand:right # implied version x.x BEGIN:WRAPPER-2 car-license-plate:123456 # implied version x.w BEGIN:WRAPPER-1 cap-command:just store it. # implied version x.v BEGIN:VEVENT # implied version 2.0 2445 - properties END:VEVENT END:WRAPPER-1 END:WRAPPER-2 END:WRAPPER-3 END:VCALENDAR When it could just be: BEGIN:VCALENDAR VERSION:2.0 favorite-hand:right car-license-plate:123456 cap-command:just store it. BEGIN:VEVENT 2445 - properties END:VEVENT END:VCALENDAR It is up to the WG to decide if the new properties effect existing objects. It is not automatic. Adding 'favorite-hand' does NOT effect anything. Adding 'bumb-all-dates-by-one-day' would effect other properties and and it would be blocked by the WG anyway. From owner-ietf-calendar@mail.imc.org Fri Jun 14 10:35:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01247 for ; Fri, 14 Jun 2002 10:35:33 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5EERh608226 for ietf-calendar-bks; Fri, 14 Jun 2002 07:27:43 -0700 (PDT) Received: from postman.incentivesystems.com ([65.220.90.244]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EERgn08221 for ; Fri, 14 Jun 2002 07:27:42 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Focus attempt: Do new properties force a change in VERSION? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 14 Jun 2002 10:30:21 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.10 |March 22, 2002) at 06/14/2002 10:30:40 AM, Serialize complete at 06/14/2002 10:30:40 AM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The implication of updating the VERSION number > would be that ALL implementation of VERSION X.Y > would have to implement ALL features in A.B through > X.Y, when in fact they can be parallel an not > interacting with each other. Some features might be parallel. For example, many of the SkiCal properties seem to be mutually independent. However, other useful features are not parallel. For example, many of the base iCalendar properties interact--consider DTEND and DURATION. It is clearly necessary that, any time we add the property which interacts with an existing property, we increment the version number. What is unclear is how much interaction is necessary. But this argument is beside the point. The fact is that the text of 2445 requires a change to the version number whenever any new property is defined: 4.7.4 Version Property Name: VERSION Purpose: This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to interpret the iCalendar object. "Interpret the iCalendar object" does not simply mean being able to parse it. It means been able to understand every property and every parameter. Now, if we had a requirement in 2445 that unknown properties be ignored, as in HTTP, then it would be valid to assume that would be safe to add properties which did not interact. Such a requirement would be a promise to spec extensions that complaint implementations would be able to cope with such new properties. But, as things stand, the spec makes the opposite promise: it promises implementors that any object labeled version 2.0 can be understood by implementing 2445 and nothing else. One more point: Doug has repeatedly asserted that VERSION refers only to the version of the format. However, this assertion cannot be correct, because 2445 does not define a format independent of the properties; it defines them all in the same ABNF grammar. /========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| |========================================================| |If at first you don't succeed, don't go skydiving. | \========================================================/ From owner-ietf-calendar@mail.imc.org Fri Jun 14 10:57:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02056 for ; Fri, 14 Jun 2002 10:57:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EEqLM09951 for ietf-calendar-bks; Fri, 14 Jun 2002 07:52:21 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EEqKn09946 for ; Fri, 14 Jun 2002 07:52:20 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5EApBL11969; Fri, 14 Jun 2002 06:51:11 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: ITIP Clarification From: JP Rosevear To: ietf-calendar@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 14 Jun 2002 06:51:11 -0400 Message-Id: <1024051871.11883.19.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Looking over the itip spec, I can see how the user can act on behalf of an organizer via the sent-by property. However what is unclear to me is if the initial event REQUEST can utilize the sent-by property because there is no mechanism specified to inform the actual organizer that they are indeed an event organizer. This is obviously a problem since all replies will flow to the organizer. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Jun 14 11:00:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02179 for ; Fri, 14 Jun 2002 11:00:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EEnbk09698 for ietf-calendar-bks; Fri, 14 Jun 2002 07:49:37 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EEnZn09694 for ; Fri, 14 Jun 2002 07:49:35 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5EAmPg11961; Fri, 14 Jun 2002 06:48:25 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: TZID conflict From: JP Rosevear To: ietf-calendar@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 14 Jun 2002 06:48:24 -0400 Message-Id: <1024051704.11918.15.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit According to the spec, the TZID property is of type TEXT meaning it can include things like a comma (which is escaped). However, a TZID parameter cannot contain the comma character (as well as several others) because it can only include characters of type paramtext which explicitly excludes the comma and allows no escaping mechanism. The upshot is you can specify a TZID property that can never be referenced by the TZID parameter of DTSTART et al. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Jun 14 11:51:51 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04181 for ; Fri, 14 Jun 2002 11:51:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EFjFx11170 for ietf-calendar-bks; Fri, 14 Jun 2002 08:45:15 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EFjEn11166 for ; Fri, 14 Jun 2002 08:45:14 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5EFjDFa006029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Jun 2002 08:45:15 -0700 Message-ID: <3D0A0E34.F61BAEBB@Royer.com> Date: Fri, 14 Jun 2002 09:39:32 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: TZID conflict References: <1024051704.11918.15.camel@endspiel.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms54AFD8756D644CEC53C03BAD" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms54AFD8756D644CEC53C03BAD Content-Type: multipart/mixed; boundary="------------552697BFCE011610DA7AF549" This is a multi-part message in MIME format. --------------552697BFCE011610DA7AF549 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit JP Rosevear wrote: > > According to the spec, the TZID property is of type TEXT meaning it can > include things like a comma (which is escaped). However, a TZID > parameter cannot contain the comma character (as well as several others) > because it can only include characters of type paramtext which > explicitly excludes the comma and allows no escaping mechanism. IN 2445: 4.1.1 List and Field Separators ... Property parameters with values containing a COLON, a SEMICOLON or a COMMA character MUST be placed in quoted text. ... Does that solve the problem? --------------552697BFCE011610DA7AF549 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------552697BFCE011610DA7AF549-- --------------ms54AFD8756D644CEC53C03BAD 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTQxNTM5MzhaMCMGCSqGSIb3DQEJ BDEWBBS5YYeK8j3Hn44e9bV3coMRUgs4CDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgELQzAcCkb6YMtd6rUfaLnk5L5oPi5ge5fnb5DDUdiJJebiB Rw4K8SOMz4qKLR/NQmZ6Vgb2TjO4yZ5vtYxCTWx7QVoqbvemRfN2XWk2hgPs9VuguKc5W3Wl YX4DSjQAP/L8jojH+88bDxwVVgwCLseFkb1DmzSV9Jl8MLcEb0ms --------------ms54AFD8756D644CEC53C03BAD-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 12:13:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04791 for ; Fri, 14 Jun 2002 12:13:38 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5EG6Br11456 for ietf-calendar-bks; Fri, 14 Jun 2002 09:06:11 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EG6An11452 for ; Fri, 14 Jun 2002 09:06:10 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA15653 for ; Fri, 14 Jun 2002 12:06:11 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA04524 for ; Fri, 14 Jun 2002 12:06:10 -0400 (EDT) Received: from [66.92.67.187] (BOB.MIT.EDU [18.18.1.170]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA05700 for ; Fri, 14 Jun 2002 12:06:10 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Fri, 14 Jun 2002 12:06:11 -0400 To: ietf-calendar@imc.org From: Bob Mahoney Subject: Input from the Referees Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks- Pat and I have been following the recent threads, and some small reminders may be in order... One of the few powers of the chairs is to call consensus on an issue. In this general category, some things to remember: Silence does not represent consensus. Loud voices with a particular viewpoint do not represent consensus. Pat and I will be making an effort over the next few days to review the recent list traffic for items we can consider closed. Look for such categorizing from us soon. All of our efforts, however polished we may consider them, will be subject to eventual wider review in order to advance. So our choices and design are subject to possible change as we are reviewed by the IESG and subjected to IETF Last Call. If we don't deal with important questions of design, they may well come back and bite us. We are making real efforts to narrow the scope of discussion, so that we can focus the energies of those brave souls still contributing. As we knock off each item, we will take up the next, and on until we reach a useful point. But we must be careful: we can legitimately put off some advanced functionality for a future version of the spec, but we will not succeed if we don't address essential points. It's good to be on guard against "mission creep", but if we do find some painful but necessary change is needed down the road, we do not do anyone a favor by putting it off. We've been at this for some time, and it's easy to be frustrated and fatigued. It would be best to take an extra breath before weighing in on a topic that is getting hot. We all want the same thing, and I'm sure we all wish this were finished by now. Please recognize that additional friction very much impairs our progress, and try and keep your contributions professional and open-minded. Your continued tolerance, energy, and attention are much appreciated by all. -Bob From owner-ietf-calendar@mail.imc.org Fri Jun 14 12:19:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05081 for ; Fri, 14 Jun 2002 12:19:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EGC7311551 for ietf-calendar-bks; Fri, 14 Jun 2002 09:12:07 -0700 (PDT) Received: from postman.incentivesystems.com ([65.220.90.244]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EGC6n11547 for ; Fri, 14 Jun 2002 09:12:06 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: TZID conflict MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Fri, 14 Jun 2002 12:14:55 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.10 |March 22, 2002) at 06/14/2002 12:15:04 PM, Serialize complete at 06/14/2002 12:15:04 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 4.1.1 List and Field Separators > > ... > Property parameters with values containing a COLON, a SEMICOLON or a > COMMA character MUST be placed in quoted text. > ... > >Does that solve the problem? But the ABNF says: tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF tzidprefix = "/" paramtext = *SAFE-CHAR SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-US-ASCII /=================================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=================================================================| |Vote for Ron, and nobody gets hurt! --actual campaign poster from| |Chicago | \=================================================================/ From owner-ietf-calendar@mail.imc.org Fri Jun 14 12:26:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05250 for ; Fri, 14 Jun 2002 12:26:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EGK1f12088 for ietf-calendar-bks; Fri, 14 Jun 2002 09:20:01 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EGK0n12080 for ; Fri, 14 Jun 2002 09:20:00 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5EGJvFa006469 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Jun 2002 09:20:01 -0700 Message-ID: <3D0A165B.2561B5D0@Royer.com> Date: Fri, 14 Jun 2002 10:14:19 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.or Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ITIP Clarification References: <1024051871.11883.19.camel@endspiel.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5E865CEB94DC1B802DCD5BB1" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms5E865CEB94DC1B802DCD5BB1 Content-Type: multipart/mixed; boundary="------------891DE37B423D66E47B642D3F" This is a multi-part message in MIME format. --------------891DE37B423D66E47B642D3F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit JP Rosevear wrote: > > Looking over the itip spec, I can see how the user can act on behalf of > an organizer via the sent-by property. However what is unclear to me is > if the initial event REQUEST can utilize the sent-by property because > there is no mechanism specified to inform the actual organizer that they > are indeed an event organizer. This is obviously a problem since all > replies will flow to the organizer. They flow to the organizers calendar, for which the sent-by CU would have access to the organizers calendar. This would be known by the organizer as they had given access to their administrative assistant (or whoever). So it would not be a surprise to the organizer. Even though the organizer and attendee values are email address in iMIP, they are in fact the calendar address which might or might not be the persons email address. So the MIME type could be used to intercept any replies and so it would not have to be present in the organizers e-mail in-box. Plus I think any reply would have the 'sent-by' in the organizer property - so tools would know. --------------891DE37B423D66E47B642D3F Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------891DE37B423D66E47B642D3F-- --------------ms5E865CEB94DC1B802DCD5BB1 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTQxNjE0MjJaMCMGCSqGSIb3DQEJ BDEWBBRNzrAmjsD/CsYz6SPvsRgaBS4fpjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgK36Pj868AKnCyUMTbO2ybFtOmEwlsusDUB7sRkbfYXtkxMx YZcYzgmymzRMdaCF8drwi9jrEPDwpIs2FkLEOY4QVLnpWPMO/i/Gy9KVpfe/UirmgBQQQr63 Kj55qimuRkGwJPalUNDfFbH4QQdHPMl7wwwu7BA3cem70THqv8fF --------------ms5E865CEB94DC1B802DCD5BB1-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 12:46:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05906 for ; Fri, 14 Jun 2002 12:46:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EGdNN13071 for ietf-calendar-bks; Fri, 14 Jun 2002 09:39:23 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EGdLn13067 for ; Fri, 14 Jun 2002 09:39:22 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5ECcCK08307; Fri, 14 Jun 2002 08:38:12 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: TZID conflict From: JP Rosevear To: John Stracke Cc: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 14 Jun 2002 08:38:11 -0400 Message-Id: <1024058291.8220.4.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 2002-06-14 at 12:14, John Stracke wrote: > > > 4.1.1 List and Field Separators > > > > ... > > Property parameters with values containing a COLON, a SEMICOLON or a > > COMMA character MUST be placed in quoted text. > > ... > > > >Does that solve the problem? > > But the ABNF says: > > tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF > tzidprefix = "/" > paramtext = *SAFE-CHAR > SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E > / NON-US-ASCII Exactly, tzid is paramtext, not param-value. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Jun 14 13:00:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06383 for ; Fri, 14 Jun 2002 13:00:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EGrox13758 for ietf-calendar-bks; Fri, 14 Jun 2002 09:53:50 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EGrmn13754 for ; Fri, 14 Jun 2002 09:53:49 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5ECqeS08325; Fri, 14 Jun 2002 08:52:40 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: ITIP Clarification From: JP Rosevear To: ietf-calendar@imc.org In-Reply-To: <3D0A165B.2561B5D0@Royer.com> References: <1024051871.11883.19.camel@endspiel.ximian.com> <3D0A165B.2561B5D0@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 14 Jun 2002 08:52:39 -0400 Message-Id: <1024059159.8220.14.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 2002-06-14 at 12:14, Doug Royer wrote: > JP Rosevear wrote: > > > > Looking over the itip spec, I can see how the user can act on behalf of > > an organizer via the sent-by property. However what is unclear to me is > > if the initial event REQUEST can utilize the sent-by property because > > there is no mechanism specified to inform the actual organizer that they > > are indeed an event organizer. This is obviously a problem since all > > replies will flow to the organizer. > > They flow to the organizers calendar, for which the sent-by > CU would have access to the organizers calendar. This would be > known by the organizer as they had given access to their administrative > assistant (or whoever). So it would not be a surprise to the organizer. This is assuming there is a centralized calendar store. Are you saying that with out such a store, the sent by parameter cannot be used? This seems to go against the idea of itip/imip. Also, the itip spec in 2.1.3 states: All responses from "Attendees" flow to the "Organizer" It is unspecific as to whether it means the calendar or the actual user. > Even though the organizer and attendee values are email address > in iMIP, they are in fact the calendar address which might or > might not be the persons email address. So the MIME type I think they must be exactly the email address for imip or you may be unable to respond to the correct person (ie an organizer who's caluser address is not an email address, with a sentby property, so you can't even use the from header, same situation with a mailing list). > could be used to intercept any replies and so it would not have > to be present in the organizers e-mail in-box. > Plus I think any reply would have the 'sent-by' in the organizer > property - so tools would know. They should indeed, but I'm unclear as to how this helps the situation. Are you saying the tools should send replies to the sent-by address instead? -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Jun 14 14:39:55 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09988 for ; Fri, 14 Jun 2002 14:39:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5EITPk19226 for ietf-calendar-bks; Fri, 14 Jun 2002 11:29:25 -0700 (PDT) Received: from capricorn.iris.com ([198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EITLn19220 for ; Fri, 14 Jun 2002 11:29:25 -0700 (PDT) To: "John Stracke" Cc: ietf-calendar@imc.org Subject: Re: TZID conflict MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06092002 June 09, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Jun 2002 14:14:51 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_06092002|June 09, 2002) at 06/14/2002 02:24:05 PM, Serialize complete at 06/14/2002 02:24:05 PM Content-Type: multipart/alternative; boundary="=_alternative 0065827385256BD8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0065827385256BD8_= Content-Type: text/plain; charset="US-ASCII" John noted: > But the ABNF says: > > tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF > tzidprefix = "/" > paramtext = *SAFE-CHAR > SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E > / NON-US-ASCII The ANBF should have been (and should be checked for ALL other ABNF): tzidparam = "TZID" "=" [tzidprefix] param-value CRLF since tzidparam needs both a param-text (it has "TZID") and a param-value like all other good 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 0065827385256BD8_= Content-Type: text/html; charset="US-ASCII"
John noted:
> But the ABNF says:
>
> tzidparam  = "TZID" "=" [tzidprefix] paramtext CRLF
> tzidprefix = "/"
> paramtext  = *SAFE-CHAR
> SAFE-CHAR  = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
>            / NON-US-ASCII

The ANBF should have been (and should be checked for ALL other ABNF):

tzidparam  = "TZID" "=" [tzidprefix] param-value CRLF

since tzidparam needs both a param-text (it has "TZID") and a param-value like all other good 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 0065827385256BD8_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 14:56:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10454 for ; Fri, 14 Jun 2002 14:56:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EInj719924 for ietf-calendar-bks; Fri, 14 Jun 2002 11:49:45 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EInin19919 for ; Fri, 14 Jun 2002 11:49:44 -0700 (PDT) To: Bob Mahoney Cc: ietf-calendar@imc.org Subject: Re: Focus attempt: Do new properties force a change in VERSION? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06092002 June 09, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Jun 2002 14:47:12 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_06092002|June 09, 2002) at 06/14/2002 02:44:25 PM, Serialize complete at 06/14/2002 02:44:25 PM Content-Type: multipart/alternative; boundary="=_alternative 006726AB85256BD8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006726AB85256BD8_= Content-Type: text/plain; charset="US-ASCII" Bob forwarded: > It would be like bumping the MIME-Version number > in e-mail from the current 1.0 each time someone > added a new header or mime body type. How many > mime types have been added since MIME 1.0 was > released? And MIME is still at 1.0 because the > format of the MIME object has not changed. Thats an apples/oranges comparison. From RFC 2045, the description of the intent of MIME-Version: (1) A MIME-Version header field, which uses a version number to declare a message to be conformant with MIME and allows mail processing agents to distinguish between such messages and those generated by older or non-conformant software, which are presumed to lack such a field. From RFC 2445, the description of the intent of VERSION: 4.7.4 Version Property Name: VERSION Purpose: This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to interpret the iCalendar object. In the former case, its an issue with conformance to the (MIME) standard. In the latter case its an issue of data interpretation. MIME is a framework for encapsulating mail (and other data too). iCalendar is a data format for conveying information. Had we defined VERSION to be "the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to parse the iCalendar object." then the comparison would be a valid one. We have always intended that the format of iCalendar would be A) "self contained" and B) adhere to a basic "name *(";" param ) ":" value CRLF" format (See Section 4.1 Content Lines) so we in effect have an implicitly fixed format (thus we didnt need a MIME-Version to determine how to parse the data). If we change the underlying data format then we would need to add a new property that is more equivalent to the MIME-Version (See Section 4. MIME-Version Header Field of RFC 2045 for more info there). 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 006726AB85256BD8_= Content-Type: text/html; charset="US-ASCII"
Bob forwarded:
>    It would be like bumping the MIME-Version number
>    in e-mail from the current 1.0 each time someone
>    added a new header or mime body type. How many
>    mime types have been added since MIME 1.0 was
>    released? And MIME is still at 1.0 because the
>    format of the MIME object has not changed.
Thats an apples/oranges comparison.  From RFC 2045, the description of the intent of MIME-Version:

    (1)   A MIME-Version header field, which uses a version
         number to declare a message to be conformant with MIME
         and allows mail processing agents to distinguish
         between such messages and those generated by older or
         non-conformant software, which are presumed to lack
         such a field.

From RFC 2445, the description of the intent of VERSION:

4.7.4 Version

  Property Name: VERSION

  Purpose: This property specifies the identifier corresponding to the
  highest version number or the minimum and maximum range of the
  iCalendar specification that is required in order to interpret the
  iCalendar object.

In the former case, its an issue with conformance to the (MIME) standard.  In the latter case its an issue of data interpretation.  MIME is a framework for encapsulating mail (and other data too).  iCalendar is a data format for conveying information.

Had we defined VERSION to be "the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to parse the iCalendar object." then the comparison would be a valid one.

We have always intended that the format of iCalendar would be A) "self contained" and B) adhere to a basic "name *(";" param ) ":" value CRLF" format (See Section 4.1 Content Lines) so we in effect have an implicitly fixed format (thus we didnt need a MIME-Version to determine how to parse the data).  If we change the underlying data format then we would need to add a new property that is more equivalent to the MIME-Version (See Section 4. MIME-Version Header Field of RFC 2045 for more info there).

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 006726AB85256BD8_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 15:02:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10839 for ; Fri, 14 Jun 2002 15:02:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EItsA20057 for ietf-calendar-bks; Fri, 14 Jun 2002 11:55:54 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EItqn20047 for ; Fri, 14 Jun 2002 11:55:53 -0700 (PDT) To: Bob Mahoney Cc: ietf-calendar@imc.org Subject: Re: Focus attempt: Do new properties force a change in VERSION? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06092002 June 09, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Jun 2002 14:54:48 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_06092002|June 09, 2002) at 06/14/2002 02:50:33 PM, Serialize complete at 06/14/2002 02:50:33 PM Content-Type: multipart/alternative; boundary="=_alternative 0067D8F485256BD8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0067D8F485256BD8_= Content-Type: text/plain; charset="US-ASCII" Bob forwarded: > The implication of updating the VERSION number > would be that ALL implementation of VERSION X.Y > would have to implement ALL features in A.B through > X.Y, when in fact they can be parallel an not > interacting with each other. Not true. From RFC 2445: Section 4.7.4 Version [Snip] Format Definition: The property is defined by the following notation: version = "VERSION" verparam ":" vervalue CRLF verparam = *(";" xparam) vervalue = "2.0" ;This memo / maxver / (minver ";" maxver) minver = ;Minimum iCalendar version needed to parse the iCalendar object maxver = ;Maximum iCalendar version needed to parse the iCalendar object Thus if we ever defined an X.Y that was not 'compliant' with A.B then the data would look like: VERSION:X.Y;X.Y to convey that X.Y was the minimum iCalendar version needed to grok the entity. Unless A.B is between X.Y and X.Y (or Q.R) then there is no justification for the claim. This is exactly why we did a min/max model for VERSION! 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 0067D8F485256BD8_= Content-Type: text/html; charset="US-ASCII"
Bob forwarded:
>   The implication of updating the VERSION number
>    would be that ALL implementation of VERSION X.Y
>    would have to implement ALL features in A.B through
>    X.Y, when in fact they can be parallel an not
>           interacting with each other.

Not true. From RFC 2445:

 Section 4.7.4 Version
[Snip]
   Format Definition: The property is defined by the following notation:

    version    = "VERSION" verparam ":" vervalue CRLF

    verparam   = *(";" xparam)

    vervalue   = "2.0"         ;This memo
               / maxver
               / (minver ";" maxver)

    minver     = <A IANA registered iCalendar version identifier>
    ;Minimum iCalendar version needed to parse the iCalendar object

    maxver     = <A IANA registered iCalendar version identifier>
    ;Maximum iCalendar version needed to parse the iCalendar object


Thus if we ever defined an X.Y that was not 'compliant' with A.B then the data would look like:

VERSION:X.Y;X.Y

to convey that X.Y was the minimum iCalendar version needed to grok the entity.  Unless A.B is between X.Y and X.Y (or Q.R) then there is no justification for the claim.  This is exactly why we did a min/max model for VERSION!

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 0067D8F485256BD8_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 15:34:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12546 for ; Fri, 14 Jun 2002 15:34:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EJS2n20685 for ietf-calendar-bks; Fri, 14 Jun 2002 12:28:02 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EJS1n20681 for ; Fri, 14 Jun 2002 12:28:01 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5EFQHV08562; Fri, 14 Jun 2002 11:26:17 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: TZID conflict From: JP Rosevear To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 14 Jun 2002 11:26:16 -0400 Message-Id: <1024068376.8220.19.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 2002-06-14 at 14:14, Bruce_Kahn@notesdev.ibm.com wrote: > John noted: > > But the ABNF says: > > > > tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF > > tzidprefix = "/" > > paramtext = *SAFE-CHAR > > SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E > > / NON-US-ASCII > > The ANBF should have been (and should be checked for ALL other ABNF): > > tzidparam = "TZID" "=" [tzidprefix] param-value CRLF > > since tzidparam needs both a param-text (it has "TZID") and a param-value > like all other good property parameters. One more minor point, this allows things like: /"Eastern, Nowhere DST" which is invalid for parsing i think. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Jun 14 15:38:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12756 for ; Fri, 14 Jun 2002 15:38:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EJV3H20734 for ietf-calendar-bks; Fri, 14 Jun 2002 12:31:03 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EJV1n20730 for ; Fri, 14 Jun 2002 12:31:01 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5EJV1Fa007715 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Jun 2002 12:31:03 -0700 Message-ID: <3D0A431F.560682CD@Royer.com> Date: Fri, 14 Jun 2002 13:25:19 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ITIP Clarification References: <1024051871.11883.19.camel@endspiel.ximian.com> <3D0A165B.2561B5D0@Royer.com> <1024059159.8220.14.camel@endspiel.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7BE9C43AA554F0709198F3B5" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms7BE9C43AA554F0709198F3B5 Content-Type: multipart/mixed; boundary="------------87938CA1CA74AEED6E8C10E7" This is a multi-part message in MIME format. --------------87938CA1CA74AEED6E8C10E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit JP Rosevear wrote: > > This is assuming there is a centralized calendar store. Are you saying > that with out such a store, the sent by parameter cannot be used? This > seems to go against the idea of itip/imip. Also, the itip spec in 2.1.3 > states: > > All responses from "Attendees" flow to the "Organizer" There is no requirement that it be that same persons e-mail inbox. I would assume that any CUA you have would be told where to get your calendar-inbox if it is not the same as your e-mail inbox. > It is unspecific as to whether it means the calendar or the actual user. > > > Even though the organizer and attendee values are email address > > in iMIP, they are in fact the calendar address which might or > > might not be the persons email address. So the MIME type > > I think they must be exactly the email address for imip or you may be > unable to respond to the correct person (ie an organizer who's caluser > address is not an email address, with a sentby property, so you can't > even use the from header, same situation with a mailing list). For CAP they are not e-mail addresses, so no - it does not have to be the same. In fact there is no reason that your calendar address could not be an iMIP address of mailto:jpr-calendar@ximian.com and your CUA reads from a special mail box. They just happen to often be the same. > > could be used to intercept any replies and so it would not have > > to be present in the organizers e-mail in-box. > > > Plus I think any reply would have the 'sent-by' in the organizer > > property - so tools would know. > > They should indeed, but I'm unclear as to how this helps the situation. > Are you saying the tools should send replies to the sent-by address > instead? No, I am saying that your CUA will know that 'sent-by' sent the original objects. And I would assume that 'sent-by' would still have access to your calendar and would do the work of processing any replies. Without CAP, it is unspecified how that control and handshake is done. If you have your e-mail and calendar-inbox the same, then you might want to consider writing a filter to pull out the text/calendar objects and process them so it will not just pop-up in the calendar owners e-mail inbox. --------------87938CA1CA74AEED6E8C10E7 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------87938CA1CA74AEED6E8C10E7-- --------------ms7BE9C43AA554F0709198F3B5 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTQxOTI1MjRaMCMGCSqGSIb3DQEJ BDEWBBQMTiO2Ktfs5flC3bgqZKlrwR8mXDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgAd9NrIp2Nwa1R25NWQh8XbYW9udf4wGqKnp+8Eh2Kz0dk0g fQV5vN0hF5S0nuNqHUQbVkNfhKgQDEMc//zyLatu0tk/lGZMv8NdvVe50qk1G7tR5eYfNAiu RWrIrcIq2RT6fBqoe3zvFRm+SEHcMiBO6/erMzrUI/RWW2RNj4td --------------ms7BE9C43AA554F0709198F3B5-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 15:48:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13354 for ; Fri, 14 Jun 2002 15:48:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EJfbW21235 for ietf-calendar-bks; Fri, 14 Jun 2002 12:41:37 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EJfZn21228 for ; Fri, 14 Jun 2002 12:41:35 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5EJfZFa007784 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Jun 2002 12:41:37 -0700 Message-ID: <3D0A459E.B6FA0243@Royer.com> Date: Fri, 14 Jun 2002 13:35:59 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Focus attempt: Do new properties force a change in VERSION? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAA79C182A7CE8E10FC71C68D" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msAA79C182A7CE8E10FC71C68D Content-Type: multipart/mixed; boundary="------------46FE371A1E129E6D404C8D44" This is a multi-part message in MIME format. --------------46FE371A1E129E6D404C8D44 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > ...to convey that X.Y was the minimum iCalendar version needed to grok > the entity. Unless A.B is between X.Y and X.Y (or Q.R) then there is > no justification for the claim. This is exactly why we did a > min/max model for VERSION! No, the same problem exists. If I use: VERSION:1.0;2.3 That would imply that I can process All of "1.x", "2.0, and "2.2" as well as "2.3". That is what VERSION says. The proposal that I am arguing against is that when we ADD a property we bump the protocol version. That would mean that if Ski-Cal implemented "2.1", that everyone that wanted "2.3" properties would have to implement Ski-Cal. Is that what you are saying? Or are you saying that each new property gets it own version number and we have to enumerate exactly which properties each and every object is compatible with? As in: VERSION:1.0;2.3;just-kidding-I-can't-do-2.1-ski-cal-version ;but-i-can-to-std-foo-property-version ? If so, lets eliminate CAPABILITY and move the functionallaty to VERSION by allowing one flag for each property that the CUA and CS supports. --------------46FE371A1E129E6D404C8D44 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------46FE371A1E129E6D404C8D44-- --------------msAA79C182A7CE8E10FC71C68D 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTQxOTM1NTlaMCMGCSqGSIb3DQEJ BDEWBBRtMbdhKr1NfuS0Oor9DnQ6gAh6tzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgHJC0IpDUHJsKhniOwIn8aQTYSYYinYqTsX5Kt5zOVFF+pCz NBa0YXXB5GUGmN9W+zPqUqz1ODRwr28s2loo6ChAv57dp0uoDgGOwO36JsXjNAeEcZLjN8qs ERhqvgUqj1nFdQkh9OZyD+6qyUeW6r9qRUt3rPdAXP7q9TbrYTf0 --------------msAA79C182A7CE8E10FC71C68D-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 16:18:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14136 for ; Fri, 14 Jun 2002 16:18:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EKBN621923 for ietf-calendar-bks; Fri, 14 Jun 2002 13:11:23 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EKBMn21919 for ; Fri, 14 Jun 2002 13:11:22 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5EGAEI08606; Fri, 14 Jun 2002 12:10:14 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: ITIP Clarification From: JP Rosevear To: ietf-calendar@imc.org In-Reply-To: <3D0A431F.560682CD@Royer.com> References: <1024051871.11883.19.camel@endspiel.ximian.com> <3D0A165B.2561B5D0@Royer.com> <1024059159.8220.14.camel@endspiel.ximian.com> <3D0A431F.560682CD@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 14 Jun 2002 12:10:13 -0400 Message-Id: <1024071013.8220.28.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 2002-06-14 at 15:25, Doug Royer wrote: > JP Rosevear wrote: > > > > This is assuming there is a centralized calendar store. Are you saying > > that with out such a store, the sent by parameter cannot be used? This > > seems to go against the idea of itip/imip. Also, the itip spec in 2.1.3 > > states: > > > > All responses from "Attendees" flow to the "Organizer" > > There is no requirement that it be that same persons e-mail inbox. > I would assume that any CUA you have would be told where to > get your calendar-inbox if it is not the same as your e-mail > inbox. > > > It is unspecific as to whether it means the calendar or the actual user. > > > > > Even though the organizer and attendee values are email address > > > in iMIP, they are in fact the calendar address which might or > > > might not be the persons email address. So the MIME type > > > > I think they must be exactly the email address for imip or you may be > > unable to respond to the correct person (ie an organizer who's caluser > > address is not an email address, with a sentby property, so you can't > > even use the from header, same situation with a mailing list). > > For CAP they are not e-mail addresses, so no - it does not have > to be the same. In fact there is no reason that your calendar > address could not be an iMIP address of mailto:jpr-calendar@ximian.com > and your CUA reads from a special mail box. > > They just happen to often be the same. I explicitly said "for imip". RFC 2447 in section 2.3: The calendar address specified within the "ATTENDEE" property in an iCalendar object MUST be a fully qualified, [RFC-822] address specification for the corresponding "Organizer" or "Attendee" of the "VEVENT" or "VTODO". Because [iTIP] does not preclude "Attendees" from forwarding "VEVENTS" or "VTODOS" to others, the [RFC-822] "Sender" value may not equal that of the "Organizer". Additionally, the "Organizer" or "Attendee" cannot be reliably inferred by the [RFC-822] "Sender" or "Reply-to" values of an iMIP message. The relevant address MUST be ascertained by opening the "text/calendar" MIME body part and examining the "ATTENDEE" and "ORGANIZER" properties. An RFC-822 address is an email address. I agree that under CAP you can specify something else. > > > could be used to intercept any replies and so it would not have > > > to be present in the organizers e-mail in-box. > > > > > Plus I think any reply would have the 'sent-by' in the organizer > > > property - so tools would know. > > > > They should indeed, but I'm unclear as to how this helps the situation. > > Are you saying the tools should send replies to the sent-by address > > instead? > > No, I am saying that your CUA will know that 'sent-by' sent the > original objects. And I would assume that 'sent-by' would still > have access to your calendar and would do the work of processing > any replies. Without CAP, it is unspecified how that control > and handshake is done. Then why send the email message at all? For IMIP the work should be done by the receiver of the message. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Fri Jun 14 16:51:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14845 for ; Fri, 14 Jun 2002 16:51:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EKhSe22418 for ietf-calendar-bks; Fri, 14 Jun 2002 13:43:28 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EKhRn22414 for ; Fri, 14 Jun 2002 13:43:27 -0700 (PDT) In-Reply-To: <1024068376.8220.19.camel@endspiel.ximian.com> To: JP Rosevear Cc: ietf-calendar@imc.org Subject: Re: TZID conflict MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06092002 June 09, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Jun 2002 16:43:11 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_06092002|June 09, 2002) at 06/14/2002 04:38:08 PM, Serialize complete at 06/14/2002 04:38:08 PM Content-Type: multipart/alternative; boundary="=_alternative 0071C53085256BD8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071C53085256BD8_= Content-Type: text/plain; charset="US-ASCII" JP wrote on 06/14/2002 11:26:16 AM: > > The ANBF should have been (and should be checked for ALL other ABNF): > > > > tzidparam = "TZID" "=" [tzidprefix] param-value CRLF > > > > since tzidparam needs both a param-text (it has "TZID") and a param-value > > like all other good property parameters. > > One more minor point, this allows things like: > > /"Eastern, Nowhere DST" > > which is invalid for parsing i think. Good catch. We do not need [tzidprefix] in the ABNF here since its already allowed in: param-value = paramtext / quoted-string paramtext = *SAFE-CHAR value = *VALUE-CHAR quoted-string = DQUOTE *QSAFE-CHAR DQUOTE NON-US-ASCII = %x80-F8 ; Use restricted by charset parameter ; on outer MIME object (UTF-8 preferred) QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII ; Any character except CTLs and DQUOTE SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-US-ASCII ; Any character except CTLs, DQUOTE, ";", ":", "," by resolving param-value to a quoted-string which allows the tzidprefix character to be in it (its a %x2F which is in QSAFE-CHAR already). (Anyone found the new home of Chris Newmans ABNF validator??) 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 0071C53085256BD8_= Content-Type: text/html; charset="US-ASCII"
JP wrote on 06/14/2002 11:26:16 AM:
> > The ANBF should have been (and should be checked for ALL other ABNF):
> >
> > tzidparam  = "TZID" "=" [tzidprefix] param-value CRLF
> >
> > since tzidparam needs both a param-text (it has "TZID") and a param-value
> > like all other good property parameters.
>
> One more minor point, this allows things like:
>
> /"Eastern, Nowhere DST"
>
> which is invalid for parsing i think.
Good catch.  We do not need [tzidprefix] in the ABNF here since its already allowed in:

     param-value        = paramtext / quoted-string

    paramtext  = *SAFE-CHAR

    value      = *VALUE-CHAR

    quoted-string      = DQUOTE *QSAFE-CHAR DQUOTE

    NON-US-ASCII       = %x80-F8
    ; Use restricted by charset parameter
    ; on outer MIME object (UTF-8 preferred)

    QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
    ; Any character except CTLs and DQUOTE

    SAFE-CHAR  = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
               / NON-US-ASCII
    ; Any character except CTLs, DQUOTE, ";", ":", ","
by resolving param-value to a quoted-string which allows the tzidprefix character to be in it (its a %x2F which is in QSAFE-CHAR already).

(Anyone found the new home of Chris Newmans ABNF validator??)

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 0071C53085256BD8_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 17:03:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15154 for ; Fri, 14 Jun 2002 17:03:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EKtA322627 for ietf-calendar-bks; Fri, 14 Jun 2002 13:55:10 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EKt8n22622 for ; Fri, 14 Jun 2002 13:55:08 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5EKt8Fa008241 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Jun 2002 13:55:10 -0700 Message-ID: <3D0A56DB.D66A1C7E@Royer.com> Date: Fri, 14 Jun 2002 14:49:31 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: ITIP Clarification References: <1024051871.11883.19.camel@endspiel.ximian.com> <3D0A165B.2561B5D0@Royer.com> <1024059159.8220.14.camel@endspiel.ximian.com> <3D0A431F.560682CD@Royer.com> <1024071013.8220.28.camel@endspiel.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms40680268FC2051CCA6ACD6C7" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms40680268FC2051CCA6ACD6C7 Content-Type: multipart/mixed; boundary="------------FB11FF504B9209C7F3187F35" This is a multi-part message in MIME format. --------------FB11FF504B9209C7F3187F35 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit JP Rosevear wrote: > > On Fri, 2002-06-14 at 15:25, Doug Royer wrote: > > JP Rosevear wrote: > > > > > > This is assuming there is a centralized calendar store. Are you saying > > > that with out such a store, the sent by parameter cannot be used? This > > > seems to go against the idea of itip/imip. Also, the itip spec in 2.1.3 > > > states: > > > > > > All responses from "Attendees" flow to the "Organizer" > > > > There is no requirement that it be that same persons e-mail inbox. > > I would assume that any CUA you have would be told where to > > get your calendar-inbox if it is not the same as your e-mail > > inbox. > > > > > It is unspecific as to whether it means the calendar or the actual user. > > > > > > > Even though the organizer and attendee values are email address > > > > in iMIP, they are in fact the calendar address which might or > > > > might not be the persons email address. So the MIME type > > > > > > I think they must be exactly the email address for imip or you may be > > > unable to respond to the correct person (ie an organizer who's caluser > > > address is not an email address, with a sentby property, so you can't > > > even use the from header, same situation with a mailing list). > > > > For CAP they are not e-mail addresses, so no - it does not have > > to be the same. In fact there is no reason that your calendar > > address could not be an iMIP address of mailto:jpr-calendar@ximian.com > > and your CUA reads from a special mail box. > > > > They just happen to often be the same. > > I explicitly said "for imip". RFC 2447 in section 2.3: > > The calendar address specified within the "ATTENDEE" property in an > iCalendar object MUST be a fully qualified, [RFC-822] address > specification for the corresponding "Organizer" or "Attendee" of the > "VEVENT" or "VTODO". But it does not say it must be *your* e-mail in box. It only says it must be *a* mailto URL corresponding to you. And even if it is your e-mail in box, then there is still no reason that a filter could not pull out text/calendar messages and send them to your CUA - which could notice that 'sent-by' was in the ORGANIZER and do the right thing. --------------FB11FF504B9209C7F3187F35 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------FB11FF504B9209C7F3187F35-- --------------ms40680268FC2051CCA6ACD6C7 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTQyMDQ5MzFaMCMGCSqGSIb3DQEJ BDEWBBTqhtzY8A05EBu+8RyAiBNn9vEVnzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgJjaVPTX9lzPySNHpS8UabjM/+I22cv3rcY4BMmA+6892yFr 59yIJKXyRHTBp2R7BKjbIx2KXbDvnW1IJ3qtTuEQwp/2la/6d38SYbfH6AEV0fwSZs8rRg2w QbaOWya8cSYrswHRC9Yw47zrc35iDa83AUvq2H3BTF6jGh+g35fb --------------ms40680268FC2051CCA6ACD6C7-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 17:39:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16266 for ; Fri, 14 Jun 2002 17:39:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5ELWcg24347 for ietf-calendar-bks; Fri, 14 Jun 2002 14:32:38 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ELWbn24343 for ; Fri, 14 Jun 2002 14:32:37 -0700 (PDT) In-Reply-To: <3D0A459E.B6FA0243@Royer.com> To: ietf-calendar@imc.org Subject: Re: Focus attempt: Do new properties force a change in VERSION? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06092002 June 09, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 14 Jun 2002 17:32:07 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_06092002|June 09, 2002) at 06/14/2002 05:27:18 PM, Serialize complete at 06/14/2002 05:27:18 PM Content-Type: multipart/alternative; boundary="=_alternative 0076401885256BD8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076401885256BD8_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 06/14/2002 03:35:59 PM: > If I use: > > VERSION:1.0;2.3 > > That would imply that I can process All of "1.x", "2.0, and "2.2" > as well as "2.3". That is what VERSION says. You misgrok the use of VERSION. If your CUA groks VERSION 2.2 then it would be able to parse and process the entity its parsing. It says nothing about what you as the recipient of the iCalendar can do, its what VERSION you need to grok in order to properly (or reasonably) deal with the entity you just got. We never said that just because your CUA groks 2.2 that a 1.0;2.3 message MUST have the 2.2 properties in it; it must have the 2.3 properties in it and any 1.0 or later CUA should be able to parse and process it (albeit w/some possible loss of fidelity; see REQUEST-STATUS) So, my new beefy CUA can generate a VERSION:2.0;3.3 METHOD:REQUEST and your yet-to-be-upgraded VERSION:2.0 CUA can grok it just as well as Bobs VERSION:3.1 CUA. You just wont be able to avail yourself of the 3.x additions to the REQUEST message. For example, we may have added some "Portrait" or "Pronunciation" or "Directions" properties to enhance the original REQUEST; your CUA does not need them in order to properly deal w/the new REQUEST. > The proposal that I am arguing against is that when we ADD a property > we bump the protocol version. That would mean that if Ski-Cal > implemented "2.1", that everyone that wanted "2.3" properties would have > to implement Ski-Cal. Im with you against reving VERSION unless there is a clear and compelling need to (and it cannot be satisified by another means that avoids reving VERSION). However I think that putting it in a different way may help ease some of the miscommunications. By the arguments Ive heard so far we must either make every new VERSION a superset of the prior collection of VERSIONs (at the expense of adding cruft) or we must change VERSION so that its a list of versions that the client can support (ie: VERSION:3.3,3.1,3.0,2.0 thus excluding the car rental cruft in 3.2 that I dont want). What I havent seen is any justification for these that make sense (although Ive only been able to skim the postings of late due to Real Work(TM) demands). See my example at top and iTIP, Section 3.6 Status Replies (ie: REQUEST-STATUS:3.9 or similar)... Back to the example (with tweaks): Hertz creates some car tracking stuff and proposes VERSION:2.3 and Ticketmaster creates some concert venue stuff and proposes VERSION:2.4. While there can be some 'crossover' between a car tracking system and the concert venue management system I would tend to view it as highly unlikely for the most part. (Anything is possible in C&S but I involk the 90/10 rule for how far we should contort before saying "Reality check time!"). Still better yet can someone tell me why they think that the VERSION:2.4 METHOD:REQUEST _must_ have VERSION:2.3 properties in it if it does not make sense?? We should _NOT_ be making CUAs that go "Hmm, I see VERSION:2.0,2.4 but I my maxver is 2.3 so Ill expect/assume/require that all my 2.3 properties MUST be there." Thats just bad design!! No way to spec around poor CUA design folks... Alternately, if someone needs to change an existing METHOD such that they absolutely make backwards interop impossible then they can always set the minver to be just that version and then older clients that did the right thing should be able to deal w/that (if not, they need to reread iTIP, Section 5.1 Partial Implementation and take the right approach by returning "Not Support" as the REQUEST-STATUS). > Is that what you are saying? Or are you saying that each new > property gets it own version number and we have to enumerate > exactly which properties each and every object is compatible with? Still have that question?? 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 0076401885256BD8_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 06/14/2002 03:35:59 PM:
> If I use:
>
>    VERSION:1.0;2.3
>
> That would imply that I can process All of "1.x", "2.0, and "2.2"
> as well as "2.3". That is what VERSION says.
You misgrok the use of VERSION.  If your CUA groks VERSION 2.2 then it would be able to parse and process the entity its parsing.  It says nothing about what you as the recipient of the iCalendar can do, its what VERSION you need to grok in order to properly (or reasonably) deal with the entity you just got.  We never said that just because your CUA groks 2.2 that a 1.0;2.3 message MUST have the 2.2 properties in it; it must have the 2.3 properties in it and any 1.0 or later CUA should be able to parse and process it (albeit w/some possible loss of fidelity; see REQUEST-STATUS)

So, my new beefy CUA can generate a VERSION:2.0;3.3 METHOD:REQUEST and your yet-to-be-upgraded VERSION:2.0 CUA can grok it just as well as Bobs VERSION:3.1 CUA.  You just wont be able to avail yourself of the 3.x additions to the REQUEST message.  For example, we may have added some "Portrait" or "Pronunciation" or "Directions" properties to enhance the original REQUEST; your CUA does not need them in order to properly deal w/the new REQUEST.

> The proposal that I am arguing against is that when we ADD a property
> we bump the protocol version. That would mean that if Ski-Cal
> implemented "2.1", that everyone that wanted "2.3" properties would have
> to implement Ski-Cal.
Im with you against reving VERSION unless there is a clear and compelling need to (and it cannot be satisified by another means that avoids reving VERSION).  However I think that putting it in a different way may help ease some of the miscommunications.  

By the arguments Ive heard so far we must either make every new VERSION a superset of the prior collection of VERSIONs (at the expense of adding cruft) or we must change VERSION so that its a list of versions that the client can support (ie: VERSION:3.3,3.1,3.0,2.0 thus excluding the car rental cruft in 3.2 that I dont want). What I havent seen is any justification for these that make sense (although Ive only been able to skim the postings of late due to Real Work(TM) demands).  See my example at top and iTIP, Section 3.6 Status Replies (ie: REQUEST-STATUS:3.9 or similar)...

Back to the example (with tweaks): Hertz creates some car tracking stuff and proposes VERSION:2.3 and Ticketmaster creates some concert venue stuff and proposes VERSION:2.4.

While there can be some 'crossover' between a car tracking system and the concert venue management system I would tend to view it as highly unlikely for the most part.  (Anything is possible in C&S but I involk the 90/10 rule for how far we should contort before saying "Reality check time!").  Still better yet can someone tell me why they think that the VERSION:2.4 METHOD:REQUEST _must_ have VERSION:2.3 properties in it if it does not make sense??

We should _NOT_ be making CUAs that go "Hmm, I see VERSION:2.0,2.4 but I my maxver is 2.3 so Ill expect/assume/require that all my 2.3 properties MUST be there."  Thats just bad design!!  No way to spec around poor CUA design folks...  

Alternately, if someone needs to change an existing METHOD such that they absolutely make backwards interop impossible then they can always set the minver to be just that version and then older clients that did the right thing should be able to deal w/that (if not, they need to reread iTIP, Section 5.1 Partial Implementation and take the right approach by returning "Not Support" as the REQUEST-STATUS).

> Is that what you are saying? Or are you saying that each new
> property gets it own version number and we have to enumerate
> exactly which properties each and every object is compatible with?
Still have that question??

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 0076401885256BD8_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 18:19:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17757 for ; Fri, 14 Jun 2002 18:19:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EMEVM27603 for ietf-calendar-bks; Fri, 14 Jun 2002 15:14:31 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EMETn27591 for ; Fri, 14 Jun 2002 15:14:29 -0700 (PDT) To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org, "John Stracke" , owner-ietf-calendar@mail.imc.org Subject: Re: TZID conflict MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 14 Jun 2002 18:14:15 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/14/2002 06:14:32 PM, Serialize complete at 06/14/2002 06:14:32 PM Content-Type: multipart/alternative; boundary="=_alternative 007A27CE85256BD8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007A27CE85256BD8_= Content-Type: text/plain; charset="us-ascii" Bruce, are you saying that the tzidparam line needs to be "fixed?" If so, I'll add it to the list of items needing repair on that draft. Bruce_Kahn@notesdev.ibm.com Sent by: owner-ietf-calendar@mail.imc.org 06/14/02 14:14 To: "John Stracke" cc: ietf-calendar@imc.org Subject: Re: TZID conflict John noted: > But the ABNF says: > > tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF > tzidprefix = "/" > paramtext = *SAFE-CHAR > SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E > / NON-US-ASCII The ANBF should have been (and should be checked for ALL other ABNF): tzidparam = "TZID" "=" [tzidprefix] param-value CRLF since tzidparam needs both a param-text (it has "TZID") and a param-value like all other good 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 007A27CE85256BD8_= Content-Type: text/html; charset="us-ascii"
Bruce, are you saying that the tzidparam line needs to be "fixed?"  If so, I'll add it to the list of items needing repair on that draft.


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

06/14/02 14:14

       
        To:        "John Stracke" <jstracke@incentivesystems.com>
        cc:        ietf-calendar@imc.org
        Subject:        Re: TZID conflict




John noted:
> But the ABNF says:
>
> tzidparam  = "TZID" "=" [tzidprefix] paramtext CRLF
> tzidprefix = "/"
> paramtext  = *SAFE-CHAR
> SAFE-CHAR  = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
>            / NON-US-ASCII

The ANBF should have been (and should be checked for ALL other ABNF):

tzidparam  = "TZID" "=" [tzidprefix] param-value CRLF

since tzidparam needs both a param-text (it has "TZID") and a param-value like all other good 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 007A27CE85256BD8_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 18:21:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17819 for ; Fri, 14 Jun 2002 18:21:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EMGmK27835 for ietf-calendar-bks; Fri, 14 Jun 2002 15:16:48 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EMGkn27822 for ; Fri, 14 Jun 2002 15:16:46 -0700 (PDT) To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org, JP Rosevear , owner-ietf-calendar@mail.imc.org Subject: Re: TZID conflict MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 14 Jun 2002 18:16:44 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/14/2002 06:16:50 PM, Serialize complete at 06/14/2002 06:16:50 PM Content-Type: multipart/alternative; boundary="=_alternative 007A61D585256BD8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007A61D585256BD8_= Content-Type: text/plain; charset="us-ascii" I went looking and found a site but all the links were nowhere. It seems to have vanished. I did find something done by another person at the IETF - but it was so complicated I did not bother using it. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Bruce_Kahn@notesdev.ibm.com Sent by: owner-ietf-calendar@mail.imc.org 06/14/02 16:43 To: JP Rosevear cc: ietf-calendar@imc.org Subject: Re: TZID conflict Bruce said >> (Anyone found the new home of Chris Newmans ABNF validator??) 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 007A61D585256BD8_= Content-Type: text/html; charset="us-ascii"
I went looking and found a site but all the links were nowhere.  It seems to have vanished.  I did find something done by another person at the IETF - but it was so complicated I did not bother using it.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


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

06/14/02 16:43

       
        To:        JP Rosevear <jpr@ximian.com>
        cc:        ietf-calendar@imc.org
        Subject:        Re: TZID conflict




Bruce said >> (Anyone found the new home of Chris Newmans ABNF validator??)

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 007A61D585256BD8_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 14 19:05:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18942 for ; Fri, 14 Jun 2002 19:05:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EN0Bs00835 for ietf-calendar-bks; Fri, 14 Jun 2002 16:00:11 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EN09n00831 for ; Fri, 14 Jun 2002 16:00:09 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5EMxOFa009018 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 14 Jun 2002 16:00:06 -0700 Message-ID: <3D0A749F.E8E5C881@Royer.com> Date: Fri, 14 Jun 2002 16:56:31 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Focus attempt: Do new properties force a change in VERSION? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEA7A458BA70FEC5093AC3662" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msEA7A458BA70FEC5093AC3662 Content-Type: multipart/mixed; boundary="------------C385FF1D2BBC2179A3B5F78D" This is a multi-part message in MIME format. --------------C385FF1D2BBC2179A3B5F78D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 06/14/2002 03:35:59 PM: > > If I use: > > > > VERSION:1.0;2.3 > > > > That would imply that I can process All of "1.x", "2.0, and "2.2" > > as well as "2.3". That is what VERSION says. > > You misgrok the use of VERSION. If your CUA groks VERSION 2.2 then it > would be able to parse and process the entity its parsing. It says > nothing about what you as the recipient of the iCalendar can do, its > what VERSION you need to grok in order to properly (or reasonably) > deal with the entity you just got. We never said that just because > your CUA groks 2.2 that a 1.0;2.3 message MUST have the 2.2 properties > in it; it must have the 2.3 properties in it and any 1.0 or later CUA > should be able to parse and process it (albeit w/some possible loss of > fidelity; see REQUEST-STATUS) Sure you did, how can I grok SKi-Cal:value if I don't know what it is? Is this not the same argument that is being used to bump the version (assuming you agree with that)? As in -> If we add something, bump the version so that the CUA knows what it is? If we tie the properties supported to the version number (add a property == bump the version), then the version will have no meaning other than a count of the number or properties (or property sets) that have been added. This is the TELNET have/want bug all over again. You can't tie features supported in an implementation to object version. The argument seem to be saying that as long as we don't change the format then we don't have to worry about VERSION because it is not relevant as the CUA must be able to grok it anyway. As in we can't do anything with VERSION other than know it is iCalendar 'format'. Which is why I say it does not need to change. And people can add all of the properties that they want and I can still grok the object and never care what the VERSION is as long as I know it is a supported format (but wait; I can't tell because you are saying that VERSION does not mean format VERSION) even when I don't know what the properties mean. > So, my new beefy CUA can generate a VERSION:2.0;3.3 METHOD:REQUEST and > your yet-to-be-upgraded VERSION:2.0 CUA can grok it just as well as > Bobs VERSION:3.1 CUA. So what would "3.1" mean? Nothing! It would only mean that some unknown number of properties have been added to the standard. It would have no other meaning. It would mean that no matter what the VERSION is, I must ignore it and parse the object. It would mean that I can not tell if I can parse the object until I try an maybe choke. If you have not changed the format then 3.1 would only mean it might contain some stuff, it might not, and it has nothing to do with if I know what you send me is usable by me. So what is it the version of? Not the contents, above you say I can't tell what is supported by looking at the version (And I agree). So what is it the version of? Is it not then just a counter of the number of properties that have been registered? What good is that? > You just wont be able to avail yourself of the > 3.x additions to the REQUEST message. For example, we may have added > some "Portrait" or "Pronunciation" or "Directions" properties to > enhance the original REQUEST; your CUA does not need them in order to > properly deal w/the new REQUEST. I agree, so what does 3.1 tell my parser? > > The proposal that I am arguing against is that when we ADD a > > property we bump the protocol version. That would mean that > > if Ski-Cal implemented "2.1", that everyone that wanted "2.3" > > properties would have to implement Ski-Cal. > > Im with you against reving VERSION unless there is a clear and > compelling need to (and it cannot be satisified by another means that > avoids reving VERSION). However I think that putting it in a > different way may help ease some of the miscommunications. Thanks, I don't see that we have changed iTIP in an incompatible way. (METHOD is again only iTIP) And that is the ONLY thing that will be effected by CAP changes. There is NO production CAP-CUA now, so nothing between any CS and any CAP-CUA will break. The ONLY thing that is going to be added (as Bernard pointed out) is that TARGET will be added in the protocol between the CUA and the CS, that in no way effects iMIP. And if I sent you an iMIP message with TARGET in it, will it break your CUA - I'll bet not. > By the arguments Ive heard so far we must either make every new > VERSION a superset of the prior collection of VERSIONs ... > .. or we must change VERSION so that its a list of versions that > the client can support ... > > Back to the example (with tweaks): Hertz creates some car tracking > stuff and proposes VERSION:2.3 and Ticketmaster creates some concert > venue stuff and proposes VERSION:2.4. > > While there can be some 'crossover' between a car tracking system and > the concert venue management system I would tend to view it as highly > unlikely for the most part. ... > > We should _NOT_ be making CUAs that go "Hmm, I see VERSION:2.0,2.4 but > I my maxver is 2.3 so Ill expect/assume/require that all my 2.3 > properties MUST be there." Thats just bad design!! No way to spec > around poor CUA design folks... I agree. > Alternately, if someone needs to change an existing METHOD such that > they absolutely make backwards interop impossible then they can always > set the minver to be just that version and then older clients that did > the right thing should be able to deal w/that (if not, they need to > reread iTIP, Section 5.1 Partial Implementation and take the right > approach by returning "Not Support" as the REQUEST-STATUS). I agree. > > Is that what you are saying? Or are you saying that each new > > property gets it own version number and we have to enumerate > > exactly which properties each and every object is compatible with? > > Still have that question?? I think we agree. There is no reason to bump the version as nothing between the CUA and a CS will effect iMIP. And only iMIP implementations will be effected if we (as in your example) change METHOD (which we will not). -Doug --------------C385FF1D2BBC2179A3B5F78D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------C385FF1D2BBC2179A3B5F78D-- --------------msEA7A458BA70FEC5093AC3662 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTQyMjU2MzFaMCMGCSqGSIb3DQEJ BDEWBBTk9a5ipyHp77vbSWgSduMtWX3hKzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgKOR3SD/XPVXygFbHmuYi5yAahk0zhXkPxqxedKyuMlPC8dQ K+4iWbwlhK1XiXjoxh8iZeBdU3vFHsijnDgypAyI1Tkhtj6PrApiLaFj/JzQupzcE6Aywqbm iiJKnRo3lnYGb9m5+8HGEO2heoOeShla3quXv6Jaro8cxBNWaZdE --------------msEA7A458BA70FEC5093AC3662-- From owner-ietf-calendar@mail.imc.org Mon Jun 17 10:58:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06554 for ; Mon, 17 Jun 2002 10:58:02 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5HElUW09371 for ietf-calendar-bks; Mon, 17 Jun 2002 07:47:30 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HElRn09365 for ; Mon, 17 Jun 2002 07:47:27 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5HEjw510273; Mon, 17 Jun 2002 10:45:58 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: ITIP Clarification From: JP Rosevear To: ietf-calendar@imc.org In-Reply-To: <3D0A56DB.D66A1C7E@Royer.com> References: <1024051871.11883.19.camel@endspiel.ximian.com> <3D0A165B.2561B5D0@Royer.com> <1024059159.8220.14.camel@endspiel.ximian.com> <3D0A431F.560682CD@Royer.com> <1024071013.8220.28.camel@endspiel.ximian.com> <3D0A56DB.D66A1C7E@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 17 Jun 2002 10:45:57 -0400 Message-Id: <1024325157.9173.6.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Fri, 2002-06-14 at 16:49, Doug Royer wrote: > JP Rosevear wrote: > > > > On Fri, 2002-06-14 at 15:25, Doug Royer wrote: > But it does not say it must be *your* e-mail in box. > > It only says it must be *a* mailto URL corresponding to you. > > And even if it is your e-mail in box, then there is still > no reason that a filter could not pull out text/calendar > messages and send them to your CUA - which could notice > that 'sent-by' was in the ORGANIZER and do the right thing. Granted, but this is not something in the scope of the imip or itip spec so there is no standard mechanism for this. Even if there was, when there is no centralized server it is likely beholden to the user to perform this task. In my mind this is making sent-by not really useable generally for the case of email only scheduling. There is still no formal mechanism for creating a meeting with, for instance: ORGANIZER;SENTBY:jpr@ximian.com:doug@royer.com And having a copy of the meeting be sent to you for your calendar and then having replies flow to you. Without that mechanism you may get attendes REPLY messages without knowing what they are for. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Mon Jun 17 11:58:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08669 for ; Mon, 17 Jun 2002 11:58:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HFlSu13274 for ietf-calendar-bks; Mon, 17 Jun 2002 08:47:28 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HFlPn13264 for ; Mon, 17 Jun 2002 08:47:25 -0700 (PDT) In-Reply-To: To: pregen@egenconsulting.com Cc: ietf-calendar@imc.org, "John Stracke" Subject: Re: TZID conflict MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06092002 June 09, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 17 Jun 2002 11:47:14 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_06092002|June 09, 2002) at 06/17/2002 11:41:46 AM, Serialize complete at 06/17/2002 11:41:46 AM Content-Type: multipart/alternative; boundary="=_alternative 00569C3785256BDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00569C3785256BDB_= Content-Type: text/plain; charset="US-ASCII" Pat asked on 06/14/2002 06:14:15 PM: > Bruce, are you saying that the tzidparam line needs to be "fixed?" > If so, I'll add it to the list of items needing repair on that draft. Yes I am but as JP later noted the correction should be to change: tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF to: tzidparam = "TZID" "=" param-value CRLF since the optional tzidprefix could be incorrectly inserted before a dquoted string causing some parsing errors. I also think we (the Royal 'we') should take another look at all the property parameters to make sure we correct them all in a similar manner if need be. JP: Did you notice any other similar problems? 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 00569C3785256BDB_= Content-Type: text/html; charset="US-ASCII"
Pat asked on 06/14/2002 06:14:15 PM:
> Bruce, are you saying that the tzidparam line needs to be "fixed?"  
> If so, I'll add it to the list of items needing repair on that draft.

Yes I am but as JP later noted the correction should be to change:

        tzidparam  = "TZID" "=" [tzidprefix] paramtext CRLF
to:

        tzidparam  = "TZID" "=" param-value CRLF

since the optional tzidprefix could be incorrectly inserted before a dquoted string causing some parsing errors.

I also think we (the Royal 'we') should take another look at all the property parameters to make sure we correct them all in a similar manner if need be.

JP: Did you notice any other similar problems?

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 00569C3785256BDB_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 17 12:58:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11421 for ; Mon, 17 Jun 2002 12:58:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HGgR515943 for ietf-calendar-bks; Mon, 17 Jun 2002 09:42:27 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HGgQn15939 for ; Mon, 17 Jun 2002 09:42:26 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5HGgPFa020893 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 17 Jun 2002 09:42:27 -0700 Message-ID: <3D0E10A4.D7A5BEDD@Royer.com> Date: Mon, 17 Jun 2002 10:39:00 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: ietf-calendar@imc.org Subject: Re: ITIP Clarification References: <1024051871.11883.19.camel@endspiel.ximian.com> <3D0A165B.2561B5D0@Royer.com> <1024059159.8220.14.camel@endspiel.ximian.com> <3D0A431F.560682CD@Royer.com> <1024071013.8220.28.camel@endspiel.ximian.com> <3D0A56DB.D66A1C7E@Royer.com> <1024325157.9173.6.camel@endspiel.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms873F66AF9FFD59C3DABB1737" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms873F66AF9FFD59C3DABB1737 Content-Type: multipart/mixed; boundary="------------8B1342D24851F1128106E781" This is a multi-part message in MIME format. --------------8B1342D24851F1128106E781 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit JP Rosevear wrote: > Granted, but this is not something in the scope of the imip or itip spec > so there is no standard mechanism for this. Even if there was, when > there is no centralized server it is likely beholden to the user to > perform this task. In my mind this is making sent-by not really useable > generally for the case of email only scheduling. There is still no > formal mechanism for creating a meeting with, for instance: > > ORGANIZER;SENTBY:jpr@ximian.com:doug@royer.com > > And having a copy of the meeting be sent to you for your calendar and > then having replies flow to you. Without that mechanism you may get > attendes REPLY messages without knowing what they are for. If you are asking if there are applications that do this correctly: Yes there are. If you are asking how to do this: You need to write, borrow, or buy a mail filter. And your right, this is out of scope for RFC244[567] and CAP. --------------8B1342D24851F1128106E781 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------8B1342D24851F1128106E781-- --------------ms873F66AF9FFD59C3DABB1737 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTcxNjM5MDBaMCMGCSqGSIb3DQEJ BDEWBBSgASLU2u/+XPDSEIHBGBzz7y6GCTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgIbM3/RYirj19VIkk+0vb14y+o1jRxu+klunSri46BZ0xWFO LyZid9fgr772VVu3ktSxK/68lwasf41zbW9/smGdUXMSCdfFe4eF4Ep3UOLhgYNljtYYOVVf YbzeibmP3KZupfg/zpYX0aB0UI7K0nBarjfkB6aVTuMXaHNxEXbg --------------ms873F66AF9FFD59C3DABB1737-- From owner-ietf-calendar@mail.imc.org Mon Jun 17 13:17:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12148 for ; Mon, 17 Jun 2002 13:17:23 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5HHAEZ16497 for ietf-calendar-bks; Mon, 17 Jun 2002 10:10:14 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HHACn16493 for ; Mon, 17 Jun 2002 10:10:12 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5HH8l413552; Mon, 17 Jun 2002 13:08:47 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: TZID conflict From: JP Rosevear To: Bruce_Kahn@notesdev.ibm.com Cc: pregen@egenconsulting.com, ietf-calendar@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 17 Jun 2002 13:08:47 -0400 Message-Id: <1024333727.13300.17.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Mon, 2002-06-17 at 11:47, Bruce_Kahn@notesdev.ibm.com wrote: > Pat asked on 06/14/2002 06:14:15 PM: > > Bruce, are you saying that the tzidparam line needs to be "fixed?" > > If so, I'll add it to the list of items needing repair on that draft. > > Yes I am but as JP later noted the correction should be to change: > > tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF > > to: > > tzidparam = "TZID" "=" param-value CRLF > > since the optional tzidprefix could be incorrectly inserted before a > dquoted string causing some parsing errors. > > I also think we (the Royal 'we') should take another look at all the > property parameters to make sure we correct them all in a similar manner > if need be. > > JP: Did you notice any other similar problems? No, but I wasn't specifically looking. I just found it doing some spec reading after some interop failures wrt TZIDs. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Mon Jun 17 13:27:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12507 for ; Mon, 17 Jun 2002 13:27:36 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5HHMVj16836 for ietf-calendar-bks; Mon, 17 Jun 2002 10:22:31 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HHMTn16832 for ; Mon, 17 Jun 2002 10:22:29 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5HHKx413617; Mon, 17 Jun 2002 13:20:59 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: ITIP Clarification From: JP Rosevear To: Doug Royer Cc: "ietf-calendar@imc.org" In-Reply-To: <3D0E10A4.D7A5BEDD@Royer.com> References: <1024051871.11883.19.camel@endspiel.ximian.com> <3D0A165B.2561B5D0@Royer.com> <1024059159.8220.14.camel@endspiel.ximian.com> <3D0A431F.560682CD@Royer.com> <1024071013.8220.28.camel@endspiel.ximian.com> <3D0A56DB.D66A1C7E@Royer.com> <1024325157.9173.6.camel@endspiel.ximian.com> <3D0E10A4.D7A5BEDD@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 17 Jun 2002 13:20:59 -0400 Message-Id: <1024334459.13225.19.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Mon, 2002-06-17 at 12:39, Doug Royer wrote: > JP Rosevear wrote: > > > Granted, but this is not something in the scope of the imip or itip spec > > so there is no standard mechanism for this. Even if there was, when > > there is no centralized server it is likely beholden to the user to > > perform this task. In my mind this is making sent-by not really useable > > generally for the case of email only scheduling. There is still no > > formal mechanism for creating a meeting with, for instance: > > > > ORGANIZER;SENTBY:jpr@ximian.com:doug@royer.com > > > > And having a copy of the meeting be sent to you for your calendar and > > then having replies flow to you. Without that mechanism you may get > > attendes REPLY messages without knowing what they are for. > > If you are asking if there are applications that do this correctly: > Yes there are. How can you judge correctness without a standard? > If you are asking how to do this: You need to write, borrow, > or buy a mail filter. And your right, this is out of scope > for RFC244[567] and CAP. Ok, this is what I thought. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Mon Jun 17 13:59:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14062 for ; Mon, 17 Jun 2002 13:59:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HHrWk18920 for ietf-calendar-bks; Mon, 17 Jun 2002 10:53:32 -0700 (PDT) Received: from postman.incentivesystems.com ([65.220.90.244]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HHrKn18912 for ; Mon, 17 Jun 2002 10:53:30 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Focus attempt: Do new properties force a change in VERSION? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Mon, 17 Jun 2002 13:56:13 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.10 |March 22, 2002) at 06/17/2002 01:56:40 PM, Serialize complete at 06/17/2002 01:56:40 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >As in we can't >do anything with VERSION other than know it is iCalendar 'format'. But iCalendar "format" is not defined anywhere. Only iCalendar is defined. (This is actually one of my major gripes with 2445: it is intuitively clear that there is a format, but its definition is intermingled with the property definitions.) /===========================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |===========================================================| |Sleep is for wimps--healthy, well-adjusted wimps, but wimps| |nonetheless. | \===========================================================/ From owner-ietf-calendar@mail.imc.org Mon Jun 17 14:19:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14822 for ; Mon, 17 Jun 2002 14:19:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HIC1w19637 for ietf-calendar-bks; Mon, 17 Jun 2002 11:12:01 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HIC0n19630 for ; Mon, 17 Jun 2002 11:12:00 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5HIBvpf031953 for ; Mon, 17 Jun 2002 14:11:57 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5HIBu624079 for ; Mon, 17 Jun 2002 14:11:56 -0400 (EDT) Message-ID: <3D0E2766.16739E4A@steltor.com> Date: Mon, 17 Jun 2002 14:16:06 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: TZID conflict References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: > > Pat asked on 06/14/2002 06:14:15 PM: > > Bruce, are you saying that the tzidparam line needs to be "fixed?" > > If so, I'll add it to the list of items needing repair on that > draft. > > Yes I am but as JP later noted the correction should be to change: > > tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF > > to: > > tzidparam = "TZID" "=" param-value CRLF > > since the optional tzidprefix could be incorrectly inserted before a > dquoted string causing some parsing errors. I assume that iCalendar parsers will need to look at the VERSION property to figure which version of the tzidparam rule part to use when parsing iCalendar objects. Correct? Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Mon Jun 17 14:35:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15514 for ; Mon, 17 Jun 2002 14:35:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HIRkC20009 for ietf-calendar-bks; Mon, 17 Jun 2002 11:27:46 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HIRjn20003 for ; Mon, 17 Jun 2002 11:27:45 -0700 (PDT) In-Reply-To: <3D0A749F.E8E5C881@Royer.com> To: ietf-calendar@imc.org Subject: Re: Focus attempt: Do new properties force a change in VERSION? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06092002 June 09, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 17 Jun 2002 14:27:21 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_06092002|June 09, 2002) at 06/17/2002 02:22:03 PM, Serialize complete at 06/17/2002 02:22:03 PM Content-Type: multipart/alternative; boundary="=_alternative 006544EB85256BDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006544EB85256BDB_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 06/14/2002 06:56:31 PM: > > You misgrok the use of VERSION. If your CUA groks VERSION 2.2 then it > > would be able to parse and process the entity its parsing. It says > > nothing about what you as the recipient of the iCalendar can do, its > > what VERSION you need to grok in order to properly (or reasonably) > > deal with the entity you just got. We never said that just because > > your CUA groks 2.2 that a 1.0;2.3 message MUST have the 2.2 properties > > in it; it must have the 2.3 properties in it and any 1.0 or later CUA > > should be able to parse and process it (albeit w/some possible loss of > > fidelity; see REQUEST-STATUS) > > Sure you did, how can I grok SKi-Cal:value if I don't know what > it is? No we didnt. Where in the RFC did we state that? You can _parse_ it as it must follow the format rules (see Section 4.1 again). _Interpreting_ its full meaning is something that only a VERSION 2.1 (or whatever) client can do. That does NOT meant that an older client cannot necessarily grok it. A METHOD:REQUEST has straighforward semantic. You may not grok the meaning of the newer 2.1 properties but you can still make a reasonable response to the REQUEST AND you can convey back to the Organizer that you may not have grok'd it w/the same fidelity as a newer CUA. Section 5 Application Protocol Fallbacks of iTIP discusses dealing with new METHODs and similar logic should also apply to VERSION (although we never expresslly put it into any RFC text, we glanced over it when we defined minver and maxver in iCalendar). > Is this not the same argument that is being used to > bump the version (assuming you agree with that)? > As in -> If we add something, bump the version so that the CUA > knows what it is? Maybe its me but I dont see that this is necessarily a problem as long as the additions do no cause a problem for older clients. Thats part of why we put in maxver and minver in the first place! If the changes are such that they are not backwards compatable then the minver gets set accordingly (OR a new METHOD is created!). Either way the receiving CUA should be able to deal w/it if it was coded properly. It is the job of the WG to make sure that any changes/additions in the future do not cause problems and that the changes/additions are done "the right way" and that harmony is maintained. > If we tie the properties supported to the version number (add a > property == bump the version), then the version will have no > meaning other than a count of the number or properties (or > property sets) that have been added. Just what do you think the use/intent of minver and maxver is? They delimit the set of CUAs that can properly (or reasonbly) grok the iCalendar stream. If some addition/change in the future decided to mangle a previously defined METHOD requires that a minver of something other than "2.0" be sent then Id have to question its change instead of defining a new METHOD value instead. Still it could happen (ie: in order to fix a serious problem that was overlooked before)... > The argument seem to be saying that as long as we don't change the > format then we don't have to worry about VERSION because it is not > relevant as the CUA must be able to grok it anyway. As in we can't > do anything with VERSION other than know it is iCalendar 'format'. No, no, no. Perhaps its the term 'format' that makes me hop up an down so Ill try to restate this as clearly as I can: VERSION does not specify the parsing format of the data, it specifies the (minimum and) maximum versions of a CUA that are required to _understand_ the parsed content. The parsing/content 'format' is defined in Section 4.1 and if that changes then we need to define a different way to detect and deal with it since it would be potentially impossible for an older CUA to even parse the new format to discover that it did not know how to even parse it (let alone understand it). In this case a new MIME type/subtype would probably be in order. If we change the semantics of a METHOD thats already defined in such a way that only newer CUAs can grok it (grok != parse; grok == understand) then that is when a VERSION with a minval higher than the current 2.0 would be necessary. Adding new 'features' does not (NOR should it!!) change the semantics of an already defined METHOD. > (but wait; I can't tell because you are saying that VERSION > does not mean format VERSION) even when I don't know what the > properties mean. VERSION does not and never has meant "format" VERSION. Dont know where that concept came from. From 2445: Purpose: This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to interpret the iCalendar object. (Emphasis mine). That seems pretty clear to me. Where does it mislead one to think its a format issue? > So what would "3.1" mean? Nothing! It would only mean that > some unknown number of properties have been added to the > standard. It would have no other meaning. They are not "unknown"; they would have to be codified in some RFC. Just because your already written/shipping CUA does not know what they are does not mean that VERSION has no meaning. It tells your CUA that there are properties in the iCalendar that it may not know how to interpret but the minver indicates that you can still properly interpret the METHOD (albeit w/o benefit of the newer properties). My VERSION 2.0;2.0 CUA may not understand the VEHICLE;TYPE=CAR:MID-SIZE in the new Hertz VERSION:2.2 REQUEST but its not necessary for me to in order to accept the REQUEST or COUNTER it. It may even be smart enough to put in a REQUEST-STATUS value to indicate that some fallback was taken for the entry. If your CUA got a VERSION:3.0;3.5 REQUEST and its just VERSION:2.0 then it should do the correct thing and send back a REPLY with "REQUEST-STATUS:3.9;Unsupported version.;I only understand a minver 2.0 REQUEST" (See 3.6 Status Replies of iTIP). > It would mean that no matter what the VERSION is, I must ignore > it and parse the object. It would mean that I can not tell if I > can parse the object until I try an maybe choke. Again, VERSION does not and never has meant "format" VERSION. See above. Also, since VERSION and METHOD appear in the stream before the other container subcomponents (ie: VEVENT) then you only have to parse some of the stream to know that you wont be able to understand the METHOD (or the VERSION). You will still have to find some way to scan over or parse over the entries since more than 1 iCalendar stream may exist in the data stream body as we defined it (See Section 4.4 iCalendar Object). However parsing is NOT the concern as long as the rules in Section 4.1 are adhered to; its only interpretation of whats parsed. > If you have not > changed the format then 3.1 would only mean it might contain some > stuff, it might not, and it has nothing to do with if I know what > you send me is usable by me. NOT a _format_ change, an interpretation change. Ill keep pointing this out as long as it takes... > I agree, so what does 3.1 tell my parser? Nothing. It tells your processing engine something though! > > We should _NOT_ be making CUAs that go "Hmm, I see VERSION:2.0,2.4 but > > I my maxver is 2.3 so Ill expect/assume/require that all my 2.3 > > properties MUST be there." Thats just bad design!! No way to spec > > around poor CUA design folks... > > I agree. We usually do. We just have to overcome our initial communication issues. 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 006544EB85256BDB_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 06/14/2002 06:56:31 PM:
> > You misgrok the use of VERSION.  If your CUA groks VERSION 2.2 then it
> > would be able to parse and process the entity its parsing. It says
> > nothing about what you as the recipient of the iCalendar can do, its
> > what VERSION you need to grok in order to properly (or reasonably)
> > deal with the entity you just got. We never said that just because
> > your CUA groks 2.2 that a 1.0;2.3 message MUST have the 2.2 properties
> > in it; it must have the 2.3 properties in it and any 1.0 or later CUA
> > should be able to parse and process it (albeit w/some possible loss of
> > fidelity; see REQUEST-STATUS)
>
> Sure you did, how can I grok SKi-Cal:value if I don't know what
> it is?

No we didnt.  Where in the RFC did we state that?

You can _parse_ it as it must follow the format rules (see Section 4.1 again).  _Interpreting_ its full meaning is something that only a VERSION 2.1 (or whatever) client can do.  That does NOT meant that an older client cannot necessarily grok it.  

A METHOD:REQUEST has straighforward semantic.  You may not grok the meaning of the newer 2.1 properties but you can still make a reasonable response to the REQUEST AND you can convey back to the Organizer that you may not have grok'd it w/the same fidelity as a newer CUA.  

Section 5 Application Protocol Fallbacks of iTIP discusses dealing with new METHODs and similar logic should also apply to VERSION (although we never expresslly put it into any RFC text, we glanced over it when we defined minver and maxver in iCalendar).

>        Is this not the same argument that is being used to
> bump the version (assuming you agree with that)?
> As in -> If we add something, bump the version so that the CUA
> knows what it is?
Maybe its me but I dont see that this is necessarily a problem as long as the additions do no cause a problem for older clients.  Thats part of why we put in maxver and minver in the first place!  If the changes are such that they are not backwards compatable then the minver gets set accordingly (OR a new METHOD is created!).  Either way the receiving CUA should be able to deal w/it if it was coded properly.

It is the job of the WG to make sure that any changes/additions in the future do not cause problems and that the changes/additions are done "the right way" and that harmony is maintained.

> If we tie the properties supported to the version number (add a
> property == bump the version), then the version will have no
> meaning other than a count of the number or properties (or
> property sets) that have been added.
Just what do you think the use/intent of minver and maxver is?  They delimit the set of CUAs that can properly (or reasonbly) grok the iCalendar stream.  If some addition/change in the future decided to mangle a previously defined METHOD requires that a minver of something other than "2.0" be sent then Id have to question its change instead of defining a new METHOD value instead.  Still it could happen (ie: in order to fix a serious problem that was overlooked before)...

> The argument seem to be saying that as long as we don't change the
> format then we don't have to worry about VERSION because it is not
> relevant as the CUA must be able to grok it anyway. As in we can't
> do anything with VERSION other than know it is iCalendar 'format'.
No, no, no.  Perhaps its the term 'format' that makes me hop up an down so Ill try to restate this as clearly as I can:

VERSION does not specify the parsing format of the data, it specifies the (minimum and) maximum versions of a CUA that are required to _understand_ the parsed content.  

The parsing/content 'format' is defined in Section 4.1 and if that changes then we need to define a different way to detect and deal with it since it would be potentially impossible for an older CUA to even parse the new format to discover that it did not know how to even parse it (let alone understand it).  In this case a new MIME type/subtype would probably be in order.

If we change the semantics of a METHOD thats already defined in such a way that only newer CUAs can grok it (grok != parse; grok == understand) then that is when a VERSION with a minval higher than the current 2.0 would be necessary.  Adding new 'features' does not (NOR should it!!) change the semantics of an already defined METHOD.  

>       (but wait; I can't tell because you are saying that VERSION
> does not mean format VERSION) even when I don't know what the
> properties mean.
VERSION does not and never has meant "format" VERSION.  Dont know where that concept came from.

From 2445:

   Purpose: This property specifies the identifier corresponding to the
  highest version number or the minimum and maximum range of the
  iCalendar specification that is required in order to interpret the
  iCalendar object.

(Emphasis mine).  That seems pretty clear to me.  Where does it mislead one to think its a format issue?

> So what would "3.1" mean? Nothing!  It would only mean that
> some unknown number of properties have been added to the
> standard. It would have no other meaning.
They are not "unknown"; they would have to be codified in some RFC.  

Just because your already written/shipping CUA does not know what they are does not mean that VERSION has no meaning.  It tells your CUA that there are properties in the iCalendar that it may not know how to interpret but the minver indicates that you can still properly interpret the METHOD (albeit w/o benefit of the newer properties).   My VERSION 2.0;2.0 CUA may not understand the VEHICLE;TYPE=CAR:MID-SIZE in the new Hertz VERSION:2.2 REQUEST but its not necessary for me to in order to accept the REQUEST or COUNTER it.  It may even be smart enough to put in a REQUEST-STATUS value to indicate that some fallback was taken for the entry.

If your CUA got a VERSION:3.0;3.5 REQUEST and its just VERSION:2.0 then it should do the correct thing and send back a REPLY with "REQUEST-STATUS:3.9;Unsupported version.;I only understand a minver 2.0 REQUEST" (See 3.6 Status Replies of iTIP).

> It would mean that no matter what the VERSION is, I must ignore
> it and parse the object. It would mean that I can not tell if I
> can parse the object until I try an maybe choke.

Again, VERSION does not and never has meant "format" VERSION.    See above.

Also, since VERSION and METHOD appear in the stream before the other container subcomponents (ie: VEVENT) then  you only have to parse some of the stream to know that you wont be able to understand the METHOD (or the VERSION).  You will still have to find some way to scan over or parse over the entries since more than 1 iCalendar stream may exist in the data stream body as we defined it (See Section 4.4 iCalendar Object).  However parsing is NOT the concern as long as the rules in Section 4.1 are adhered to; its only interpretation of whats parsed.

>                                                  If you have not
> changed the format then 3.1 would only mean it might contain some
> stuff, it might not, and it has nothing to do with if I know what
> you send me is usable by me.

NOT a _format_ change, an interpretation change.  Ill keep pointing this out as long as it takes...

> I agree, so what does 3.1 tell my parser?
Nothing.  It tells your processing engine something though!

> > We should _NOT_ be making CUAs that go "Hmm, I see VERSION:2.0,2.4 but
> > I my maxver is 2.3 so Ill expect/assume/require that all my 2.3
> > properties MUST be there."  Thats just bad design!!  No way to spec
> > around poor CUA design folks...
>
> I agree.
We usually do.  We just have to overcome our initial communication issues.

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 006544EB85256BDB_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 17 14:51:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16171 for ; Mon, 17 Jun 2002 14:51:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HIkUZ21781 for ietf-calendar-bks; Mon, 17 Jun 2002 11:46:30 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HIkTn21777 for ; Mon, 17 Jun 2002 11:46:29 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5HIkSFa022072 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 17 Jun 2002 11:46:31 -0700 Message-ID: <3D0E2DB6.D601E1E5@Royer.com> Date: Mon, 17 Jun 2002 12:43:02 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I did a checkin of CAP] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms12B4710755EFD218104DE354" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms12B4710755EFD218104DE354 Content-Type: multipart/mixed; boundary="------------72860EE2D9EA551CF58539E7" This is a multi-part message in MIME format. --------------72860EE2D9EA551CF58539E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit An INTERIM version of CAP is available at: http://INET-Consulting.com/CAP-16-JUN-2002.txt Please note that we hope to push the next official version of CAP before the 24th cutoff date. (just because we want to get it out.) Please send ME email for typo's (mailto:Doug@Royer.com). Please send what you think are changes that need to be made to CAP - to this list (mailto:ietf-calendar@imc.org). It was my intent to consolidate the list information. I suspect as usual there will be issues - please we are open - just send the objective facts of any issues. I took text from -05, -06, and -07, and I am still comparing for missing or extra text. THIS IS STILL work in progress. I have a list of 20 or so things left. Look for "TODO" where I spotted these in the draft. Double check to see that all properties and components have a definition section. (some missing). Add definitions for STATE(), OWNER(), NONOWNER(), CAL-QL and other CAP-QL text missing. Text to describe how to store and fetch pre-defined or stored VQUERYs. Double check all work. I went through and changed all descriptions to use common phrases and terminology. I organized and alphabetized the properties and components. They were by section, however I think the sections leading up to the property descriptions give the summary. In a few places I combined 2 or 3 sections into one section. (VCARs for example) There is more text to be added, mostly properties and CAP-QL statements that were not defined, but used. -Doug --------------72860EE2D9EA551CF58539E7 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------72860EE2D9EA551CF58539E7-- --------------ms12B4710755EFD218104DE354 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTcxODQzMDJaMCMGCSqGSIb3DQEJ BDEWBBR9RafXs4ehG5r8I50nMQmUaGnCYzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgHcs7noMsh2g+DPyTn7ZuRcP+Mmqmkaxo02lofY/ryHtUMbp Crib9+9De7s2Eo6FAgvk1tTM+iHwwom/Bium5UEeuB6dfVi6u8k2mgoYpQYfM+w/CCfc0qBF I8bmosC585zCB3QlB7RfiLsWNoFAJIpxnZ7j/ZK/Y9WEpx9h/t7E --------------ms12B4710755EFD218104DE354-- From owner-ietf-calendar@mail.imc.org Mon Jun 17 15:00:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16511 for ; Mon, 17 Jun 2002 15:00:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HIsJQ22688 for ietf-calendar-bks; Mon, 17 Jun 2002 11:54:19 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HIsIn22681 for ; Mon, 17 Jun 2002 11:54:18 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5HIsHFa022123 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 17 Jun 2002 11:54:19 -0700 Message-ID: <3D0E2F8B.A707CFBC@Royer.com> Date: Mon, 17 Jun 2002 12:50:51 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: TZID conflict References: <3D0E2766.16739E4A@steltor.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7CC28381C1676B0774C12178" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms7CC28381C1676B0774C12178 Content-Type: multipart/mixed; boundary="------------3F935299DFFD023039AC9C68" This is a multi-part message in MIME format. --------------3F935299DFFD023039AC9C68 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I assume that iCalendar parsers will need to look at the > VERSION property to figure which version of the tzidparam > rule part to use when parsing iCalendar objects. The ABNF bug makes no differance because a well written iCal parser and generator would have placed them in quotes anyway: IN 2445: 4.1.1 List and Field Separators ... Property parameters with values containing a COLON, a SEMICOLON or a COMMA character MUST be placed in quoted text. ... --------------3F935299DFFD023039AC9C68 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------3F935299DFFD023039AC9C68-- --------------ms7CC28381C1676B0774C12178 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTcxODUwNTFaMCMGCSqGSIb3DQEJ BDEWBBT9u4+w7JZrkclfdbVE2KWToXGNLDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgATibu2Ygc5GafQdubXQqDx4fP4sp2SlSBSf85+fhJsiLosB MpDoe1McxxDq7FBpmuS0WONlIbSuMZhBXFUc3U7GS6mATFUTVqugGyUiXTwf7kI52gSOL3cL eTZos8pe+4FqJVzD8/strdjvJ0A+b516OfgRiz/y8IWXmRm3D6dU --------------ms7CC28381C1676B0774C12178-- From owner-ietf-calendar@mail.imc.org Mon Jun 17 16:26:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18899 for ; Mon, 17 Jun 2002 16:26:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HKG1127810 for ietf-calendar-bks; Mon, 17 Jun 2002 13:16:01 -0700 (PDT) Received: from localhost.localdomain (gateway.ximian.com [141.154.95.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HKFxn27806 for ; Mon, 17 Jun 2002 13:16:00 -0700 (PDT) Received: (from jpr@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5HKEkD28644; Mon, 17 Jun 2002 16:14:46 -0400 X-Authentication-Warning: localhost.localdomain: jpr set sender to jpr@ximian.com using -f Subject: Re: TZID conflict From: JP Rosevear To: ietf-calendar@imc.org In-Reply-To: <3D0E2F8B.A707CFBC@Royer.com> References: <3D0E2766.16739E4A@steltor.com> <3D0E2F8B.A707CFBC@Royer.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7.99 Date: 17 Jun 2002 16:14:46 -0400 Message-Id: <1024344886.28595.0.camel@endspiel.ximian.com> Mime-Version: 1.0 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Mon, 2002-06-17 at 14:50, Doug Royer wrote: > > > I assume that iCalendar parsers will need to look at the > > VERSION property to figure which version of the tzidparam > > rule part to use when parsing iCalendar objects. > > The ABNF bug makes no differance because a well written iCal parser > and generator would have placed them in quotes anyway: > > IN 2445: > > 4.1.1 List and Field Separators > > ... > Property parameters with values containing a COLON, a SEMICOLON or a > COMMA character MUST be placed in quoted text. A TZID parameter was explicitly excluded from having those characters under the current abnf. -JP -- -- ======================================================================= JP Rosevear jpr@ximian.com Ximian Inc. http://www.ximian.com From owner-ietf-calendar@mail.imc.org Mon Jun 17 18:38:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22063 for ; Mon, 17 Jun 2002 18:38:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HMWis05216 for ietf-calendar-bks; Mon, 17 Jun 2002 15:32:44 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HMWgn05211 for ; Mon, 17 Jun 2002 15:32:42 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5HMWYFa023474 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 Jun 2002 15:32:36 -0700 Message-ID: <3D0E62B2.D7C7499B@Royer.com> Date: Mon, 17 Jun 2002 16:29:06 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: JP Rosevear CC: ietf-calendar@imc.org Subject: Re: TZID conflict References: <3D0E2766.16739E4A@steltor.com> <3D0E2F8B.A707CFBC@Royer.com> <1024344886.28595.0.camel@endspiel.ximian.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEA8C23B6626617324EA7AB45" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msEA8C23B6626617324EA7AB45 Content-Type: multipart/mixed; boundary="------------EE8D834DFB8208B92B64667A" This is a multi-part message in MIME format. --------------EE8D834DFB8208B92B64667A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit JP Rosevear wrote: > > On Mon, 2002-06-17 at 14:50, Doug Royer wrote: > > > > > I assume that iCalendar parsers will need to look at the > > > VERSION property to figure which version of the tzidparam > > > rule part to use when parsing iCalendar objects. > > > > The ABNF bug makes no differance because a well written iCal parser > > and generator would have placed them in quotes anyway: > > > > IN 2445: > > > > 4.1.1 List and Field Separators > > > > ... > > Property parameters with values containing a COLON, a SEMICOLON or a > > COMMA character MUST be placed in quoted text. > > A TZID parameter was explicitly excluded from having those characters > under the current abnf. yes, and thanks for pointing out that the ABNF has a bug. --------------EE8D834DFB8208B92B64667A Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------EE8D834DFB8208B92B64667A-- --------------msEA8C23B6626617324EA7AB45 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MTcyMjI5MDZaMCMGCSqGSIb3DQEJ BDEWBBRxLBxBQDFcRgcVadr9UoNmHvcxtjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgGnzWdPS0EcC41x5MzbyWOJdupCFEy7QorlRlv+SzPQDQK+r QN9RiuUW1IrHcoV4IBAkwMzDpTHtgAwb3BKHUy0LfEI9Hfok3VzYB3XGrBPYfmVHw1MJ3gCO AlpG195QH80hrM081CsRLGn7ReVA71pC2qsbelCEu8OokjPtS4iA --------------msEA8C23B6626617324EA7AB45-- From owner-ietf-calendar@mail.imc.org Mon Jun 17 18:47:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22278 for ; Mon, 17 Jun 2002 18:47:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5HMgvM05605 for ietf-calendar-bks; Mon, 17 Jun 2002 15:42:57 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5HMgtn05601 for ; Mon, 17 Jun 2002 15:42:56 -0700 (PDT) To: "ietf-calendar@imc.org" Subject: Re: [Fwd: I did a checkin of CAP] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Mon, 17 Jun 2002 18:42:43 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/17/2002 06:42:59 PM Content-Type: multipart/mixed; boundary="=_mixed 007CC32185256BDB_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 007CC32185256BDB_= Content-Type: multipart/alternative; boundary="=_alternative 007CC32185256BDB_=" --=_alternative 007CC32185256BDB_= Content-Type: text/plain; charset="us-ascii" Doug, if someone spots a typo they probably ought to post it to this list as well so you don't get three messages all pointing out the same typo. That way, we can see what has been found. Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/17/02 14:43 Please respond to "ietf-calendar@imc.org" To: "ietf-calendar@imc.org" cc: Subject: [Fwd: I did a checkin of CAP] An INTERIM version of CAP is available at: http://INET-Consulting.com/CAP-16-JUN-2002.txt Please note that we hope to push the next official version of CAP before the 24th cutoff date. (just because we want to get it out.) Please send ME email for typo's (mailto:Doug@Royer.com). Please send what you think are changes that need to be made to CAP - to this list (mailto:ietf-calendar@imc.org). It was my intent to consolidate the list information. I suspect as usual there will be issues - please we are open - just send the objective facts of any issues. I took text from -05, -06, and -07, and I am still comparing for missing or extra text. THIS IS STILL work in progress. I have a list of 20 or so things left. Look for "TODO" where I spotted these in the draft. Double check to see that all properties and components have a definition section. (some missing). Add definitions for STATE(), OWNER(), NONOWNER(), CAL-QL and other CAP-QL text missing. Text to describe how to store and fetch pre-defined or stored VQUERYs. Double check all work. I went through and changed all descriptions to use common phrases and terminology. I organized and alphabetized the properties and components. They were by section, however I think the sections leading up to the property descriptions give the summary. In a few places I combined 2 or 3 sections into one section. (VCARs for example) There is more text to be added, mostly properties and CAP-QL statements that were not defined, but used. -Doug --=_alternative 007CC32185256BDB_= Content-Type: text/html; charset="us-ascii"
Doug, if someone spots a typo they probably ought to post it to this list as well so you don't get three messages all pointing out the same typo.  That way, we can see what has been found.


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

06/17/02 14:43
Please respond to "ietf-calendar@imc.org"

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        [Fwd: I did a checkin of CAP]




An INTERIM version of CAP is available at:

                http://INET-Consulting.com/CAP-16-JUN-2002.txt

Please note that we hope to push the next official version of CAP
before the 24th cutoff date. (just because we want to get it out.)

Please send ME email for typo's (mailto:Doug@Royer.com).

Please send what you think are changes that need to be
made to CAP - to this list (mailto:ietf-calendar@imc.org).

It was my intent to consolidate the list information. I suspect
as usual there will be issues - please we are open - just
send the objective facts of any issues.

I took text from -05, -06, and -07, and I am still comparing
for missing or extra text.

THIS IS STILL work in progress.

I have a list of 20 or so things left. Look for "TODO" where I
spotted these in the draft.

                Double check to see that all properties and components
       have a definition section. (some missing).

                Add definitions for STATE(), OWNER(), NONOWNER(), CAL-QL
       and other CAP-QL text missing.

       Text to describe how to store and fetch pre-defined or
       stored VQUERYs.

       Double check all work.
     
I went through and changed all descriptions to use common
phrases and terminology.

I organized and alphabetized the properties and components.
They were by section, however I think the sections leading
up to the property descriptions give the summary.

In a few places I combined 2 or 3 sections into one section.
(VCARs for example)

There is more text to be added, mostly properties and CAP-QL
statements that were not defined, but used.


-Doug

--=_alternative 007CC32185256BDB_=-- --=_mixed 007CC32185256BDB_= Content-Type: application/octet-stream; name="Doug.vcf" Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOlJveWVyO0RvdWcNCnRlbDtwYWdlcjpwYWdlckBSb3llci5jb20NCnRl bDtjZWxsOjIwOC01MjAtNDA0NA0KdGVsO2ZheDo4NjYtNTk0LTg1NzQNCnRlbDt3b3JrOjg2Ni01 OTQtODU3NA0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vUm95ZXIuY29tL1Blb3Bs ZS9Eb3VnDQpvcmc6aHR0cDovL0lORVQtQ29uc3VsdGluZy5jb20NCmFkcjo7OzE3OTUgVy4gQnJv YWR3YXkgIzI2NjtJZGFobyBGYWxscztJZGFobzs4MzQwMjtVLlMuQS4NCnZlcnNpb246Mi4xDQpl bWFpbDtpbnRlcm5ldDpEb3VnQFJveWVyLmNvbQ0KdGl0bGU6Q2hpZWYgRXhlY3V0aXZlIE1hbmFn ZXINCngtbW96aWxsYS1jcHQ6OzEyNzA0DQpmbjpEb3VnIFJveWVyDQplbmQ6dmNhcmQNCg== --=_mixed 007CC32185256BDB_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 17 22:10:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25678 for ; Mon, 17 Jun 2002 22:10:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5I24wO12829 for ietf-calendar-bks; Mon, 17 Jun 2002 19:04:58 -0700 (PDT) Received: from front1.chartermi.net (24.213.60.123.up.mi.chartermi.net [24.213.60.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5I24vn12825 for ; Mon, 17 Jun 2002 19:04:57 -0700 (PDT) Received: from [24.159.200.183] (HELO localhost) by front1.chartermi.net (CommuniGate Pro SMTP 3.5.3) with ESMTP-TLS id 116993085 for ietf-calendar@imc.org; Mon, 17 Jun 2002 22:04:34 -0400 Date: Mon, 17 Jun 2002 21:04:21 -0500 Subject: Re: Focus attempt: Do new properties force a change in VERSION? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: David Nusbaum To: ietf-calendar@imc.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5I24vn12826 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I have been working on a CUA and found the meaning of VERSION to be confusing despite the description of the property contained in RFC2445. My confusion stems from the fact that the general property parameter, property, and component definitions all include support for "some other IANA registered (parameter, property, or component)". My assumption, perhaps incorrect, is that I would have to be able to parse any iCalendar content following that format defined in RFC2445 and that I MUST be able to interpret any of the objects defined within the RFC. This seemed to make sense because some components and properties are core to calendaring and scheduling, such as time zone related elements, while others elements may be specific to one specific vertical such as the car reservation system. Regardless of what the VERSION description says today, why do we support other IANA registered names if they would need to be added to the RFC and the version number incremented? I also think it practical to allow for vertical extensions of the CORE object specification without updating the version number and that incrementing the version be reserved for changes to the CORE specification (horizontal). This is my first update to the mailing list, so don't hit me too hard. I just wanted to offer the opinion of somebody who has been writing to the specification and how it had been interpreted along the way. On Monday, June 17, 2002, at 01:27 PM, Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 06/14/2002 06:56:31 PM: > > > You misgrok the use of VERSION.  If your CUA groks VERSION 2.2 then > it > > > would be able to parse and process the entity its parsing. It says > > > nothing about what you as the recipient of the iCalendar can do, its > > > what VERSION you need to grok in order to properly (or reasonably) > > > deal with the entity you just got. We never said that just because > > > your CUA groks 2.2 that a 1.0;2.3 message MUST have the 2.2 > properties > > > in it; it must have the 2.3 properties in it and any 1.0 or later > CUA > > > should be able to parse and process it (albeit w/some possible loss > of > > > fidelity; see REQUEST-STATUS) > > > > Sure you did, how can I grok SKi-Cal:value if I don't know what > > it is? > > No we didnt.  Where in the RFC did we state that? > > You can _parse_ it as it must follow the format rules (see Section 4.1 > again).  _Interpreting_ its full meaning is something that only a > VERSION 2.1 (or whatever) client can do.  That does NOT meant that an > older client cannot necessarily grok it.   > > A METHOD:REQUEST has straighforward semantic.  You may not grok the > meaning of the newer 2.1 properties but you can still make a reasonable > response to the REQUEST AND you can convey back to the Organizer that > you may not have grok'd it w/the same fidelity as a newer CUA.   > > Section 5 Application Protocol Fallbacks of iTIP discusses dealing with > new METHODs and similar logic should also apply to VERSION (although we > never expresslly put it into any RFC text, we glanced over it when we > defined minver and maxver in iCalendar). > > >        Is this not the same argument that is being used to > > bump the version (assuming you agree with that)? > > As in -> If we add something, bump the version so that the CUA > > knows what it is? > > Maybe its me but I dont see that this is necessarily a problem as long > as the additions do no cause a problem for older clients.  Thats part > of why we put in maxver and minver in the first place!  If the changes > are such that they are not backwards compatable then the minver gets > set accordingly (OR a new METHOD is created!).  Either way the > receiving CUA should be able to deal w/it if it was coded properly. > > It is the job of the WG to make sure that any changes/additions in the > future do not cause problems and that the changes/additions are done > "the right way" and that harmony is maintained. > > > If we tie the properties supported to the version number (add a > > property == bump the version), then the version will have no > > meaning other than a count of the number or properties (or > > property sets) that have been added. > > Just what do you think the use/intent of minver and maxver is?  They > delimit the set of CUAs that can properly (or reasonbly) grok the > iCalendar stream.  If some addition/change in the future decided to > mangle a previously defined METHOD requires that a minver of something > other than "2.0" be sent then Id have to question its change instead of > defining a new METHOD value instead.  Still it could happen (ie: in > order to fix a serious problem that was overlooked before)... > > > The argument seem to be saying that as long as we don't change the > > format then we don't have to worry about VERSION because it is not > > relevant as the CUA must be able to grok it anyway. As in we can't > > do anything with VERSION other than know it is iCalendar 'format'. > > No, no, no.  Perhaps its the term 'format' that makes me hop up an down > so Ill try to restate this as clearly as I can: > > VERSION does not specify the parsing format of the data, it specifies > the (minimum and) maximum versions of a CUA that are required to > _understand_ the parsed content.   > > The parsing/content 'format' is defined in Section 4.1 and if that > changes then we need to define a different way to detect and deal with > it since it would be potentially impossible for an older CUA to even > parse the new format to discover that it did not know how to even parse > it (let alone understand it).  In this case a new MIME type/subtype > would probably be in order. > > If we change the semantics of a METHOD thats already defined in such a > way that only newer CUAs can grok it (grok != parse; grok == > understand) then that is when a VERSION with a minval higher than the > current 2.0 would be necessary.  Adding new 'features' does not (NOR > should it!!) change the semantics of an already defined METHOD.   > > >       (but wait; I can't tell because you are saying that VERSION > > does not mean format VERSION) even when I don't know what the > > properties mean. > > VERSION does not and never has meant "format" VERSION.  Dont know where > that concept came from. > > From 2445: > >    Purpose: This property specifies the identifier corresponding to the >   highest version number or the minimum and maximum range of the >   iCalendar specification that is required in order to interpret the >   iCalendar object. > > (Emphasis mine).  That seems pretty clear to me.  Where does it mislead > one to think its a format issue? > > > So what would "3.1" mean? Nothing!  It would only mean that > > some unknown number of properties have been added to the > > standard. It would have no other meaning. > > They are not "unknown"; they would have to be codified in some RFC.   > > Just because your already written/shipping CUA does not know what they > are does not mean that VERSION has no meaning.  It tells your CUA that > there are properties in the iCalendar that it may not know how to > interpret but the minver indicates that you can still properly > interpret the METHOD (albeit w/o benefit of the newer properties).   My > VERSION 2.0;2.0 CUA may not understand the VEHICLE;TYPE=CAR:MID-SIZE in > the new Hertz VERSION:2.2 REQUEST but its not necessary for me to in > order to accept the REQUEST or COUNTER it.  It may even be smart enough > to put in a REQUEST-STATUS value to indicate that some fallback was > taken for the entry. > > If your CUA got a VERSION:3.0;3.5 REQUEST and its just VERSION:2.0 then > it should do the correct thing and send back a REPLY with > "REQUEST-STATUS:3.9;Unsupported version.;I only understand a minver 2.0 > REQUEST" (See 3.6 Status Replies of iTIP). > > > It would mean that no matter what the VERSION is, I must ignore > > it and parse the object. It would mean that I can not tell if I > > can parse the object until I try an maybe choke. > > Again, VERSION does not and never has meant "format" VERSION.    See > above. > > Also, since VERSION and METHOD appear in the stream before the other > container subcomponents (ie: VEVENT) then  you only have to parse some > of the stream to know that you wont be able to understand the METHOD > (or the VERSION).  You will still have to find some way to scan over or > parse over the entries since more than 1 iCalendar stream may exist in > the data stream body as we defined it (See Section 4.4 iCalendar > Object).  However parsing is NOT the concern as long as the rules in > Section 4.1 are adhered to; its only interpretation of whats parsed. > > >                                                  If you have not > > changed the format then 3.1 would only mean it might contain some > > stuff, it might not, and it has nothing to do with if I know what > > you send me is usable by me. > > NOT a _format_ change, an interpretation change.  Ill keep pointing > this out as long as it takes... > > > I agree, so what does 3.1 tell my parser? > > Nothing.  It tells your processing engine something though! > > > > We should _NOT_ be making CUAs that go "Hmm, I see VERSION:2.0,2.4 > but > > > I my maxver is 2.3 so Ill expect/assume/require that all my 2.3 > > > properties MUST be there."  Thats just bad design!!  No way to spec > > > around poor CUA design folks... > > > > I agree. > > We usually do.  We just have to overcome our initial communication > issues. > > 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... > From owner-ietf-calendar@mail.imc.org Thu Jun 20 13:47:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08051 for ; Thu, 20 Jun 2002 13:47:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KHaYt21666 for ietf-calendar-bks; Thu, 20 Jun 2002 10:36:34 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHaXn21662 for ; Thu, 20 Jun 2002 10:36:33 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KHaTpf029024 for ; Thu, 20 Jun 2002 13:36:29 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KHaT628212 for ; Thu, 20 Jun 2002 13:36:29 -0400 (EDT) Message-ID: <3D12139A.E10911A1@steltor.com> Date: Thu, 20 Jun 2002 13:40:42 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: UPN-FILTER has nothing to do with CAP-QL References: <3D0E2DB6.D601E1E5@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 6.1.3 UPN-FILTER Value you are proposing to modify the values "OWNER" and "NONOWNER" to "OWNER()" and "NONOWNER()" respectively. This proposition has already been discussed on the mailing list in January 2002 and did not reach consensus. See: http://www.imc.org/ietf-calendar/mail-archive/msg02973.html http://www.imc.org/ietf-calendar/mail-archive/msg02985.html The syntax of UPN-FILTER has nothing to do with the CAP-QL language. There are no rational to have UPN-FILTER "look like" CAP-QL. There are no "OWNER()" and "NONOWNER()" functions in CAP-QL anymore. With the functions "SELF()", and "CAL-OWNERS()", CAP-QL doesn't need "OWNER()" and "NONOWNER()". Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 20 13:47:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08064 for ; Thu, 20 Jun 2002 13:47:49 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5KHdCx21733 for ietf-calendar-bks; Thu, 20 Jun 2002 10:39:12 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHdAn21726 for ; Thu, 20 Jun 2002 10:39:11 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KHd6pf029066 for ; Thu, 20 Jun 2002 13:39:06 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KHd6628982 for ; Thu, 20 Jun 2002 13:39:06 -0400 (EDT) Message-ID: <3D121437.DFFD24E6@steltor.com> Date: Thu, 20 Jun 2002 13:43:19 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: STATE() is ambiguous and makes querying for METHOD an exception References: <3D0E2DB6.D601E1E5@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 6.1.1 CAL-QUERY Value Type you are proposing to add the function STATE() to the col-value rule part. As I mentionned on the mailing list in May 2002, this function is ambiguous. It is not clear to which component(s) it applies. For instance, if the STATE() function applies to VEVENT in the following query: SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' does it applies to VAGENDA in the following query? SELECT * FROM VAGENDA WHERE STATE() = 'BOOKED' As I pointed out on the mailing list: http://www.imc.org/ietf-calendar/mail-archive/msg04570.html The state of a component should be sent on the wire to the CUA, such that the CUA can easily find out the state of components returned for an arbitrary search. Otherwise, the CUA will be forced to perform multiple search commands (i.e., one for each state) when a single search could do. My understanding is that the STATE() function attempts to solve the issue about querying on the METHOD property, unfortunately, it makes querying on this property an exception, and doesn't solve the issue about querying on the X-PROP in iTIP objects. For those interested I posted a proposal on the mailing list that doesn't make query for iTIP objects a special case. See: http://www.imc.org/ietf-calendar/mail-archive/msg04640.html, and http://www.imc.org/ietf-calendar/mail-archive/msg05008.html. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 20 13:59:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08484 for ; Thu, 20 Jun 2002 13:59:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KHlnt22927 for ietf-calendar-bks; Thu, 20 Jun 2002 10:47:49 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHlmn22920 for ; Thu, 20 Jun 2002 10:47:48 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KHlipf029161 for ; Thu, 20 Jun 2002 13:47:44 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KHli600025 for ; Thu, 20 Jun 2002 13:47:44 -0400 (EDT) Message-ID: <3D12163D.BD281F08@steltor.com> Date: Thu, 20 Jun 2002 13:51:57 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: SELECT *.* FROM VAGENDA References: <3D0E2DB6.D601E1E5@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 7.1 VAGENDA Component you are proposing that: > To fetch all of the properties from the targeted VAGENDA. This does > not feach any components: > > SELECT * FROM VAGENDA > > To fetch all of the properties from the targeted VAGENDA and all of > the contaied components, use the special '*.*' value: > > SELECT *.* FROM VAGENDA If this WG agrees to change the CAP-QL has you are proposing this information should appear in the CAP-QL section and not in the VAGENDA component registration. Can you clarify what is the intent here? Does your proposition imply that SELECT * FROM VEVENT will no longer return VALARM components contained in VEVENT components as well? Or are you making this an exception exclusively for VAGENDA components? Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 20 13:59:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08534 for ; Thu, 20 Jun 2002 13:59:56 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5KHnOj23162 for ietf-calendar-bks; Thu, 20 Jun 2002 10:49:24 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KHnNn23158 for ; Thu, 20 Jun 2002 10:49:23 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KHnKpf029171 for ; Thu, 20 Jun 2002 13:49:20 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KHnJ600718 for ; Thu, 20 Jun 2002 13:49:20 -0400 (EDT) Message-ID: <3D12169D.AABDE468@steltor.com> Date: Thu, 20 Jun 2002 13:53:33 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: iCalendar object MUST include at least one calendar component References: <3D0E2DB6.D601E1E5@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 8.4 GENERATE-UID Command you are proposing that the GENERATE-UID command returns an iCalendar object such as: > BEGIN:VCALENDAR > VERSION:2.0 > CMD;ID=unique-per-cua-124:REPLY > UID:20011121T120000Z-12340@cal.example.com > UID:20011121T120000Z-12341@cal.example.com > UID:20011121T120000Z-12342@cal.example.com > UID:20011121T120000Z-12343@cal.example.com > UID:20011121T120000Z-12344@cal.example.com > END:VCALENDAR Futhermore, in section 8.5 GET-CAPABILITY Command you are proposing that the GET-CAPABILITY command returns an iCalendar object such as: > BEGIN:VCALENDAR > VERSION:2.0 > CMD;ID=unique-per-cua-125:REPLY > CAP-VERSION:1.0 > PRODID:The CS prodid > QUERY-LEVEL:CAP-QL > CAR-LEVEL:CAR-FULL-1 > DATE-MAX:99991231T235959Z > DATE-MIN:00000101T000000Z > MAX-COMPONENT-SIZE:0 > COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR, > VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT > ITIP-VERSION:2447 > RECUR-ACCEPTED:TRUE > RECUR-EXPAND:TRUE > RECUR-LIMIT:0 > CS-STORES-EXPANDED:FALSE > X-INET-PRIVATE-COMMANDS:1.0 > END:VCALENDAR Clearly, these iCalendar objects violates RFC 2445. Since, per RFC 2445 (section 4.6), iCalendar object MUST include at least one calendar component. As it is a requirement for CAP to obey RFC 2445. I don't see any other solution than to return results in new components such as: BEGIN:VUIDLIST UID:uid1 UID:uid2 UID:uid3 END:VUIDLIST Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 20 14:11:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09117 for ; Thu, 20 Jun 2002 14:11:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KI0AN24590 for ietf-calendar-bks; Thu, 20 Jun 2002 11:00:10 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KI09n24584 for ; Thu, 20 Jun 2002 11:00:09 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KI06pf029261 for ; Thu, 20 Jun 2002 14:00:06 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KI06602346 for ; Thu, 20 Jun 2002 14:00:06 -0400 (EDT) Message-ID: <3D121923.EDAE7C6A@steltor.com> Date: Thu, 20 Jun 2002 14:04:19 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Reply to a command by a command? References: <3D0E2DB6.D601E1E5@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 8.9 REPLY Command you are proposing to add a new command REPLY to return the results of commands. In my opinion, it doesn't makes sense to reply to a command by a command! REPLY being a command, should one reply to this command as well? It is clear to me that the identifier of a command should be specified in a separate attribute (e.g., CMDID) and not as a parameter of the CMD property, such that it is possible to return a calendar component that contains a command identifier (CMDID) and no command (CMD) (i.e., when returning the result of a command). I did send a full proposal on the mailing list that follows the model that was specified in draft-05. I haven't heard any objections so far on the mailing list. See examples: http://www.imc.org/ietf-calendar/mail-archive/msg04640.html See specification: http://www.imc.org/ietf-calendar/mail-archive/msg05008.html Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 20 14:11:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09137 for ; Thu, 20 Jun 2002 14:11:45 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5KI3mO25130 for ietf-calendar-bks; Thu, 20 Jun 2002 11:03:48 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KI3ln25124 for ; Thu, 20 Jun 2002 11:03:47 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KI3ipf029308 for ; Thu, 20 Jun 2002 14:03:44 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KI3h603137 for ; Thu, 20 Jun 2002 14:03:43 -0400 (EDT) Message-ID: <3D1219FD.69B36A67@steltor.com> Date: Thu, 20 Jun 2002 14:07:57 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: CU MUST NOT be able to change decreed VCAR with CAP References: <3D0E2DB6.D601E1E5@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 4.2.4 Decreed VCARs you are proposing to add the following statement: > To the CUA any "VCAR" component with the "DECREED" > property set to "TRUE" can not be changed by the currently > authenticated UPN, and depending on the implementation and other > VCARs; might not be able to be changed by any UPN using CAP. ^^^^^^^^^ That must be MUST NOT. Decreed VCARs are "persistent and immutable" by definition, so it doesn't make sense to allow someone to change a decreed VCAR by using CAP. Otherwise, a CUA will no longer be able to assume that a decreed VCAR will remain the same for its entire session. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 20 14:11:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09150 for ; Thu, 20 Jun 2002 14:11:46 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5KI1tt24860 for ietf-calendar-bks; Thu, 20 Jun 2002 11:01:55 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KI1sn24854 for ; Thu, 20 Jun 2002 11:01:54 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KI1opf029291 for ; Thu, 20 Jun 2002 14:01:51 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KI1l602433 for ; Thu, 20 Jun 2002 14:01:47 -0400 (EDT) Message-ID: <3D121988.DF4FAB8@steltor.com> Date: Thu, 20 Jun 2002 14:06:00 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Adding DECREED:TRUE to VCAR on the fly References: <3D0E2DB6.D601E1E5@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 4.2.4 Decreed VCARs you are proposing to add the following statement: > [...] > A reply from the CS > may dynamically create VCARs that are decreed depending on the > implementation. > [...] This proposition has already been discussed on the mailing list in February 2002 and did not reach consensus. I still believe that it would not be a good idea to allow the CS to add DECREED:TRUE on the fly in returned VCAR components. For those interested check the following thread in the mailing list archive: http://www.imc.org/ietf-calendar/mail-archive/thrd2.html#03185 and the message in which I expressed my view on the subject: http://www.imc.org/ietf-calendar/mail-archive/msg03331.html Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 20 14:31:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09681 for ; Thu, 20 Jun 2002 14:31:53 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5KIRBH27092 for ietf-calendar-bks; Thu, 20 Jun 2002 11:27:11 -0700 (PDT) Received: from postman.incentivesystems.com ([65.220.90.244]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIRAn27088 for ; Thu, 20 Jun 2002 11:27:10 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Reply to a command by a command? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 20 Jun 2002 14:29:47 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.10 |March 22, 2002) at 06/20/2002 02:30:30 PM, Serialize complete at 06/20/2002 02:30:30 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >In my opinion, it doesn't makes sense to reply to a command >by a command! REPLY being a command, should one reply to >this command as well? Of course not--"one" in this case is the CUA, which never replies. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |"Dinner Special: Turkey $2.35; Chicken or Beef $2.25; Children| |$2.00." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Jun 20 14:34:51 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09776 for ; Thu, 20 Jun 2002 14:34:50 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5KIULB27227 for ietf-calendar-bks; Thu, 20 Jun 2002 11:30:21 -0700 (PDT) Received: from postman.incentivesystems.com ([65.220.90.244]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIUJn27221 for ; Thu, 20 Jun 2002 11:30:19 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: iCalendar object MUST include at least one calendar component MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Stracke" Date: Thu, 20 Jun 2002 14:32:57 -0400 X-MIMETrack: Serialize by Router on Incentive_Notes/Incentivesystems(Release 5.0.10 |March 22, 2002) at 06/20/2002 02:33:39 PM, Serialize complete at 06/20/2002 02:33:39 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This does seem to make sense--and it should be an easy change. /==============================================================\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==============================================================| |"Dinner Special: Turkey $2.35; Chicken or Beef $2.25; Children| |$2.00." | \==============================================================/ From owner-ietf-calendar@mail.imc.org Thu Jun 20 14:43:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10032 for ; Thu, 20 Jun 2002 14:43:44 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5KIcFA27528 for ietf-calendar-bks; Thu, 20 Jun 2002 11:38:15 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KIcEn27523 for ; Thu, 20 Jun 2002 11:38:14 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KIcBpf029794 for ; Thu, 20 Jun 2002 14:38:11 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KIc7609251 for ; Thu, 20 Jun 2002 14:38:07 -0400 (EDT) Message-ID: <3D12220C.CD2228E3@steltor.com> Date: Thu, 20 Jun 2002 14:42:20 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Reply to a command by a command? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit John Stracke wrote: > > >In my opinion, it doesn't makes sense to reply to a command > >by a command! REPLY being a command, should one reply to > >this command as well? > > Of course not--"one" in this case is the CUA, which never replies. Perhaps you should read Doug's big proposal. From section 8.5 GET-CAPABILITY Command: > The CS MAY send a GET-CAPABILITY command to any CUA. The GET- > CAPABILITY command MAY be implemented by a CUA. If the CUA receives a command (CMD), it is only normal to presume that the CUA should reply. Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 20 16:41:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12192 for ; Thu, 20 Jun 2002 16:41:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KKYvH01872 for ietf-calendar-bks; Thu, 20 Jun 2002 13:34:57 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KKYun01868 for ; Thu, 20 Jun 2002 13:34:56 -0700 (PDT) In-Reply-To: <3D12169D.AABDE468@steltor.com> To: Bernard Desruisseaux Cc: ietf-calendar@imc.org Subject: Re: iCalendar object MUST include at least one calendar component MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06092002 June 09, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 20 Jun 2002 16:32:58 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_06172002|June 17, 2002) at 06/20/2002 04:29:55 PM, Serialize complete at 06/20/2002 04:29:55 PM Content-Type: multipart/alternative; boundary="=_alternative 0071035785256BDE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071035785256BDE_= Content-Type: text/plain; charset="US-ASCII" Bernard wrote on 06/20/2002 01:53:33 PM: > > BEGIN:VCALENDAR > > VERSION:2.0 > > CMD;ID=unique-per-cua-124:REPLY > > UID:20011121T120000Z-12340@cal.example.com [Snip] > > BEGIN:VCALENDAR > > VERSION:2.0 > > CMD;ID=unique-per-cua-125:REPLY [Snip] > Clearly, these iCalendar objects violates RFC 2445. > Since, per RFC 2445 (section 4.6), iCalendar object > MUST include at least one calendar component. > > As it is a requirement for CAP to obey RFC 2445. I > don't see any other solution than to return results > in new components such as: > > BEGIN:VUIDLIST Nice idea. Id suggest that you make a generic component to use, perhaps something like a VREPLY or a VRESPONSE (Editors pick as to the actual name). I suggest it so that we dont get a proliferation of new subcomponents whose sole purpose in the standard is to make sure we dont violate the RFC 2445 tenant about containment. That is, a VUIDLIST and a VCAPABILITY and a VGEEWHIZ and a VCAPV4FILLER and a... Since there is data to return in reponse to the command, make a generic container we can reuse for that purpose and let it be defined such that it can have anything in it (properties only, properties and other containers, etc) and then use the new container wherever needed. 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 0071035785256BDE_= Content-Type: text/html; charset="US-ASCII"
Bernard wrote on 06/20/2002 01:53:33 PM:
> > BEGIN:VCALENDAR
> > VERSION:2.0
> > CMD;ID=unique-per-cua-124:REPLY
> > UID:20011121T120000Z-12340@cal.example.com
[Snip]
> > BEGIN:VCALENDAR
> > VERSION:2.0
> > CMD;ID=unique-per-cua-125:REPLY
[Snip]
> Clearly, these iCalendar objects violates RFC 2445.
> Since, per RFC 2445 (section 4.6), iCalendar object
> MUST include at least one calendar component.
>
> As it is a requirement for CAP to obey RFC 2445. I
> don't see any other solution than to return results
> in new components such as:
>
>   BEGIN:VUIDLIST
Nice idea.  Id suggest that you make a generic component to use, perhaps something like a VREPLY or a VRESPONSE (Editors pick as to the actual name).  

I suggest it so that we dont get a proliferation of new subcomponents whose sole purpose in the standard is to make sure we dont violate the RFC 2445 tenant about containment.  That is, a VUIDLIST and a VCAPABILITY and a VGEEWHIZ and a VCAPV4FILLER and a...

Since there is data to return in reponse to the command, make a generic container we can reuse for that purpose and let it be defined such that it can have anything in it (properties only, properties and other containers, etc) and then use the new container wherever needed.

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 0071035785256BDE_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 20 17:06:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12579 for ; Thu, 20 Jun 2002 17:06:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KL08603782 for ietf-calendar-bks; Thu, 20 Jun 2002 14:00:08 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KL07n03776 for ; Thu, 20 Jun 2002 14:00:07 -0700 (PDT) In-Reply-To: To: David Nusbaum Cc: ietf-calendar@imc.org Subject: Re: Focus attempt: Do new properties force a change in VERSION? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06092002 June 09, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 20 Jun 2002 16:57:56 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_06172002|June 17, 2002) at 06/20/2002 04:55:05 PM, Serialize complete at 06/20/2002 04:55:05 PM Content-Type: multipart/alternative; boundary="=_alternative 00734CC285256BDE_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00734CC285256BDE_= Content-Type: text/plain; charset="US-ASCII" David replied on 06/17/2002 10:04:21 PM: > My assumption, > perhaps incorrect, is that I would have to be able to parse any > iCalendar content following that format defined in RFC2445 and that I > MUST be able to interpret any of the objects defined within the RFC. Fairly accurate. You should be able to parse ANYTHING that conforms to RFC 2445 but you may not be able to interpret it for some reason (probably architectural in nature but not always). For example, Outlook can parse an iTIP REQUESTs that has RDATEs in it and it wont complain but they drop RDATEs on the floor and the invitation is not flagged as being repeating. The reason being that they internal design is more pattern centric and list centric. Or your application may not have the concept of a Journal it for whatever reason so you probably wont write any code to actually process the VJOURNAL that you can easily parse. > Regardless of what the VERSION description says today, why do we support > other IANA registered names if they would need to be added to the RFC > and the version number incremented? This is NOT accurate. Its possible for anyone (ie: SKiCAL) to draft up some new properties to add to the current standard without needing to revise/increment VERSION. That however does not preclude reving of VERSION if some properties are added if there is a sufficient or compelling need to do so. From the fragments Ive caught so far I havent seen any such need for doing that just yet but perhaps its there. So far Doug and I have gone back and forth (while being on the same side of the fence I suspect) but no clarification from the "Pro revising" camp yet... > This is my first update to the mailing list, so don't hit me too hard. We stopped flaying former lurkers a while ago... ;^) 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 00734CC285256BDE_= Content-Type: text/html; charset="US-ASCII"
David replied on 06/17/2002 10:04:21 PM:

>                                                      My assumption,
> perhaps incorrect, is that I would have to be able to parse any
> iCalendar content following that format defined in RFC2445 and that I
> MUST be able to interpret any of the objects defined within the RFC.

Fairly accurate.  You should be able to parse ANYTHING that conforms to RFC 2445 but you may not be able to interpret it for some reason (probably architectural in nature but not always).  

For example, Outlook can parse an iTIP REQUESTs that has RDATEs in it and it wont complain but they drop RDATEs on the floor and the invitation is not flagged as being repeating.  The reason being that they internal design is more pattern centric and list centric.  Or your application may not have the concept of a Journal it for whatever reason so you probably wont write any code to actually process the VJOURNAL that you can easily parse.

> Regardless of what the VERSION description says today, why do we support
> other IANA registered names if they would need to be added to the RFC
> and the version number incremented?

This is NOT accurate.  Its possible for anyone (ie: SKiCAL) to draft up some new properties to add to the current standard without needing to revise/increment VERSION.  That however does not preclude reving of VERSION if some properties are added if there is a sufficient or compelling need to do so.

From the fragments Ive caught so far I havent seen any such need for doing that just yet but perhaps its there.  So far Doug and I have gone back and forth (while being on the same side of the fence I suspect) but no clarification from the "Pro revising" camp yet...

> This is my first update to the mailing list, so don't hit me too hard.

We stopped flaying former lurkers a while ago... ;^)

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 00734CC285256BDE_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 20 17:16:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12721 for ; Thu, 20 Jun 2002 17:16:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KLBwD04241 for ietf-calendar-bks; Thu, 20 Jun 2002 14:11:58 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KLBtn04235 for ; Thu, 20 Jun 2002 14:11:55 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5KLBsFa016502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 20 Jun 2002 14:11:57 -0700 Message-ID: <3D1243B4.31916E91@Royer.com> Date: Thu, 20 Jun 2002 15:05:56 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: iCalendar object MUST include at least one calendar component References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB81A2EA0D022A67330E58E01" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msB81A2EA0D022A67330E58E01 Content-Type: multipart/mixed; boundary="------------96BFC7EA59B0E8C111660797" This is a multi-part message in MIME format. --------------96BFC7EA59B0E8C111660797 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Nice idea. Id suggest that you make a generic component to use, > perhaps something like a VREPLY or a VRESPONSE (Editors pick as to the > actual name). Great idea, if there are no objections, I'l wrapp all replies with a VREPLY (just because it is shorter than VERSPONSE :-). Keep those cards and letters coming. -Doug --------------96BFC7EA59B0E8C111660797 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------96BFC7EA59B0E8C111660797-- --------------msB81A2EA0D022A67330E58E01 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MjAyMTA2MDFaMCMGCSqGSIb3DQEJ BDEWBBSx8ABt2bGKBWMjx1JYgZtya/KtYDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgKHiEQDoDG7PVUOFGSjAhOF7Y2QJhy0Z5OLBeLco2KpuFLCP v0CV0Yk0BicItKyCd1Rx9rAgAzRqsxulD+6N9zasTVsVZsH61asEjLEJKq5ZKhefG/F3Fmxk VC2qvSYC+HXVwkKA2H0ExXGWlos0LBewhClRtOyktdt8dl+reh+r --------------msB81A2EA0D022A67330E58E01-- From owner-ietf-calendar@mail.imc.org Thu Jun 20 17:16:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12736 for ; Thu, 20 Jun 2002 17:16:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5KKLUu00880 for ietf-calendar-bks; Thu, 20 Jun 2002 13:21:30 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KKLTn00876 for ; Thu, 20 Jun 2002 13:21:29 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KKLPpf031341 for ; Thu, 20 Jun 2002 16:21:26 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KKLP627813 for ; Thu, 20 Jun 2002 16:21:25 -0400 (EDT) Message-ID: <3D123A42.662D33D0@steltor.com> Date: Thu, 20 Jun 2002 16:25:38 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: "UNPROCESSED", "BOOKED" and "DELETED" References: <3D0E2DB6.D601E1E5@Royer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In section 1.3 Definitions you are proposing the following definition: > Booked - An entry in the calendar store has one of three conceptual > states. It is "UNPROCESSED", "BOOKED" or marked as "DELETED". > How the implementation stores the state of any object is not a > protocol issues and is not discussed. An object can be said to be > booked, unprocessed, or marked for delete. As I said before on the mailing list, we shouldn't be mixing the state of a component (i.e., "unprocessed"/"booked") with the fact that it has been marked for removal. These are 2 different things. It should be possible to differentiate a VEVENT marked for removal from an iTIP object, containing a VEVENT, that has been marked for removal. The fact that a component has been marked for removal would be better handled by a property which could easily be maintained by CMD:MODIFY, and queried with CMD:SEARCH, just like any other property. What I'm saying here is the exact same thing as was done in draft-05, where calendars could be marked for removal by mean of the TOMBSTONE property. Furthermore, I maintain that given a proper calendar store object model we don't need a special CAP-QL function (such as STATE()) to differentiate "unprocessed" components (iTIP) from "booked" components. With the proposal I sent to the mailing list, finding all "unprocessed" components is as easy as: SELECT * FROM VITIP Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 20 19:03:25 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14978 for ; Thu, 20 Jun 2002 19:03:24 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5KMw0005884 for ietf-calendar-bks; Thu, 20 Jun 2002 15:58:00 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KMvxn05880 for ; Thu, 20 Jun 2002 15:57:59 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5KMvupf032544 for ; Thu, 20 Jun 2002 18:57:56 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5KMvu623045 for ; Thu, 20 Jun 2002 18:57:56 -0400 (EDT) Message-ID: <3D125EF1.533B77AB@steltor.com> Date: Thu, 20 Jun 2002 19:02:09 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: iCalendar object MUST include at least one calendar component References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: > > Nice idea. Id suggest that you make a generic component to use, > perhaps something like a VREPLY or a VRESPONSE (Editors pick as to the > actual name). Good by me. Such a component would provide a grouping of component properties that describe the reply to a command. Now, if you think about it, the CMDID, TARGET and perhaps the REQUEST-STATUS properties should also go into this VREPLY (or VRESPONSE) component. This way, whenever the CUA specifies more than one TARGET in a command it could receive an iCalendar object with multiple VREPLY components, that is, one for each TARGET. For instance, the reply to an arbitrary search command for some VEVENT components in multiple calendars could then look like the following: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//XYZZY/CalendarServer//EN BEGIN:VREPLY CMDID:abcd1235 REQUEST-STATUS:2.0 TARGET:cap://cal.host.com/mary-relcalid <-- Mary's target BEGIN:VEVENT [...] END:VEVENT END:VREPLY BEGIN:VREPLY CMDID:abcd1235 REQUEST-STATUS:2.0 TARGET:cap://cal.host.com/bob-relcalid <-- Bob's target BEGIN:VEVENT [...] END:VEVENT END:VREPLY END:VCALENDAR Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Fri Jun 21 21:28:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06074 for ; Fri, 21 Jun 2002 21:28:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5M1HrQ01232 for ietf-calendar-bks; Fri, 21 Jun 2002 18:17:53 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5M1Hpw01227 for ; Fri, 21 Jun 2002 18:17:51 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5M1HlFa026695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Jun 2002 18:17:54 -0700 Message-ID: <3D13CECC.D8D39E56@Royer.com> Date: Fri, 21 Jun 2002 19:11:40 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: STATE() is ambiguous and makes querying for METHOD an exception References: <3D0E2DB6.D601E1E5@Royer.com> <3D121437.DFFD24E6@steltor.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2C04B90134E75F86FE3432F8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms2C04B90134E75F86FE3432F8 Content-Type: multipart/mixed; boundary="------------A1534398E6AB05A0CC1B7E38" This is a multi-part message in MIME format. --------------A1534398E6AB05A0CC1B7E38 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > As I mentionned on the mailing list in May 2002, this function is > ambiguous. It is not clear to which component(s) it applies. > For instance, if the STATE() function applies to VEVENT in the > following query: > > SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' The same as when it was: SELECT * FROM VEVENT WHERE METHOD = ' ... > does it applies to VAGENDA in the following query? > > SELECT * FROM VAGENDA WHERE STATE() = 'BOOKED' The same as when it was: SELECT * FROM VAGENDA WHERE METHOD = '... --------------A1534398E6AB05A0CC1B7E38 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------A1534398E6AB05A0CC1B7E38-- --------------ms2C04B90134E75F86FE3432F8 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MjIwMTExNDBaMCMGCSqGSIb3DQEJ BDEWBBQ/8hZnBqtFpHxjOHsXPowIMGXQvjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgCwSORtJYoMS9lZGXp+sh/GgW/YT+z1EY2IrYNo4rrAO+4Fw 59mYTP3tHU2zAIss5Y2RgYHzhp8evCjl9ik4CDRjY7uLPGlKMLIpGzj/8opFv3Cwbc6AyKWo VELoOrzzptEsEw9KtyLw8K3yR7hA6Id3B/MbU3P1csmPnvbv7pmg --------------ms2C04B90134E75F86FE3432F8-- From owner-ietf-calendar@mail.imc.org Fri Jun 21 21:29:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06090 for ; Fri, 21 Jun 2002 21:29:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5M1KXE01320 for ietf-calendar-bks; Fri, 21 Jun 2002 18:20:33 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5M1KWw01311 for ; Fri, 21 Jun 2002 18:20:32 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5M1KXFa026720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Jun 2002 18:20:35 -0700 Message-ID: <3D13CF72.C9B7EECA@Royer.com> Date: Fri, 21 Jun 2002 19:14:26 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: SELECT *.* FROM VAGENDA References: <3D0E2DB6.D601E1E5@Royer.com> <3D12163D.BD281F08@steltor.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4CB0CF6C92FDA6AFF208F0A6" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms4CB0CF6C92FDA6AFF208F0A6 Content-Type: multipart/mixed; boundary="------------42B2FC9F93D9DAC34D9171CD" This is a multi-part message in MIME format. --------------42B2FC9F93D9DAC34D9171CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > > In section 7.1 VAGENDA Component you are proposing that: > > > To fetch all of the properties from the targeted VAGENDA. This does > > not feach any components: > > > > SELECT * FROM VAGENDA > > > > To fetch all of the properties from the targeted VAGENDA and all of > > the contaied components, use the special '*.*' value: > > > > SELECT *.* FROM VAGENDA > > If this WG agrees to change the CAP-QL has you are proposing this > information should appear in the CAP-QL section and not in the > VAGENDA component registration. > > Can you clarify what is the intent here? Does your proposition > imply that > > SELECT * FROM VEVENT > > will no longer return VALARM components contained in VEVENT > components as well? No > Or are you making this an exception > exclusively for VAGENDA components? (and VCALSTORE I assume?) It says VAGENDA and VCALSTORE in the text, correct? --------------42B2FC9F93D9DAC34D9171CD Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------42B2FC9F93D9DAC34D9171CD-- --------------ms4CB0CF6C92FDA6AFF208F0A6 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MjIwMTE0MjZaMCMGCSqGSIb3DQEJ BDEWBBTYFUcV4vJFMDF2F3KMAMmhffFj6DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgHSulOlWMMGJujD+9EZSy1rv/NbWqsvL108SPVGNmTS1myTb 6PRJvrNgnRE3JLHZQ1zQwiFxuYpVhMZmtdYGTlu8M6ezzImTbUZ1JcydttISbG/uexn4m/SB NSoprGvwuCudz347Wu2BXmx2HDkzSJ3JyxcKtLveBPP/sNRtxz3P --------------ms4CB0CF6C92FDA6AFF208F0A6-- From owner-ietf-calendar@mail.imc.org Sat Jun 22 23:11:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09840 for ; Sat, 22 Jun 2002 23:11:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5N2DY111850 for ietf-calendar-bks; Sat, 22 Jun 2002 19:13:34 -0700 (PDT) Received: from oe-mp1.bizmailsrvcs.net (oe-mp1pub.managedmail.com [206.46.164.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5N2DXw11846 for ; Sat, 22 Jun 2002 19:13:33 -0700 (PDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with ESMTP id <20020623021331.JWEK15579.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net> for ; Sat, 22 Jun 2002 21:13:31 -0500 Received: from champagned ([24.50.100.19]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020623021331.VDUC8375.oe-ismta1.bizmailsrvcs.net@champagned> for ; Sat, 22 Jun 2002 21:13:31 -0500 Reply-To: From: "Darryl Champagne" To: Subject: RE: STATE() is ambiguous and makes querying for METHOD an exception Date: Sat, 22 Jun 2002 22:14:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D13CECC.D8D39E56@Royer.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I may be a relatively quiet lurker, and witnessing an ongoing dispute, but could I ask for slightly more expansive responses? I realize there is a tendency to get annoyed, and answer with short, minimalistic responses, but they are not especially informative for other people trying to better their understanding of CAP. Thanks, dgc Darryl G. Champagne Openwave Systems Inc. Mobile Development One Burlington Woods Drive Email: Darryl.Champagne@Openwave.com Burlington, MA 01803 USA (W) +1.781.313.1306 (M) +1.781.820.2283 ------------------------------------------------------------- Privacy and Confidentiality Notice: The information contained in this electronic mail message is intended for the named recipient(s) only. It may contain privileged and confidential information. If you are not an intended recipient, you must not copy, forward, distribute, or take any action in reliance on it. If you have received this electronic mail message in error, please notify the sender immediately. ------------------------------------------------------------- -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Doug Royer Sent: Friday, June 21, 2002 9:12 PM To: ietf-calendar@imc.org Subject: Re: STATE() is ambiguous and makes querying for METHOD an exception > As I mentionned on the mailing list in May 2002, this function is > ambiguous. It is not clear to which component(s) it applies. > For instance, if the STATE() function applies to VEVENT in the > following query: > > SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' The same as when it was: SELECT * FROM VEVENT WHERE METHOD = ' ... > does it applies to VAGENDA in the following query? > > SELECT * FROM VAGENDA WHERE STATE() = 'BOOKED' The same as when it was: SELECT * FROM VAGENDA WHERE METHOD = '... From owner-ietf-calendar@mail.imc.org Sun Jun 23 15:56:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03456 for ; Sun, 23 Jun 2002 15:56:14 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5NJoPB05557 for ietf-calendar-bks; Sun, 23 Jun 2002 12:50:25 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5NJoOw05553 for ; Sun, 23 Jun 2002 12:50:24 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5NJoNFa029695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 23 Jun 2002 12:50:25 -0700 Message-ID: <3D1624FB.B3A636B@Royer.com> Date: Sun, 23 Jun 2002 13:43:55 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: STATE() is ambiguous and makes querying for METHOD an exception References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms099DC2C7042C303F50E20284" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms099DC2C7042C303F50E20284 Content-Type: multipart/mixed; boundary="------------40697E0F4219C25836CDDC2B" This is a multi-part message in MIME format. --------------40697E0F4219C25836CDDC2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Darryl Champagne wrote: > > Hi, > I may be a relatively quiet lurker, and witnessing an ongoing dispute, but > could I ask for slightly more expansive responses? I realize there is a > tendency to get annoyed, and answer with short, minimalistic responses, but > they are not especially informative for other people trying to better their > understanding of CAP. Thanks for your reply. However the response is in total, there was no change to the scope of the query response. > As I mentionned on the mailing list in May 2002, this function is > ambiguous. It is not clear to which component(s) it applies. > For instance, if the STATE() function applies to VEVENT in the > following query: > > SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' --------------40697E0F4219C25836CDDC2B Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------40697E0F4219C25836CDDC2B-- --------------ms099DC2C7042C303F50E20284 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MjMxOTQzNTVaMCMGCSqGSIb3DQEJ BDEWBBQz3mS298I+7vqoSek/vcl2sd+puDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgKsVQvxbFB+g+ucUJDPm2PARqi3v/zi8WnGFyWHEocJrLVqn Xnyrg50CuJZCQYfatja69HvVv6yTQXqhRrFbtgb0GussSQYHhT1Cz536Cd1c+Dx0TT7nQmz3 z7s5zy5/iWZ1VwhgjrdYHZdUY5jRwtpAgLCgkb6vm5rPW47CYk6F --------------ms099DC2C7042C303F50E20284-- From owner-ietf-calendar@mail.imc.org Mon Jun 24 12:06:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14619 for ; Mon, 24 Jun 2002 12:06:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OFqWa11240 for ietf-calendar-bks; Mon, 24 Jun 2002 08:52:32 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OFqVw11236 for ; Mon, 24 Jun 2002 08:52:31 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5OFqTFa004537 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 24 Jun 2002 08:52:31 -0700 Message-ID: <3D173EAF.1D93996B@Royer.com> Date: Mon, 24 Jun 2002 09:45:51 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: Re: I did a checkin of CAP] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms87FC2E3EDECD2557B072A79C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms87FC2E3EDECD2557B072A79C Content-Type: multipart/mixed; boundary="------------43ED324E555B34FCB077C4AB" This is a multi-part message in MIME format. --------------43ED324E555B34FCB077C4AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I did some diffs and in total over the last view edits I added as many of the items that I could find on the list over the last few months that had not been included. Including: Adding how to tag VALARMs as local so they are not exported during a REQUEST or COUNTER (LOCAL parameter + SEQUENCE property) ((mid FEB on list) Added a note about the problem of exporting VALARMs. Added more CAP-QL notes that I found as bugs. I don't think they changed the protocol, they just were not noticed before (locale effecting query sort order for example). Added that UTF-8 MUST BE the initial charset and that the default locale is not specified. Now the CUA can query the CS and select a locale. Prior to this the locale information was in the CS, but there was no way for the CS to specify it at run time. Added the SET-LOCALE (and charset) command. This was on the list as a topic - no specific proposal was given. Added text on how a CUA knows the charset and locale that a CS I did -not- add the part of that debate that described how a CUA should synchronize with a CS, from the list it appeared that no one agreed to that part of my proposal. Adding how to tag VALARMS that are global and received as part of a REQUEST from being acted on. (ENABLE parameter) (mid FEB on list). This includes additions/changed to the ABNF - only effects CAP protocol - not iTIP or iMIP. Added text on how to disambiguate the effect of query. This is controversial. However I think I answered all questions I could find. Some may not be happy that the way they wanted it is not spelled they way they want, but I think it addresses their concerns. Added ABNF to update the 'calprops' ABNF name so we could add properties to CAP and still call them VCALENDAR objects (only effect CAP protocol and not ITIP or iMIP). The CHILD vs RELATED-TO properties in the VCALSTORE are there. There was no proposal on how one VCALSTORE relates to another, but there was a great deal of email about adding RELATED-TO to the VCALSTORE for relating one to another. I never did fully understand the issue - but I added them. (related to removing hierarchy - but despite all of the email, I could not find a specific proposal) I did not add the VCOMMAND from -05 because it was a wrapper to the modified METHOD values, which we rejected. If we needed to, some version of it can be added back. (The issue was that if we modified METHOD, we needed a wrapper [VCOMMAND] so a CUA/CS would not confuse the object with a iTIP object). I had thought that it would be added, but once METHOD only meant iTIP, then 100% of all VCOMMANDS only contained VCALENDAR objects anyway so it seemed it did not need to be re-added. I removed the unpopular METHOD also contains state (I had proposed that method mean ITIP + booked + deleted) and replaced with the STATE() method that means one of those same three states. And added text saying that it is implementation specific on how the state is stored - no one could agree on how, now it is up to the implementation. On the list I could only find one objection to STATE(). I removed the need for 100% pure iTIP objects to contain the CREATE command, as 100% of the time it means CREATE them in the UNPROCESSED state. I removed many examples that seemed to duplicate other examples or iTIP. Still the draft is 130 pages. I removed using the METHOD property for issuing commands per the unpopularity of my proposal. Added CMD. moved the latency from the beep layer into CMD. Added separate sections describing each command that was not described in the past. (some were missing) Added the VREPLY component per popular demand to wrap all replies. Pat had said that we may wish to have a separate draft showing examples. I think that is a good idea. Altered the section on how to submit new objects and alter existing object per the very old action item list. (method reviewer replaced with - do an rfc). Moved all text describing the effect of X- objects to one location. I converted the REPLY restriction tables to ABNF. for two reasons (1) size now smaller, (2) ABNF is the way to do it in drafts. The only restriction tables that remain are the ones that describe how they specifically are effected by the subject of the text (unique to VCALSTORE, VAGENDA, ...). [still not done] Consistency in error codes. Beep: Removed many BEEP examples and replaced them with text/calendar examples. Added text describing the effect of BEEP virtual hosting. This has not been discused on the list and I only added that a CS/CUA may wish to use that beep feature, and if they do, how it effects CAP. (see new properties - summary section - CSID). Added text describing how the localize (locale) can effect CAP and how CAP should use it. [not done] The BEEP profile for CAP. Changed things for consistency. Changed some names for consistency. 'OWNER' vs 'OWNER(), vs OWNER property'. Several on the list said there should not be 2 ways to say the same thing. Same with NONOWNER vs 'NOT OWNER()'. One person did not want them to be the same, others did. There is now OWNER property and OWNER() method and 'OWNER' is not overloaded. (Plus OWNER and NONOWNER dissallowed UPNs of the same name). Changed CURRENT-CALID() to CURRENT-TARGET(), because it matched the TARGET value, not the contained calendar. (VCARS would always match them selves) I did not change the meaning, just how it is spelled. And it always meant target. In many places the term 'calendar component' was used and in others 'component' was used. I removed 'calendar'. Similar for properties and parameters. Removed (changed) the word 'event' when it did not mean 'VEVENT'. Most changed to the word 'object' or 'component'. In process: I am still reviewing the draft for consistency. I think that GET-CAPABALITIES and the VCALSTORE properties may still have some problems. I am still re-reading the last few months of posts looking for forgotten issues and resolutions. --------------43ED324E555B34FCB077C4AB Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------43ED324E555B34FCB077C4AB-- --------------ms87FC2E3EDECD2557B072A79C 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MjQxNTQ1NTFaMCMGCSqGSIb3DQEJ BDEWBBQZpDQbyGKVCRuoWU3QqL8O5owW+TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgG4+sTTqfKfS2VZ3yCes7B/ezyn4Xzkz2GS4ZcANwd44b9q9 hWYvnpTxdps9nydRiBIGDEdpoUkao1hG5mLCLCxL8aNZWfiEzGi2lOsx6jd6OLwjTaC9mM1a 8Cp1gY9xW6GKdjK23vqxRqQKv6XfQW8VjDVpS0dwLAhp1zxikF94 --------------ms87FC2E3EDECD2557B072A79C-- From owner-ietf-calendar@mail.imc.org Mon Jun 24 16:12:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27965 for ; Mon, 24 Jun 2002 16:12:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OK4Ws22550 for ietf-calendar-bks; Mon, 24 Jun 2002 13:04:32 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OK4Uw22545 for ; Mon, 24 Jun 2002 13:04:30 -0700 (PDT) To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: I did a checkin of CAP] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Mon, 24 Jun 2002 16:04:20 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/24/2002 04:04:33 PM, Serialize complete at 06/24/2002 04:04:33 PM Content-Type: multipart/alternative; boundary="=_alternative 006E42D485256BE2_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E42D485256BE2_= Content-Type: text/plain; charset="us-ascii" Doug, thanks for the summary of the CAP changes you made. List, please take the time to review the draft and post any issues/agreements so that we can move it along. There were a lot of comments made on the list over the last several months. We need to make sure Doug has covered all of them. If there are sections that are missing, speak up. If there are sections that need re-wording, speak up. If it looks OK as is, speak up as well. When people step up to do editing, that is just what they are doing - editing - putting down on paper their intrepretation of what is on the list. Note that Doug has mentioned one area that was not on the list. Please take the time to read that part of the draft - Doug, please post the specific text of that section of the draft to the list. Let's make it convenient for everyone to specifically read that text. Again, we thank everyone for their support and work reading these drafts. And remember, until they become RFCs they are still drafts - ie. documents in progress. Let's make this a document we all like and let's move it along. I actually think I see some light at the end of the tunnel. --=_alternative 006E42D485256BE2_= Content-Type: text/html; charset="us-ascii"
Doug, thanks for the summary of the CAP changes you made.  List, please take the time to review the draft and post any issues/agreements so that we can move it along.  There were a lot of comments made on the list over the last several months.  We need to make sure Doug has covered all of them.  If there are sections that are missing, speak up.  If there are sections that need re-wording, speak up.  If it looks OK as is, speak up as well.  When people step up to do editing, that is just what they are doing - editing - putting down on paper their intrepretation of what is on the list. Note that Doug has mentioned one area that was not on the list.  Please take the time to read that part of the draft - Doug, please  post the specific text of that section of the draft to the list.  Let's make it convenient for everyone to specifically read that text.  

Again, we thank everyone for their support and work reading these drafts.  And remember, until they become RFCs they are still drafts - ie. documents in progress.  Let's make this a document we all like and let's move it along.  I actually think I see some light at the end of the tunnel. --=_alternative 006E42D485256BE2_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 24 16:40:59 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29247 for ; Mon, 24 Jun 2002 16:40:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OKWoA23681 for ietf-calendar-bks; Mon, 24 Jun 2002 13:32:50 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OKWnw23677 for ; Mon, 24 Jun 2002 13:32:49 -0700 (PDT) To: "ietf-calendar@imc.org" Subject: Virtual Interop Testing for iCalendar, iMIP and iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Mon, 24 Jun 2002 16:32:51 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/24/2002 04:32:52 PM, Serialize complete at 06/24/2002 04:32:52 PM Content-Type: multipart/alternative; boundary="=_alternative 0070DEF585256BE2_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0070DEF585256BE2_= Content-Type: text/plain; charset="us-ascii" Hi, it's time to schedule our virtual interop. What this is going to be is an interop testing of RFCs 2445, 2446 and 2447 (iCalendar, iTIP and iMIP) over the internet. (What a concept!). Everyone has limited time and budgets so it has made it tough to get an "in-person interop" going. I'm willing to put in the effort to set this up and I hope vendors and open source groups will be willing to participate/ My thoughts on how this virtual testing will work are as follows. There will be a secure server that will have IMAP and POP capability so we can test sending calendar entries. There will be a Team Room, again secure with log-ons, where people can hold discussions on-line (similar to AOL and MSN, but encrypted). This is where everyone will be able to mark off when a MUST or SHOULD has worked/not worked/almost worked and where comments can be made. We will have an agenda that will set up times to do the testing and times to stop and chat about where we are at that point in the testing. I will ask everyone that participates on this interop to devote the full time to the testing - i.e. assume you are away from the office during the testing (even though you are not). We will have regular conference calls set at certain intervals during the two days. Results on testing will be provided by each participant to the chair, . The chair, myself, will summarize the results and report them, confidentially, to the IETF Area Directors. All confidentiality rules observed at a normal interop testing will be observed during the virtual testing. This shall be a low cost interop - the costs will be the conference calling facility and that will be based on how many people sign up for the virtual testing. When I know the number, I will estimate the costs and we will divide it equally among the participants. I do not foresee this being more than $100 per organization. Now, here's what I need from everyone: 1. Preferred dates - here's my selections - pick the best for you. We want to do two contiguous days. Please respond within the next two weeks if you will be participating and which days you prefer. I will need at least two weeks to finalize the virtual testing facility. - Any two days the week of July 29-August 2 - Any two days the week of August 5 - 9 - Any two days the week of September 3-6 NOTE - I am not opposed to doing weekend days if that fits schedules better. 2. I need to ensure we have a really good testing matrix that reflects all items that need to be tested. We have used a fairly high level matrix for the prior testing. Since we are going to be doing this testing "virtually" I need more comprehensive matrixes In other words, I need a clearly defined chart (I see a spreadsheet working quite nicely for this) with MUSTS/SHOULDs defined. Then as a test is completed, we will check off, by vendor, what has been completed. My request is for volunteers to help draw up these matrixes. I did a good start using GREP - but as many of you have probably already figured out, I'm an end user not a developer of calendar apps. I need someone who really understands the drafts to help me put together the matrixes - one per draft. So...if you would like to help, please send me an email. Thanks for your support. Help us move these RFC's up to Standard level!. --=_alternative 0070DEF585256BE2_= Content-Type: text/html; charset="us-ascii"
Hi, it's time to schedule our virtual interop.  What this is going to be is an interop testing of RFCs 2445, 2446 and 2447 (iCalendar, iTIP and iMIP) over the internet.  (What a concept!).  Everyone has limited time and budgets so it has made it tough to get an "in-person interop" going.  I'm willing to put in the effort to set this up and I hope vendors and open source groups will be willing to participate/

My thoughts on how this virtual testing will work are as follows.  
  1. There will be a secure server that will have IMAP and POP capability so we can test sending calendar entries.  
  2. There will be a Team Room, again secure with log-ons, where people can hold discussions on-line (similar to AOL and MSN, but encrypted).  This is where everyone will be able to mark off when a MUST or SHOULD has worked/not worked/almost worked and where comments can be made.
  3. We will have an agenda that will set up times to do the testing  and times to stop and chat about where we are at that point in the testing.  
  4. I will ask everyone that participates on this interop to devote the full time to the testing - i.e. assume you are away from the office during the testing (even though you are not).
  5. We will have regular conference calls set at certain intervals during the two days.
  6. Results on testing will be provided by each participant to the chair, .
  7. The chair, myself, will summarize the results and report them, confidentially, to the IETF Area Directors.
  8. All confidentiality rules observed at a normal interop testing will be observed during the virtual testing.  
  9. This shall be a low cost interop - the costs will be the conference calling facility and that will be based on how many people sign up for the virtual testing.  When I know the number, I will estimate the costs and we will divide it equally among the participants.  I do not foresee this being more than $100 per organization.

    Now, here's what I need from everyone:

    1.  Preferred dates - here's my selections - pick the best for you.  We want to do two contiguous days.  Please respond within the next two weeks if you will be participating and which days you prefer.  I will need at least two weeks to finalize the virtual testing facility.  
            - Any two days the week of July 29-August 2
            - Any two days the week of August 5 - 9
            - Any two days the week of September 3-6

    NOTE - I am not opposed to doing weekend days if that fits schedules better.

    2.  I need to ensure we have a really good testing matrix that reflects all items that need to be tested.  We have used a fairly high level matrix for the prior testing.  Since we are going to be doing this testing "virtually" I need more comprehensive matrixes  In other words, I need a clearly defined chart (I see a spreadsheet working quite nicely for this) with MUSTS/SHOULDs defined.  Then as a test is completed, we will check off, by vendor, what has been completed.  

    My request is for volunteers to help draw up these matrixes.  I did a good start using GREP - but as many of you have probably already figured out, I'm an end user not a developer of calendar apps.  I need someone who really understands the drafts to help me put together the matrixes - one per draft.  So...if you would like to help, please send me an email.

    Thanks for your support.  Help us move these RFC's up to Standard level!.  

--=_alternative 0070DEF585256BE2_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 24 17:24:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01783 for ; Mon, 24 Jun 2002 17:24:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OLCYS25268 for ietf-calendar-bks; Mon, 24 Jun 2002 14:12:34 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OLCTw25236 for ; Mon, 24 Jun 2002 14:12:29 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5OLCQFa006593 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 24 Jun 2002 14:12:28 -0700 Message-ID: <3D1789A9.6B8B77CF@Royer.com> Date: Mon, 24 Jun 2002 15:05:45 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: pregen@egenconsulting.com CC: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: I did a checkin of CAP] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA2B7A08C18F4669E569611A4" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msA2B7A08C18F4669E569611A4 Content-Type: multipart/mixed; boundary="------------35D59D2503012EF998FACF1D" This is a multi-part message in MIME format. --------------35D59D2503012EF998FACF1D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit pregen@egenconsulting.com wrote: > ... - Doug, please post the specific > text of that section of the draft to the list. I updated the definition of CSID. I included how it ties to he BEEP 'serverName' value: CSID - Each CS needs its own unique identifier. The "CSID" property is the official unique identifier for the CS. If the BEEP 'serverName' attribute was suppled in the BEEP 'start' message, then the CSID will be mapped to the virtual host name supplied and the host name part of the CSID MUST BE the same as the 'serverName' value. This allows one CS implementation to service multiple virtual hosts. CS's are not required to support virtual hosting. If a CS does not support virtual hosting then it must ignore the BEEP 'serverName'. (Section 7.5) --------------35D59D2503012EF998FACF1D Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------35D59D2503012EF998FACF1D-- --------------msA2B7A08C18F4669E569611A4 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MjQyMTA1NDVaMCMGCSqGSIb3DQEJ BDEWBBQH8hYOwG/ZINAH6CMaekXV4MajIDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgFKevHm2V3oQSI5WdI8EpDFlqBASlsPWloo4stPbr1ikRtiS ribPTWuugZ+DADoI+Yd53/MffK0zSJZmH7oiXcFnlSISiZle3V7Tr2uZJPYx4OadxHrmvFkm Cw5eNz/FvsToXFm9dMXtJbKyQQvj15d3Ji/cjW6k0gp6bHRo9mPh --------------msA2B7A08C18F4669E569611A4-- From owner-ietf-calendar@mail.imc.org Mon Jun 24 17:44:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03151 for ; Mon, 24 Jun 2002 17:44:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OLXE826244 for ietf-calendar-bks; Mon, 24 Jun 2002 14:33:14 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OLXCw26240 for ; Mon, 24 Jun 2002 14:33:12 -0700 (PDT) To: Doug Royer Cc: doug@royer.com, "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: I did a checkin of CAP] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Mon, 24 Jun 2002 17:33:15 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/24/2002 05:33:16 PM, Serialize complete at 06/24/2002 05:33:16 PM Content-Type: multipart/alternative; boundary="=_alternative 007666B285256BE2_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007666B285256BE2_= Content-Type: text/plain; charset="us-ascii" Thanks for the update! --=_alternative 007666B285256BE2_= Content-Type: text/html; charset="us-ascii"
Thanks for the update! --=_alternative 007666B285256BE2_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 26 08:47:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16001 for ; Wed, 26 Jun 2002 08:47:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5QCeSC08040 for ietf-calendar-bks; Wed, 26 Jun 2002 05:40:28 -0700 (PDT) Received: from mail.samsungcontact.com ([195.89.159.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QCeQw08036 for ; Wed, 26 Jun 2002 05:40:26 -0700 (PDT) Received: from mail.samsungcontact.com (root@localhost) by mail.samsungcontact.com (8.11.6/8.11.6) with ESMTP id g5QCePr03565; Wed, 26 Jun 2002 13:40:26 +0100 Received: from samsungcontact.com ( 195.89.159.62) by mail.samsungcontact.com (Samsung Contact SMTP Relay 7.1.0) via ESMTP; Wed, 26 Jun 2002 13:40:26 +0100 (BST) Message-ID: <3D19B639.1070409@samsungcontact.com> Date: Wed, 26 Jun 2002 13:40:25 +0100 From: Mark Davidson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: Doug Royer Subject: Re: [Fwd: I did a checkin of CAP] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here are a few small typos/consistency fixes: [3.2] Calendar Store Object Model VAGENDAs can contain VFREEBUSY objects (as per pic on page 18) [4.2.3] Predefined VCARs The REQUESTONLY example has the PERMISSION:WRITE property, it should be PERMISSION:CREATE The UPDATEPARTSTATUS example needs an END:VCAR on the end of it. [8.10] SEARCH command The searching for events example is looking for METHOD IS 'CREATE', this should now be STATE() = 'booked' Mark Davidson From owner-ietf-calendar@mail.imc.org Wed Jun 26 10:12:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19706 for ; Wed, 26 Jun 2002 10:12:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5QE6P411171 for ietf-calendar-bks; Wed, 26 Jun 2002 07:06:25 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QE6Ow11165 for ; Wed, 26 Jun 2002 07:06:24 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5QE6Jpf001958 for ; Wed, 26 Jun 2002 10:06:20 -0400 Received: from steltor.com (c-1782.in.steltor.com [101.1.42.13]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5QE6J605615 for ; Wed, 26 Jun 2002 10:06:19 -0400 (EDT) Message-ID: <3D19CB5E.DE4701D3@steltor.com> Date: Wed, 26 Jun 2002 10:10:38 -0400 From: Bernard Desruisseaux Organization: Steltor X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA,pdf MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [Fwd: I did a checkin of CAP] References: <3D19B639.1070409@samsungcontact.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Davidson wrote: > > Here are a few small typos/consistency fixes: > > [4.2.3] Predefined VCARs > > The REQUESTONLY example has the PERMISSION:WRITE property, it should > be PERMISSION:CREATE Actually, the REQUESTONLY example is right. If you look at draft-07 as well as the mailing list archive you'll find out that the permvalue rule part that was agreed on is: permvalue = ( "READ" / "WRITE" / "DELETE" / "MODIFY" / all ) I don't remember seeing any proposition on the mailing list to change this rule part. Thanks for pointing this out! Cheers, Bernard -- Bernard Desruisseaux mailto:bernard@steltor.com Research & Development Tel. : +1 514 733-8500 x4213 Steltor Fax : +1 514 733-8878 From owner-ietf-calendar@mail.imc.org Thu Jun 27 11:25:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23794 for ; Thu, 27 Jun 2002 11:25:05 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5RF7ef23863 for ietf-calendar-bks; Thu, 27 Jun 2002 08:07:40 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RF7cw23852 for ; Thu, 27 Jun 2002 08:07:38 -0700 (PDT) Received: from Royer.com (mail.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5RF7QFa031414 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 27 Jun 2002 08:07:29 -0700 Message-ID: <3D1B287D.800BD280@Royer.com> Date: Thu, 27 Jun 2002 09:00:13 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: RE: Application for port-number (1026)] Content-Type: multipart/mixed; boundary="------------69AF6731AC8E0E12114AC169" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------69AF6731AC8E0E12114AC169 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: RE: Application for port-number (1026) Date: Wed, 26 Jun 2002 18:15:18 -0700 From: "IANA" To: Dear Doug, We have assigned the following user port number: cap 1026/tcp Calender Access Protocol cap 1026/udp Calender Access Protocol Please notify the IANA if there is a change in contact information by completing the following template: Michelle S. Cotton IANA Administrator *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 email: iana@iana.org *************************************************************** --------------69AF6731AC8E0E12114AC169 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------69AF6731AC8E0E12114AC169-- From owner-ietf-calendar@mail.imc.org Thu Jun 27 12:04:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27349 for ; Thu, 27 Jun 2002 12:04:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RFrIT14301 for ietf-calendar-bks; Thu, 27 Jun 2002 08:53:18 -0700 (PDT) Received: from CarWash.IncentiveSystems.com (CarWash.IncentiveSystems.com [66.152.247.41]) by above.proper.com (8.11.6/8.11.3) with SMTP id g5RFrGw14288 for ; Thu, 27 Jun 2002 08:53:17 -0700 (PDT) Received: from minglewood.incentivesystems.com ([172.16.0.25]) by CarWash.IncentiveSystems.com (NAVGW 2.5.2.11) with SMTP id M2002062711575031857 for ; Thu, 27 Jun 2002 11:57:50 -0400 Received: from franklinstower.incentivesystems.com ([10.10.30.26]) by minglewood.incentivesystems.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Jun 2002 11:51:50 -0400 Subject: Re: [Fwd: RE: Application for port-number (1026)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C21DF1.62BBE4C0" Date: Thu, 27 Jun 2002 11:43:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Message-ID: <4B5305E45A015F4D874F39922DBC31B46BCC@franklinstower.incentivesystems.com> X-MS-Has-Attach: yes Thread-Topic: Re: [Fwd: RE: Application for port-number (1026)] Thread-Index: AcId8oqK3AwXzakJRzuX9dA9EqISLA== From: "John Stracke" To: X-OriginalArrivalTime: 27 Jun 2002 15:51:50.0118 (UTC) FILETIME=[8CCAB060:01C21DF2] Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C21DF1.62BBE4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We don't need a UDP port, do we? Did you ask for one, or did they just = include one automatically? /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ |John Stracke |Principal Engineer | |jstracke@incentivesystems.com |Incentive Systems, Inc. | |http://www.incentivesystems.com <> = |My opinions are my own. | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| |"HTTP is what happens in the absence of good design." -- Keith| |Moore | \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/ ------_=_NextPart_001_01C21DF1.62BBE4C0 Content-Type: application/octet-stream; name="~~DLNK0.URL" Content-Description: http://www.incentivesystems.com/ Content-Disposition: attachment; filename="~~DLNK0.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9aHR0cDovL3d3dy5pbmNlbnRpdmVzeXN0ZW1zLmNvbS8N Cg== ------_=_NextPart_001_01C21DF1.62BBE4C0-- From owner-ietf-calendar@mail.imc.org Thu Jun 27 12:47:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00568 for ; Thu, 27 Jun 2002 12:47:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5RGauI02192 for ietf-calendar-bks; Thu, 27 Jun 2002 09:36:56 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RGatw02180 for ; Thu, 27 Jun 2002 09:36:55 -0700 (PDT) Received: from Royer.com (mail.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5RGarFa031974 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 27 Jun 2002 09:36:55 -0700 Message-ID: <3D1B3D6E.A0C53A1E@Royer.com> Date: Thu, 27 Jun 2002 10:29:34 -0600 From: Doug Royer Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke CC: ietf-calendar@imc.org Subject: Re: [Fwd: RE: Application for port-number (1026)] References: <4B5305E45A015F4D874F39922DBC31B46BCC@franklinstower.incentivesystems.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms28CDF706A3C0417ED0B0683C" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms28CDF706A3C0417ED0B0683C Content-Type: multipart/mixed; boundary="------------D5887827CD71FBDF2C09CCE6" This is a multi-part message in MIME format. --------------D5887827CD71FBDF2C09CCE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Stracke wrote: > > We don't need a UDP port, do we? Did you ask for one, or did > they just include one automatically? They always issue both: http://www.iana.org/assignments/port-numbers --------------D5887827CD71FBDF2C09CCE6 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------D5887827CD71FBDF2C09CCE6-- --------------ms28CDF706A3C0417ED0B0683C 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 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhA85nVyQ1LlncKock/RLC9dMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDEyMjAwMDAw MFoXDTAyMTAxMjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0B CQEWDmRvdWdAcm95ZXIuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7uTPDnj/U t/EKae6vnKPIWpCI2HoHAl3n5uSf/gIwD4Z+j3gewsR0Dm70bjAcWxwps6FNphsMUBolBwKo L73DGK8NNSz+G8fvzMrDa6SA+Pv/hv0IhkqqmCkEdgawKzzs3i3t3qQy8zOVhXNQSkhUvzlu TDNi0FS2bsCepU7hwwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMTgwNjlhZjY3YjMyNzNhNTAyMzQw MWRjMjU3MWY3NjQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQAirjMwaw74Gbr3M61qm+BnzaNOeTMvriFN twfq1XDwgW4VBGhP1jHFL1bg6TJwEonPLJepixj0Y6/SahwkG1QUo86aCyJSyrB7qWl5q4PI XvjcGvN3jgVLlM5CYcXIyEXL9sGm8hxdxPB15yKd519QNkzNp+sd5QU8Ww5DM0AYczCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDzmdXJDUuWdwqhyT9EsL10wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA2MjcxNjI5MzhaMCMGCSqGSIb3DQEJ BDEWBBSAJft4TBTIWAi/JhKkfhBxTG+u7zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgCpnQpP1uTjezGirPS63uCst2eYWaPhC8U4QOfcc6+fnojtc PdmqI87kPBdZ93EbTx14vIVLWpJLPVGiE0lD0JQI52Uz9NBz8xT6HuRpFNn3qc9FARBH64dP OJIvo87Xj8IPgDBJLRP/N9afjf9z8hcEj9vrz30GXZvD2zYDS0/v --------------ms28CDF706A3C0417ED0B0683C-- From owner-ietf-calendar@mail.imc.org Fri Jun 28 11:32:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01161 for ; Fri, 28 Jun 2002 11:32:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5SFM6v03085 for ietf-calendar-bks; Fri, 28 Jun 2002 08:22:06 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SFM4w03066 for ; Fri, 28 Jun 2002 08:22:04 -0700 (PDT) To: "ietf-calendar@imc.org" Cc: "ietf-calendar@imc.org" , owner-ietf-calendar@mail.imc.org Subject: Re: [Fwd: RE: Application for port-number (1026)] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 28 Jun 2002 11:21:48 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/28/2002 11:22:06 AM Content-Type: multipart/mixed; boundary="=_mixed 005468F485256BE6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_mixed 005468F485256BE6_= Content-Type: multipart/alternative; boundary="=_alternative 005468F485256BE6_=" --=_alternative 005468F485256BE6_= Content-Type: text/plain; charset="us-ascii" Excellent! thanks for coordinating this. Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 06/27/2002 11:00 Please respond to "ietf-calendar@imc.org" To: "ietf-calendar@imc.org" cc: Subject: [Fwd: RE: Application for port-number (1026)] -------- Original Message -------- Subject: RE: Application for port-number (1026) Date: Wed, 26 Jun 2002 18:15:18 -0700 From: "IANA" To: Dear Doug, We have assigned the following user port number: cap 1026/tcp Calender Access Protocol cap 1026/udp Calender Access Protocol Please notify the IANA if there is a change in contact information by completing the following template: Michelle S. Cotton IANA Administrator *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 email: iana@iana.org *************************************************************** --=_alternative 005468F485256BE6_= Content-Type: text/html; charset="us-ascii"
Excellent!  thanks for coordinating this.


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

06/27/2002 11:00
Please respond to "ietf-calendar@imc.org"

       
        To:        "ietf-calendar@imc.org" <ietf-calendar@imc.org>
        cc:        
        Subject:        [Fwd: RE: Application for port-number (1026)]





-------- Original Message --------
Subject: RE: Application for port-number (1026)
Date: Wed, 26 Jun 2002 18:15:18 -0700
From: "IANA" <iana@iana.org>
To: <Doug@Royer.com>

Dear Doug,

We have assigned the following user port number:

cap             1026/tcp   Calender Access Protocol
cap             1026/udp   Calender Access Protocol

Please notify the IANA if there is a change in contact
information by completing the following template:

Michelle S. Cotton
IANA Administrator

***************************************************************
Internet Assigned Numbers Authority (IANA)
4676 Admiralty Way, Suite 330
Marina del Rey, California 90292

email: iana@iana.org
***************************************************************

--=_alternative 005468F485256BE6_=-- --=_mixed 005468F485256BE6_= Content-Type: application/octet-stream; name="Doug.vcf" Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOlJveWVyO0RvdWcNCnRlbDtwYWdlcjpwYWdlckBSb3llci5jb20NCnRl bDtjZWxsOjIwOC01MjAtNDA0NA0KdGVsO2ZheDo4NjYtNTk0LTg1NzQNCnRlbDt3b3JrOjg2Ni01 OTQtODU3NA0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8vUm95ZXIuY29tL1Blb3Bs ZS9Eb3VnDQpvcmc6aHR0cDovL0lORVQtQ29uc3VsdGluZy5jb20NCmFkcjo7OzE3OTUgVy4gQnJv YWR3YXkgIzI2NjtJZGFobyBGYWxscztJZGFobzs4MzQwMjtVLlMuQS4NCnZlcnNpb246Mi4xDQpl bWFpbDtpbnRlcm5ldDpEb3VnQFJveWVyLmNvbQ0KdGl0bGU6Q2hpZWYgRXhlY3V0aXZlIE1hbmFn ZXINCngtbW96aWxsYS1jcHQ6OzEyNzA0DQpmbjpEb3VnIFJveWVyDQplbmQ6dmNhcmQNCg== --=_mixed 005468F485256BE6_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 28 16:49:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21041 for ; Fri, 28 Jun 2002 16:49:39 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g5SKgC207781 for ietf-calendar-bks; Fri, 28 Jun 2002 13:42:12 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SKgAw07777 for ; Fri, 28 Jun 2002 13:42:10 -0700 (PDT) To: ietf-calendar@imc.org Subject: CAP draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Fri, 28 Jun 2002 16:42:18 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 06/28/2002 04:42:13 PM, Serialize complete at 06/28/2002 04:42:13 PM Content-Type: multipart/alternative; boundary="=_alternative 0071BCD185256BE6_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0071BCD185256BE6_= Content-Type: text/plain; charset="us-ascii" Has everyone responded to the list regarding CAP changes? We would like to submit the draft so it can be reviewed by everyone in the IETF. Now is your chance - if you object, say so. If you do not have objections or we do not hear on the list, we're submitting the draft. Thanks. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0071BCD185256BE6_= Content-Type: text/html; charset="us-ascii"
Has everyone responded to the list regarding CAP changes? We would like to submit the draft so it can be reviewed by everyone in the IETF.  Now is your chance - if you object, say so.  If you do not have objections or we do not hear on the list, we're submitting the draft.  Thanks.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0071BCD185256BE6_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 28 18:31:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26116 for ; Fri, 28 Jun 2002 18:31:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5SMMu011264 for ietf-calendar-bks; Fri, 28 Jun 2002 15:22:56 -0700 (PDT) Received: from plexus.steltor.com (plexus.steltor.com [207.139.176.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SMMtw11259 for ; Fri, 28 Jun 2002 15:22:55 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.steltor.com (8.12.1/1.0.1) with ESMTP id g5SMMppf026284; Fri, 28 Jun 2002 18:22:51 -0400 Received: from steltor.com (c-0000.in.steltor.com [101.1.42.1]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g5SMMp626180; Fri, 28 Jun 2002 18:22:51 -0400 (EDT) Message-ID: <3D1CE1BA.A07332A3@steltor.com> Date: Fri, 28 Jun 2002 18:22:50 -0400 From: George Babics X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: pregen@egenconsulting.com CC: ietf-calendar@imc.org Subject: Re: CAP draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Isn't it a bit too early to submit the draft? I think there were many changes done recently in Doug's working document that were not discussed nor agreed to on the list, should we take the time to review, comment and adjust them? If I am not mistaken, before posting a new draft the chairs should ask or declare consensus for each one the proposed changes. Was that done for these changes? George pregen@egenconsulting.com wrote: > > Has everyone responded to the list regarding CAP changes? We would like to submit the draft so it can be reviewed by everyone in the IETF. Now is your chance - if you object, say so. If you do not > have objections or we do not hear on the list, we're submitting the draft. Thanks. > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 From owner-ietf-calendar@mail.imc.org Fri Jun 28 19:53:17 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29170 for ; Fri, 28 Jun 2002 19:53:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5SNjj013920 for ietf-calendar-bks; Fri, 28 Jun 2002 16:45:45 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SNjiw13916 for ; Fri, 28 Jun 2002 16:45:44 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g5SNjiFa010589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 28 Jun 2002 16:45:47 -0700 Message-ID: <3D1CF367.D01DDA8D@Royer.com> Date: Fri, 28 Jun 2002 17:38:15 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org Organization: http://INET-Consulting.com X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP draft References: <3D1CE1BA.A07332A3@steltor.com> Content-Type: multipart/mixed; boundary="------------8E4CD76F57CC5EE4C2C216D8" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------8E4CD76F57CC5EE4C2C216D8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit George Babics wrote: > > > Isn't it a bit too early to submit the draft? The cut-off is Monday at 9AM EST. This is (was) the last business day. > I think there were many changes done recently in Doug's working > document that were not discussed nor agreed to on the list, Only one was not discussed - the BEEP 'serverName', but it was posted and has not been officially published. All of the other items have been discussed on the list. Agreed: Almost all of the changes have some disagreement. We don't have to agree - we have to have consensus. > should > we take the time to review, comment and adjust them? The editors do have access to the latest unpublished version, so at this point only the editors can provide input - until it is published. I have made *several* more small edits in the last week or so since the un-official post of the draft. The editors still have full access to the text. > If I am not mistaken, before posting a new draft the chairs > should ask or declare consensus for each one the proposed changes. > Was that done for these changes? Not for each change, that would take decades. --------------8E4CD76F57CC5EE4C2C216D8 Content-Type: text/x-vcard; charset=us-ascii; name="Doug.vcf" Content-Description: Card for Doug Royer Content-Disposition: attachment; filename="Doug.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Royer;Doug tel;pager:pager@Royer.com tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:http://INET-Consulting.com adr:;;1795 W. Broadway #266;Idaho Falls;Idaho;83402;U.S.A. version:2.1 email;internet:Doug@Royer.com title:Chief Executive Manager x-mozilla-cpt:;12704 fn:Doug Royer end:vcard --------------8E4CD76F57CC5EE4C2C216D8--