From owner-ietf-calendar@mail.imc.org Fri Jan 9 10:46:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07779 for ; Fri, 9 Jan 2004 10:46:30 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06JJGib057126 for ; Tue, 6 Jan 2004 11:19:16 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i06JJGhC057125 for ietf-calendar-bks; Tue, 6 Jan 2004 11:19:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06JJDib057107 for ; Tue, 6 Jan 2004 11:19:14 -0800 (PST) (envelope-from pregen@egenconsulting.com) In-Reply-To: <3FFAF89D.9010904@oracle.com> To: George Babics Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: "and so this is Christmas, and what have you done?" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Tue, 6 Jan 2004 14:19:17 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 01/06/2004 02:19:16 PM, Serialize complete at 01/06/2004 02:19:16 PM Content-Type: multipart/alternative; boundary="=_alternative 006A230185256E13_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A230185256E13_= Content-Type: text/plain; charset="US-ASCII" Yes, that sounds like a good idea too. It helps separate the issues and makes for easier reading. George Babics Sent by: owner-ietf-calendar@mail.imc.org 01/06/2004 13:04 To ietf-calendar@imc.org cc Subject Re: "and so this is Christmas, and what have you done?" Helge Hess wrote: > > On 10.12.2003, at 19:14, pregen@egenconsulting.com wrote: > >> Helge, this is a great idea. It would be great if you can do that for >> us. > > > No problem, I've just created: > - a CALSCH product, which is the entry point for the group > - a component (read: topic/category) "general" for general issues > - a user "ietf-calendar@imc.org" which is set as the initial owner > for "general" issues (receives mail on each issue) > Should we have a topic/category for each rfc or draft, i.e., separate categories for iMIP, iTIP, CAP, and iCalendar? Even though our current focus is on CAP, people may want to submit issues or bugs relating to the other docs. George --=_alternative 006A230185256E13_= Content-Type: text/html; charset="US-ASCII"
Yes, that sounds like a good idea too.  It helps separate the issues and makes for easier reading.


George Babics <george.babics@oracle.com>
Sent by: owner-ietf-calendar@mail.imc.org

01/06/2004 13:04

To
ietf-calendar@imc.org
cc
Subject
Re: "and so this is Christmas, and what have you done?"







Helge Hess wrote:
>
> On 10.12.2003, at 19:14, pregen@egenconsulting.com wrote:
>
>> Helge, this is a great idea.  It would be great if you can do that for
>> us.
>
>
> No problem, I've just created:
> - a CALSCH product, which is the entry point for the group
> - a component (read: topic/category) "general" for general issues
> - a user "ietf-calendar@imc.org" which is set as the initial owner
>   for "general" issues (receives mail on each issue)
>

  Should we have a topic/category for each rfc or draft, i.e., separate
categories for iMIP, iTIP, CAP, and iCalendar? Even though our current
focus is on CAP, people may want to submit issues or bugs relating to
the other docs.

George
--=_alternative 006A230185256E13_=-- From owner-ietf-calendar@mail.imc.org Fri Jan 9 10:46:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07872 for ; Fri, 9 Jan 2004 10:46:45 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06I8Jib053696 for ; Tue, 6 Jan 2004 10:08:19 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i06I8JIq053695 for ietf-calendar-bks; Tue, 6 Jan 2004 10:08:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06I8Hib053689 for ; Tue, 6 Jan 2004 10:08:18 -0800 (PST) (envelope-from george.babics@oracle.com) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i06I7nZp012263 for ; Tue, 6 Jan 2004 10:07:50 -0800 (PST) Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i06I87S29975 for ; Tue, 6 Jan 2004 11:08:07 -0700 (MST) Received: from oracle.com (gbabics-ca.ca.oracle.com [144.23.213.222]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i06I86S29955 for ; Tue, 6 Jan 2004 11:08:06 -0700 (MST) Message-ID: <3FFAF974.3020405@oracle.com> Date: Tue, 06 Jan 2004 13:07:48 -0500 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: "and so this is Christmas, and what have you done?" References: <3FD746C7.1020106@centive.com> <3FD785BA.8090300@Royer.com> In-Reply-To: <3FD785BA.8090300@Royer.com> 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 Doug Royer wrote: > Should there be a monthly post to this list saying ...go...here ... for > issue list? > Else it may be a FAQ. > The monthly post or FAQ should also include the "rules of engagement" sent by Bob Morgan, and any other essential information that a newcomer should know. George From subs-reminder@imc.org Fri Jan 9 10:47:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07915 for ; Fri, 9 Jan 2004 10:47:09 -0500 (EST) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i071Diib083823 for ; Tue, 6 Jan 2004 17:13:45 -0800 (PST) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i071DiX7083822; Tue, 6 Jan 2004 17:13:44 -0800 (PST) Date: Tue, 6 Jan 2004 17:13:44 -0800 (PST) Message-Id: <200401070113.i071DiX7083822@above.proper.com> To: calsch-archive@ietf.org Subject: [[443738906]] Subscription to ietf-calendar for calsch-archive@lists.ietf.org Greetings. This message is a periodic reminder that calsch-archive@lists.ietf.org is subscribed to the ietf-calendar mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-calendar mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-calendar-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "calsch-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-calendar@mail.imc.org Fri Jan 9 10:48:04 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07987 for ; Fri, 9 Jan 2004 10:48:02 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06I59ib053609 for ; Tue, 6 Jan 2004 10:05:09 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i06I59YU053608 for ietf-calendar-bks; Tue, 6 Jan 2004 10:05:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06I58ib053603 for ; Tue, 6 Jan 2004 10:05:09 -0800 (PST) (envelope-from george.babics@oracle.com) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail1.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i06I4d3m025344 for ; Tue, 6 Jan 2004 10:05:05 -0800 (PST) Received: from rgmgw4.us.oracle.com (localhost [127.0.0.1]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i06I4V418442 for ; Tue, 6 Jan 2004 11:04:31 -0700 (MST) Received: from oracle.com (gbabics-ca.ca.oracle.com [144.23.213.222]) by rgmgw4.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i06I4U418421 for ; Tue, 6 Jan 2004 11:04:31 -0700 (MST) Message-ID: <3FFAF89D.9010904@oracle.com> Date: Tue, 06 Jan 2004 13:04:13 -0500 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: "and so this is Christmas, and what have you done?" References: <22F5CB4B-2B40-11D8-8033-000393C29C2A@skyrix.com> In-Reply-To: <22F5CB4B-2B40-11D8-8033-000393C29C2A@skyrix.com> 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 Helge Hess wrote: > > On 10.12.2003, at 19:14, pregen@egenconsulting.com wrote: > >> Helge, this is a great idea. It would be great if you can do that for >> us. > > > No problem, I've just created: > - a CALSCH product, which is the entry point for the group > - a component (read: topic/category) "general" for general issues > - a user "ietf-calendar@imc.org" which is set as the initial owner > for "general" issues (receives mail on each issue) > Should we have a topic/category for each rfc or draft, i.e., separate categories for iMIP, iTIP, CAP, and iCalendar? Even though our current focus is on CAP, people may want to submit issues or bugs relating to the other docs. George From owner-ietf-calendar@mail.imc.org Mon Jan 12 15:08:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15098 for ; Mon, 12 Jan 2004 15:08:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CJoTib002737; Mon, 12 Jan 2004 11:50:29 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CJoT2q002736; Mon, 12 Jan 2004 11:50:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CJoRib002731 for ; Mon, 12 Jan 2004 11:50:28 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:A6kuiTEFEfAuE52wDYDCoibrFjcvDTV2@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i0CJoPMX011353 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 12 Jan 2004 11:50:26 -0800 Message-ID: <4002FA81.2070401@Royer.com> Date: Mon, 12 Jan 2004 12:50:25 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: I-D ACTION:draft-royer-calsch-sched-ex-00.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060808080206070202000804" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060808080206070202000804 Content-Type: multipart/mixed; boundary="------------030206040407090102090301" This is a multi-part message in MIME format. --------------030206040407090102090301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI This is pass zero of iTIP and CAP examples. --------------------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : iCalendar Scheduling Author(s) : D. Royer Filename : draft-royer-calsch-sched-ex-00.txt Pages : 48 Date : 2004-1-7 A proposal to specify booked persistent data in calendar stores to track 'SEQUENCE' and 'DTSTAMP' property values for CUAs with direct access to calendar stores. With iMIP the iCalendar CUA's do not see the others stored CS data. With WebDAV, HTTP, or FTP access, the CUA can see into the public data of other calendars. The storage of persistent data mandated by [iTIP] has not been standardized yet. This memo proposes a way to standardize on those persistent items. Also included are ways to make the various ways of using the [iCAL] and [iTIP] 'RECURRENCE-ID' property work between vendors and to document the procedures to work with 'RECURRENCE-ID's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-royer-calsch-sched-ex-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-royer-calsch-sched-ex-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-royer-calsch-sched-ex-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------030206040407090102090301 Content-Type: Message/External-body; name="draft-royer-calsch-sched-ex-00.txt" Content-Disposition: inline; filename="draft-royer-calsch-sched-ex-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-7143502.I-D@ietf.org> --------------030206040407090102090301-- --------------ms060808080206070202000804 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwMTEyMTk1MDI1WjAjBgkqhkiG9w0BCQQxFgQU/7cqoy9ySrzS04tGcTKe ZbI4lhwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAhWKFGzxh6J5NLkJcjyRvDoDcs/CwaHYKX3J6SsxKOMl5Se1oeaXbUFNs+Mm6ALKI G4Rbt7tSN6QiJA46lhwT8C67cQMP0Ku5GZQFNZrGgRJ5gYexaXc5IypaC1Icl5YucD5N/nfm LS3yY/X11EKaICe4nNwZ5b8fPRYIlLvKfbqtqd6KTYKv3a940qz4iIwc8m70jP78Z8ICJ+Dx FTgh+kg1PTRnK71XYMEaE5aowppWV7WqcJ+QQPTcDZq/lUxwDmTz8nX9ReXr63NcKgmOEiMb rPpXFwo7GY9hTtjADGW3fL3tWVY2hukNBtKfDL13tI/WHRAQ8CkvdYxjlJdH4AAAAAAAAA== --------------ms060808080206070202000804-- From owner-ietf-calendar@mail.imc.org Mon Jan 12 15:19:05 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16830 for ; Mon, 12 Jan 2004 15:19:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CK7Cib003689; Mon, 12 Jan 2004 12:07:12 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CK7CHd003688; Mon, 12 Jan 2004 12:07:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CK7Aib003680 for ; Mon, 12 Jan 2004 12:07:10 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (IDENT:Zp+80d9axFY5FbYiifYoECdL3p8Yf/8t@inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i0CK78MX011794 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 12 Jan 2004 12:07:09 -0800 Message-ID: <4002FE6C.9040804@Royer.com> Date: Mon, 12 Jan 2004 13:07:08 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" Organization: http://INET-Consulting.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: draft-ietf-calsch-cap-12 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050204050705050901030200" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050204050705050901030200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I just submitted draft-ietf-calsch-cap-12. And I placed copies at: http://INET-Consulting.com/draft-ietf-calsch-cap-12.txt http://INET-Consulting.com/draft-ietf-calsch-cap-12.html http://INET-Consulting.com/draft-ietf-calsch-cap-12.xml -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050204050705050901030200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwMTEyMjAwNzA4WjAjBgkqhkiG9w0BCQQxFgQULPAd+Di9xmaT7nG7q9Qa mUx0JM8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAYN0kHFMnOC0zCdJRRbqy+M0jFeGS0PCr89FcjgzI1UnVlQ2eg7dD4GETLhzjIyIV Y+R/WhVN1+w6wi81FFTqBwg4rUMN1ukLG+2491xgSGoalG19BqyV72CyGjqXL8PID3Px1Vc1 yJ4AgCaCF/iozEpRWGAUg4RDbbvTXEDMLWGMIgfNtUNf1HTTtVgKGsCt8ax0Vo7azeEOo7cO udyWQWB/VUyaa6hMIJwIHqb6jIEGoVOuzWgMIn2gGRgZA5PsB+qeFPr5w+3GuV7g/djMtE1r 6rhywJ8LqHRpauHppImE6uns2QryeYaznwQhMPDA9Fx/dl2aCzeRfuvLhrx/fQAAAAAAAA== --------------ms050204050705050901030200-- From owner-ietf-calendar@mail.imc.org Tue Jan 13 16:04:32 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12890 for ; Tue, 13 Jan 2004 16:04:30 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DKp2ib064000; Tue, 13 Jan 2004 12:51:02 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DKp2Tw063999; Tue, 13 Jan 2004 12:51:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DKoxib063991 for ; Tue, 13 Jan 2004 12:51:00 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12128; Tue, 13 Jan 2004 15:50:59 -0500 (EST) Message-Id: <200401132050.PAA12128@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-calendar@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-cap-12.txt Date: Tue, 13 Jan 2004 15:50:59 -0500 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Calendar Access Protocol (CAP) Author(s) : D. Royer Filename : draft-ietf-calsch-cap-12.txt Pages : 143 Date : 2004-1-13 The Calendar Access Protocol (CAP) is an Internet protocol described in this memo that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [iCAL] based Calendar Store (CS). The CAP definition is based on requirements identified by the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) Working Group. More information about the IETF CALSCH Working Group activities can be found on the IMC web site at http:// www.imc.org/ietf-calendar and at the IETF web site at http:// www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the references within this memo for further information on how to access these various documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-cap-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-calsch-cap-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-13155900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-cap-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-cap-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-13155900.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-calendar@mail.imc.org Mon Jan 19 11:04:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23437 for ; Mon, 19 Jan 2004 11:04:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JFnLib019907; Mon, 19 Jan 2004 07:49:21 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JFnLVn019906; Mon, 19 Jan 2004 07:49:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.pspl.co.in (www.pspl.co.in [202.54.11.65] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JFnEib019888 for ; Mon, 19 Jan 2004 07:49:19 -0800 (PST) (envelope-from shriram_vishwanathan@persistent.co.in) Received: (from root@localhost) by smtp.pspl.co.in (8.12.9/8.12.9) id i0JFnHWq024890 for ; Mon, 19 Jan 2004 21:19:17 +0530 X-Scanned: XAM28400 Scanned by XAMIME Received: from ps1033 (PS1033.intranet.pspl.co.in [192.168.1.42]) (authenticated bits=0) by persistent.co.in (8.12.9/8.12.9) with ESMTP id i0JFnGhc024864; Mon, 19 Jan 2004 21:19:17 +0530 Message-ID: <031001c3dea3$c3a609e0$2a01a8c0@persistent.co.in> From: "Shriram V" To: Cc: "Shriram V" References: <002f01c3b418$d0401020$2a01a8c0@persistent.co.in> Subject: Errors in RRULE examples in RFC2445? Date: Mon, 19 Jan 2004 21:13:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-0.5 required=7.0 tests=REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, Is this an error in the RRULE examples in RFC 2445, in section 4.8.5.4? I have found that two of the rules in the RFC include the last occurrence, even though it occurs later than the UNTIL date-time. I tried searching though the mailing list archives, but could not find any previous postings on these errors. ======= [Page 119] Everyday in January, for 3 years: DTSTART;TZID=US-Eastern:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA or RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 ==> (1998 9:00 AM EDT)January 1-31 (1999 9:00 AM EDT)January 1-31 (2000 9:00 AM EDT)January 1-31 ======= 1. It should be EST instead of EDT? (A typo?) 2. Last occurrence (2000 09:00 Jan 31) should not be included. The last occurrence is on (2000 09:00 EST Jan 31) which is equivalent to (2000 14:00 UTC Jan 31). This is definitely later than UNTIL (2000 09:00 UTC Jan 31), so should be excluded. ======= [Page 125] Every 3 hours from 9:00 AM to 5:00 PM on a specific day: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z ==> (September 2, 1997 EDT)09:00,12:00,15:00 ======= 1. Again last occurrence (1997 15:00 PM Sep 2) should not be included. The last occurrence is on (1997 15:00 EDT Sep 2) which is equivalent to (1997 19:00 UTC Sep 2). This is definitely later than UNTIL (1997 17:00 UTC Sep 2), so should be excluded. Somebody please comment. Let me know if my interpretation is correct or not? Thanks, Shriram. From owner-ietf-calendar@mail.imc.org Mon Jan 19 13:23:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00600 for ; Mon, 19 Jan 2004 13:23:13 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JIAXib029272; Mon, 19 Jan 2004 10:10:33 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JIAXvv029271; Mon, 19 Jan 2004 10:10:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JIAWib029262 for ; Mon, 19 Jan 2004 10:10:32 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12: Bad changes to REQUEST-STATUS MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_01072004NP January 07, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 19 Jan 2004 13:03:26 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 01/19/2004 01:07:38 PM, Serialize complete at 01/19/2004 01:07:38 PM Content-Type: multipart/alternative; boundary="=_alternative 0063198585256E20_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063198585256E20_= Content-Type: text/plain; charset="US-ASCII" I see in the published CAP-12 draft that there is still a section for changes to REQUEST-STATUS. Besides being incorrectly listed under Section 8 New Properties (REQUEST-STATUS is _not_ a new property) the proposed change has no technical need for CAP or any actual WG discussion. The biggest problem I see with Section 8.28 REQUEST-STATUS property is a change to the base iCalendar REQUEST-STATUS defintion that is NOT backwards compatible effectively making the current iCalendar/iTIP/iMIP implementations unable to send/receive a CAP iCalendar stream (and would make a CAP parser treat a valid 2445 REQUEST-STATUS as incomplete). The current 2445 ABNF for REQUEST-STATUS is: rstatus = "REQUEST-STATUS" rstatparam ":" statcode ";" statdesc [";" extdata] rstatparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparm) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) statcode = 1*DIGIT *("." 1*DIGIT) ;Hierarchical, numeric return status code statdesc = text ;Textual status description extdata = text ;Textual exception data. For example, the offending property ;name and value or complete property line. text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) ; Folded according to description above (text added for reference). The proposed new ABNF for REQUEST-STATUS is: rstatus = "REQUEST-STATUS" rstatparam ":" statcode ";" [ statdesc ] ";" [ extdata ] Essentially the change is to _require_ the addition of an extra semicolon on REQUEST-STATUS. This has never been identified as a problem nor has there been any justification for this non-backwards compatible change even though the issue has been pointed out at least 2 times before now. Since statdesc is text and that can be 0 or more characters there is no actual need to change the ABNF to make statdesc optional; it can be derived already using the 2445 ABNF. Even the examples shown immediately below the text are incorrect given the changed ABNF: REQUEST-STATUS:2.0;Success violates the proposed ABNF. It MUST have a trialing semicolon after "Success". The same goes for ALL the other examples. I have no problems with the clear need for adding new classes of REQUEST-STATUS values (under statcode) but I do have a BIG problem with making an unnecessary change like this thats not backwards compatible AND fixes NO problem. I propose that we simply remove Section 8.28 entirely since it does nothing to describe the new changes it mentiones on page 17: REQUEST-STATUS - The [iCAL] "REQUEST-STATUS" property is extended to include new error numbers. (Section 8.28) or at a minimum we restore the RFC 2445 ABNF and just use Section 8.28 to provide a description of the new statclasses (as promised last Feb) instead. At least RFC 2445 had a desription of the classes that we need for CAP. Here is a snippet from 2445 that we need in CAP: The following are initial classes for the return status code. Individual iCalendar object methods will define specific return status codes for these classes. In addition, other classes for the return status code may be defined using the registration process defined later in this memo. |==============+===============================================| | Short Return | Longer Return Status Description | | Status Code | | |==============+===============================================| | 1.xx | Preliminary success. This class of status | | | of status code indicates that the request has | | | request has been initially processed but that | | | completion is pending. | ... 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 0063198585256E20_= Content-Type: text/html; charset="US-ASCII"
I see in the published CAP-12 draft that there is still a section for changes to REQUEST-STATUS.  Besides being incorrectly listed under Section 8  New Properties (REQUEST-STATUS is _not_ a new property) the proposed change has no technical need for CAP or any actual WG discussion.  

The biggest problem I see with Section 8.28 REQUEST-STATUS property is a change to the base iCalendar REQUEST-STATUS defintion that is NOT backwards compatible effectively making the current iCalendar/iTIP/iMIP implementations unable to send/receive a CAP iCalendar stream (and would make a CAP parser treat a valid 2445 REQUEST-STATUS as incomplete).

The current 2445 ABNF for REQUEST-STATUS is:

     rstatus    = "REQUEST-STATUS" rstatparam ":"
                 statcode ";" statdesc [";" extdata]

    rstatparam = *(
               ; the following is optional,
               ; but MUST NOT occur more than once
                (";" languageparm) /

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

               (";" xparam)
               )

    statcode   = 1*DIGIT *("." 1*DIGIT)
    ;Hierarchical, numeric return status code

    statdesc   = text
    ;Textual status description

    extdata    = text
    ;Textual exception data. For example, the offending property
    ;name and value or complete property line.

     text       = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
    ; Folded according to description above

(text added for reference).  The proposed new ABNF for REQUEST-STATUS is:

   rstatus  = "REQUEST-STATUS" rstatparam ":"
             statcode ";" [ statdesc ] ";" [ extdata ]
Essentially the change is to _require_ the addition of an extra semicolon on REQUEST-STATUS.  This has never been identified as a problem nor has there been any justification for this non-backwards compatible change even though the issue has been pointed out at least 2 times before now.  Since statdesc is text and that can be 0 or more characters there is no actual need to change the ABNF to make statdesc optional; it can be derived already using the 2445 ABNF.

Even the examples shown immediately below the text are incorrect given the changed ABNF:

   REQUEST-STATUS:2.0;Success

violates the proposed ABNF.  It MUST have a trialing semicolon after "Success".  The same goes for ALL the other examples.

I have no problems with the clear need for adding new classes of REQUEST-STATUS values (under statcode) but I do have a BIG problem with making an unnecessary change like this thats not backwards compatible AND fixes NO problem.

I propose that we simply remove Section 8.28 entirely since it does nothing to describe the new changes it mentiones on page 17:

   REQUEST-STATUS -  The [iCAL] "REQUEST-STATUS" property is extended to
     include new error numbers. (Section 8.28)
or at a minimum we restore the RFC 2445 ABNF and just use Section 8.28 to provide a description of the new statclasses (as promised last Feb) instead.  At least RFC 2445 had a desription of the classes that we need for CAP.  Here is a snippet from 2445 that we need in CAP:

   The following are initial classes for the return status code.
  Individual iCalendar object methods will define specific return
  status codes for these classes. In addition, other classes for the
  return status code may be defined using the registration process
  defined later in this memo.

    |==============+===============================================|
    | Short Return | Longer Return Status Description              |
    | Status Code  |                                               |
    |==============+===============================================|
    |    1.xx      | Preliminary success. This class of status     |
    |              | of status code indicates that the request has |
    |              | request has been initially processed but that |
    |              | completion is pending.                        |
...

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 0063198585256E20_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 19 13:30:35 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00875 for ; Mon, 19 Jan 2004 13:30:35 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JIL5ib029919; Mon, 19 Jan 2004 10:21:05 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JIL573029918; Mon, 19 Jan 2004 10:21:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JIL3ib029909 for ; Mon, 19 Jan 2004 10:21:04 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12: Stored queries STILL in? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_01072004NP January 07, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 19 Jan 2004 13:13:47 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 01/19/2004 01:18:10 PM, Serialize complete at 01/19/2004 01:18:10 PM Content-Type: multipart/alternative; boundary="=_alternative 00640C4085256E20_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00640C4085256E20_= Content-Type: text/plain; charset="US-ASCII" In rescanning CAP-12 for changes I see that the editors have not removed all vestiges of stored queries from CAP 1.0. There is still text on QUERYID (8.27 QUERYID property) and several examples that use QUERYID. These should be removed for CAP 1.0 and be just part of any CAP followon that describes a stored query mechanism. In addition VQUERYs are still part of the object model in Section 3.2 Calendar Store Object Model. This too should be removed and proposed in the followon work. Otherwise CAP 1.0 will implicitly, if not explicitly, mandate that a CS MUST support stored VQUERYs which is not a reasonable requirement as we've covered ad naseum over the past 2 years. I propose that the QUERYID section be removed, the VQUERYs be removed from the model diagram (pp 20 & 21) and that QUERYID be removed from all examples. All the text can be moved to any followon work that stored query proponents want to propose for consideration. 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 00640C4085256E20_= Content-Type: text/html; charset="US-ASCII"
In rescanning CAP-12 for changes I see that the editors have not removed all vestiges of stored queries from CAP 1.0.  There is still text on QUERYID (8.27 QUERYID property) and several examples that use QUERYID.  These should be removed for CAP 1.0 and be just part of any CAP followon that describes a stored query mechanism.

In addition VQUERYs are still part of the object model in Section 3.2 Calendar Store Object Model.  This too should be removed and proposed in the followon work.

Otherwise CAP 1.0 will implicitly, if not explicitly, mandate that a CS MUST support stored VQUERYs which is not a reasonable requirement as we've covered ad naseum over the past 2 years.  I propose that the QUERYID section be removed, the VQUERYs be removed from the model diagram (pp 20 & 21) and that QUERYID be removed from all examples.  All the text can be moved to any followon work that stored query proponents want to propose for consideration.
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 00640C4085256E20_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 19 13:55:39 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01995 for ; Mon, 19 Jan 2004 13:55:38 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JIirib031073; Mon, 19 Jan 2004 10:44:53 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JIirh3031072; Mon, 19 Jan 2004 10:44:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JIirib031063 for ; Mon, 19 Jan 2004 10:44:53 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12: 10.12.1 Searching for VFREEBUSY MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_01072004NP January 07, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 19 Jan 2004 13:41:12 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 01/19/2004 01:41:59 PM, Serialize complete at 01/19/2004 01:41:59 PM Content-Type: multipart/alternative; boundary="=_alternative 00668ECB85256E20_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00668ECB85256E20_= Content-Type: text/plain; charset="US-ASCII" In checking out my last big concerns in CAP I ran across some text in Section 10.12.1 Searching for VFREEBUSY that I think may be wrong (or at least unclear). In general, I think the new text is a big improvment and Im glad to see it. However I would like to make it clearer to avoid any confusion. The latest CAP-12 draft says: 10.12.1 Searching for VFREEBUSY If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the "VFREEBUSY" component in the "COMPONENTS" value in a reply to the "GET-CAPABILITY" command, then it is the CS's responsibility and not the CUA's responsibility to provide the correct "VFREEBUSY" information for a calendar. [Snip, snip] Such a CS MUST dynamically create the results of a search for "VFREEBUSY" components at search time when searching for STATE() = 'BOOKED' items. For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE" and have the "VFREEBUSY" component in the "COMPONENTS" value in the "CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information on the CS. These CSs then MUST return a "VFREEBUSY" component calculated from the stored components. If no "VFREEBUSY" information is available for the "TARGET" calendar, then a "VFREEBUSY" with no blocked out time will be returned with a success code. A CUA sets the "VFREEBUSY" time on a those calendars by creating a "VFREEBUSY" component without a "METHOD" creating a "BOOKED" entry. If a CS does not set the "VFREEBUSY" value in the "COMPONENTS" "CAPABILITY" value, the CS does not support the "VFREEBUSY" component and all creation and searching for a "VFREEBUSY" component MUST fail. Examples of calendars that may be in this category are public event calendars that will never require scheduling with other UPNs. First off, why is VFREEBUSY contingent on the CS's ability or inability to RECUR-EXPAND? Since RECUR-EXPAND is defined as: Description: If TRUE then the endpoint can expand an object into multiple instances as defined by its recurrence rules when the "EXPAND" property is supplied. If FALSE then the endpoint ignores the "EXPAND" property. it merely tells the CUA if the CS supports result expansion or not. It has _nothing_ to do with the CS's ability (or inability) to handle repeat instances internally and thus generate the correct VFREEBUSY on demand. As I read the text above it appears as if BOTH the "RECUR-EXPAND:TRUE" and "RECUR-EXPAND:FALSE" CSs will do the same thing anyway (or close to it). That is, for the TRUE case: a CS MUST dynamically create the results of a search for "VFREEBUSY" components at search time when searching for STATE() = 'BOOKED' items. and for the FALSE case: These CSs then MUST return a "VFREEBUSY" component calculated from the stored components. These are nearly identical except that in the FALSE case it appears as if the data could reflect STATE() != BOOKED items. This is not good and probably a phrasing issue rather than a technical one. After all, I doubt the intent is to have th CS, in this case, return VFREEBUSY that reflects pending invitations or reschedules that the CU has not yet taken any action on. Secondly, the text in the 3rd cited paragraph above is self contradictory. First it says "CUA MAY store the "VFREEBUSY" information on the CS" but then it goes on to say "These CSs then MUST return a "VFREEBUSY" component calculated from the stored components." I believe the former sentence is incorrect or at least poorly phrased and that the latter sentence is 100% accurate (with the caveat about "stored components" above). A CUA should NOT be able to modify the VFREEBUSY for a calendar in such a way that it does NOT reflect the calendars contents. Otherwise it is possible for a CUA to make the VFREEBUSY data not reflect the calendars contents at all and this is not goodness. I think that by simply removing the text "a CUA MAY store the "VFREEBUSY" information on the CS" should resolve this (although it would mean a slight editoral change to the first half of that sentence to be useful) will resolve this potential disasterous feature. Finally, I wonder about the text: A CUA sets the "VFREEBUSY" time on a those calendars by creating a "VFREEBUSY" component without a "METHOD" creating a "BOOKED" entry. This appears to allow a CUA to create VFREEBUSY data (for the CS to preserve) that does NOT reflect the actual contents of the actual calendar. Why would we want to make the VFREEBUSY data NOT accurately represent the state of the calendars booked contents?? If there is nothing on the calendar or it ALL entries that have TRANSP:TRANSPARENT or TRANSP:TRANSPARENT-NOCONFLICT properties then one would expect a VFREEBUSY with no FREEBUSY properties in it, NOT something the CUA may have forged. 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... Warning: Dates in Calendar are closer than they appear. --=_alternative 00668ECB85256E20_= Content-Type: text/html; charset="US-ASCII"
In checking out my last big concerns in CAP I ran across some text in Section 10.12.1 Searching for VFREEBUSY that I think may be wrong (or at least unclear).  In general, I think the new text is a big improvment and Im glad to see it.  However I would like to make it clearer to avoid any confusion.  The latest CAP-12 draft says:

10.12.1 Searching for VFREEBUSY

  If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the
  "VFREEBUSY" component in the "COMPONENTS" value in a reply to the
  "GET-CAPABILITY" command, then it is the CS's responsibility and not
  the CUA's responsibility to provide the correct "VFREEBUSY"
  information for a calendar.

[Snip, snip]

   Such a CS MUST dynamically create the results of a search for
  "VFREEBUSY" components at search time when searching for STATE() =
  'BOOKED' items.

  For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE"
  and have the "VFREEBUSY" component in the "COMPONENTS" value in the
  "CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information on
  the CS. These CSs then MUST return a "VFREEBUSY" component calculated
  from the stored components. If no "VFREEBUSY" information is
  available for the "TARGET" calendar, then a "VFREEBUSY" with no
  blocked out time will be returned with a success code. A CUA sets the
  "VFREEBUSY" time on a those calendars by creating a "VFREEBUSY"
  component without a "METHOD" creating a "BOOKED" entry.

  If a CS does not set the "VFREEBUSY" value in the "COMPONENTS"
  "CAPABILITY" value, the CS does not support the "VFREEBUSY" component
  and all creation and searching for a "VFREEBUSY" component MUST fail.
  Examples of calendars that may be in this category are public event
  calendars that will never require scheduling with other UPNs.
First off, why is VFREEBUSY contingent on the CS's ability or inability to RECUR-EXPAND?   Since RECUR-EXPAND is defined as:

   Description: If TRUE then the endpoint can expand an object into
  multiple instances as defined by its recurrence rules when the
  "EXPAND" property is supplied. If FALSE then the endpoint ignores the
  "EXPAND" property.
it merely tells the CUA if the CS supports result expansion or not.  It has _nothing_ to do with the CS's ability (or inability) to handle repeat instances internally and thus generate the correct VFREEBUSY on demand.  

As I read the text above it appears as if BOTH the "RECUR-EXPAND:TRUE" and "RECUR-EXPAND:FALSE" CSs will do the same thing anyway (or close to it).  That is, for the TRUE case:

         a CS MUST dynamically create the results of a search for
  "VFREEBUSY" components at search time when searching for STATE() =
  'BOOKED' items.

and for the FALSE case:

           These CSs then MUST return a "VFREEBUSY" component calculated
  from the stored components.

These are nearly identical except that in the FALSE case it appears as if the data could reflect STATE() != BOOKED items.  This is not good and probably a phrasing issue rather than a technical one.  After all, I doubt the intent is to have th CS, in this case, return VFREEBUSY that reflects pending invitations or reschedules that the CU has not yet taken any action on.

Secondly, the text in the 3rd cited paragraph above is self contradictory.  First it says "CUA MAY store the "VFREEBUSY" information on the CS" but then it goes on to say "These CSs then MUST return a "VFREEBUSY" component calculated from the stored components."  I believe the former sentence is incorrect or at least poorly phrased and that the latter sentence is 100% accurate (with the caveat about "stored components" above).   A CUA should NOT be able to modify the VFREEBUSY for a calendar in such a way that it does NOT reflect the calendars contents.  Otherwise it is possible for a CUA to make the VFREEBUSY data not reflect the calendars contents at all and this is not goodness.

I think that by simply removing the text "a CUA MAY store the "VFREEBUSY" information on the CS" should resolve this (although it would mean a slight editoral change to the first half of that sentence to be useful) will resolve this potential disasterous feature.

Finally, I wonder about the text:

                                                     A CUA sets the
  "VFREEBUSY" time on a those calendars by creating a "VFREEBUSY"
  component without a "METHOD" creating a "BOOKED" entry.

This appears to allow a CUA to create VFREEBUSY data (for the CS to preserve) that does NOT reflect the actual contents of the actual calendar.  Why would we want to make the VFREEBUSY data NOT accurately represent the state of the calendars booked contents??  If there is nothing on the calendar or it ALL entries that have TRANSP:TRANSPARENT or TRANSP:TRANSPARENT-NOCONFLICT properties then one would expect a VFREEBUSY with no FREEBUSY properties in it, NOT something the CUA may have forged.

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...
Warning: Dates in Calendar are closer than they appear. --=_alternative 00668ECB85256E20_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 19 14:11:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02766 for ; Mon, 19 Jan 2004 14:11:24 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JJ0xib032270; Mon, 19 Jan 2004 11:00:59 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JJ0xBf032269; Mon, 19 Jan 2004 11:00:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JJ0wib032263 for ; Mon, 19 Jan 2004 11:00:58 -0800 (PST) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-12: 8.16 EXPAND property MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_01072004NP January 07, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 19 Jan 2004 13:58:05 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 01/19/2004 01:58:04 PM, Serialize complete at 01/19/2004 01:58:04 PM Content-Type: multipart/alternative; boundary="=_alternative 00681A8A85256E20_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00681A8A85256E20_= Content-Type: text/plain; charset="US-ASCII" Ok, we didnt get an answer to my question on EXPAND with time bounded searches so I wanted to ask again. The current description of EXPAND is: Description: If a CUA wishes to see all of the instances of a recurring component the CUA sets EXPAND=TRUE in the "VQUERY" component. If not specified, the default is FALSE. Note that if the CS has its "RECUR-EXPAND" CS property value set to false then the "EXPAND" property will be ignored and the result will be as if the "EXPAND" value was set to false. The results will be bounded by any date range or other limits in the query. In trying to get my head around the use of EXPAND before I noted that its unclear and quite ambiguous what the CS should do for a VQUERY that has both a time range as part of the WHERE selection subclause and the EXPAND:TRUE property. I can see the scenarios for when a CUA would or would not use EXPAND to get the correct results but nowhere in CAP do I see where it deals with the ambiguous case of: BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE DTSTART >= '20031208T050000Z' AND DTEND <= '20031213T045959Z' AND STATE() = 'BOOKED' END:VQUERY In the interest of getting this resolved faster I thought Id propose that CAP be changed to either prevent the above query or to specify a consistant behaviour by all CS. I propose that the following text be added to Section 8.16 EXPAND property: The "EXPAND" propety MAY NOT be included in a VQUERY that component that contains any WHERE clause that specify a bounding or specific date-time related search criteria. If a CS receives such a VQUERY, it MUST ignore the EXPAND property. For example, if the CUA sends: BEGIN:VQUERY EXPAND:TRUE QUERY:SELECT * FROM VEVENT WHERE DTSTART >= '20031208T050000Z' AND DTEND <= '20031213T045959Z' AND STATE() = 'BOOKED' END:VQUERY then the CS would treat the VQUERY as if it were just: BEGIN:VQUERY QUERY:SELECT * FROM VEVENT WHERE DTSTART >= '20031208T050000Z' AND DTEND <= '20031213T045959Z' AND STATE() = 'BOOKED' END:VQUERY This also means that when stored queries are reproposed they too will be covered from the CUA sending EXPAND:TRUE and the stored VQUERY containing the same kinds of date-time search criterias. Editorial note: the 'false' in lines 4 & 6 at top should 'FALSE'. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Warning: Dates in Calendar are closer than they appear. --=_alternative 00681A8A85256E20_= Content-Type: text/html; charset="US-ASCII"
Ok, we didnt get an answer to my question on EXPAND with time bounded searches so I wanted to ask again.  The current description of EXPAND is:

   Description: If a CUA wishes to see all of the instances of a
  recurring component the CUA sets EXPAND=TRUE in the "VQUERY"
  component. If not specified, the default is FALSE. Note that if the
  CS has its "RECUR-EXPAND" CS property value set to false then the
  "EXPAND" property will be ignored and the result will be as if the
  "EXPAND" value was set to false. The results will be bounded by any
  date range or other limits in the query.
In trying to get my head around the use of EXPAND before I noted that its unclear and quite ambiguous what the CS should do for a VQUERY that has both a time range as part of the WHERE selection subclause and the EXPAND:TRUE property.  I can see the scenarios for when a CUA would or would not use EXPAND to get the correct results but nowhere in CAP do I see where it deals with the ambiguous case of:

          BEGIN:VQUERY
         EXPAND:TRUE
         QUERY:SELECT * FROM VEVENT
         WHERE DTSTART >= '20031208T050000Z'
         AND DTEND <= '20031213T045959Z'
         AND STATE() = 'BOOKED'
         END:VQUERY

In the interest of getting this resolved faster I thought Id propose that CAP be changed to either prevent the above query or to specify a consistant behaviour by all CS.  I propose that the following text be added to Section 8.16 EXPAND property:

   The "EXPAND" propety MAY NOT be included in a VQUERY that component that
   contains any WHERE clause that specify a bounding or specific date-time
   related search criteria.  If a CS receives such a VQUERY, it MUST
   ignore the EXPAND property.  For example, if the CUA sends:

         BEGIN:VQUERY
         EXPAND:TRUE
         QUERY:SELECT * FROM VEVENT
         WHERE DTSTART >= '20031208T050000Z'
         AND DTEND <= '20031213T045959Z'
         AND STATE() = 'BOOKED'
         END:VQUERY

   then the CS would treat the VQUERY as if it were just:

          BEGIN:VQUERY
         QUERY:SELECT * FROM VEVENT
         WHERE DTSTART >= '20031208T050000Z'
         AND DTEND <= '20031213T045959Z'
         AND STATE() = 'BOOKED'
         END:VQUERY

This also means that when stored queries are reproposed they too will be covered from the CUA sending EXPAND:TRUE and the stored VQUERY containing the same kinds of date-time search criterias.

Editorial note: the 'false' in lines 4 & 6 at top should 'FALSE'.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear. --=_alternative 00681A8A85256E20_=-- From owner-ietf-calendar@mail.imc.org Mon Jan 19 14:20:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03155 for ; Mon, 19 Jan 2004 14:20:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JJATib032647; Mon, 19 Jan 2004 11:10:29 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JJATa3032646; Mon, 19 Jan 2004 11:10:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JJARib032639 for ; Mon, 19 Jan 2004 11:10:27 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i0JJAJkN007741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 Jan 2004 11:10:22 -0800 Message-ID: <400C2B9B.7060307@Royer.com> Date: Mon, 19 Jan 2004 12:10:19 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12: Stored queries STILL in? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090503000601060105080106" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090503000601060105080106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As you know Bruce, stored queries have been in CAP since -00 and there has been no consensus called to remove them. The ability to support PDA's and low memory devices was in the CAP requirements specificaiton that was the reason they were created. It has been requested by you as you put it 'ad naseum over the past 2 years.' and we all know you do not want them. I have also checked the bugzilla database, no such action items exist. Bruce_Kahn@notesdev.ibm.com wrote: > > In rescanning CAP-12 for changes I see that the editors have not > removed all vestiges of stored queries from CAP 1.0. There is still > text on QUERYID (8.27 QUERYID property) and several examples that use > QUERYID. These should be removed for CAP 1.0 and be just part of any > CAP followon that describes a stored query mechanism. > > In addition VQUERYs are still part of the object model in Section 3.2 > Calendar Store Object Model. This too should be removed and proposed > in the followon work. > > Otherwise CAP 1.0 will implicitly, if not explicitly, mandate that a > CS MUST support stored VQUERYs which is not a reasonable requirement > as we've covered ad naseum over the past 2 years. I propose that the > QUERYID section be removed, the VQUERYs be removed from the model > diagram (pp 20 & 21) and that QUERYID be removed from all examples. > All the text can be moved to any followon work that stored query > proponents want to propose for consideration. > > 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... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090503000601060105080106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwMTE5MTkxMDE5WjAjBgkqhkiG9w0BCQQxFgQU4mZPNTLHAG6Z3hPcIGRg THQM/uEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAO10PHTgZyHg8IqKWMATyxQEyR88jlBrF19ivWTR+FFT+oeqPZvW8Jklct18y6a7w UlzgdoSlooCa4vSONBjez5mUfHT8ehg9MbyQQvwDitK2HKz5eWs3DH7NSYKw+UFbk2NDsswl XNNNPZ3+maes2CYKRTzXapRPq23hTzO6JN6LtWvwLjwOtZ+saOKAvMoxMXNk9ApFODBJNA/E ltlFhqIQXwHkyU00ZbgDLTgs/aYOFeiIbExkZZuTVw06t8LqHZcafAXAiK0S1c1TZJvoGii6 +RSbIjq76ZWNixH6dwdvpekZnHUBNZHGcLf/22j8OewkW9xcyz6l6UJyDuQMzgAAAAAAAA== --------------ms090503000601060105080106-- From owner-ietf-calendar@mail.imc.org Mon Jan 19 15:04:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05229 for ; Mon, 19 Jan 2004 15:04:37 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JJtRib035251; Mon, 19 Jan 2004 11:55:27 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JJtRfB035250; Mon, 19 Jan 2004 11:55:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JJtPib035243 for ; Mon, 19 Jan 2004 11:55:25 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i0JJtMkN008482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 Jan 2004 11:55:24 -0800 Message-ID: <400C362A.7030708@Royer.com> Date: Mon, 19 Jan 2004 12:55:22 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12: Bad changes to REQUEST-STATUS References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020401070106020608060005" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020401070106020608060005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > I see in the published CAP-12 draft that there is still a section for > changes to REQUEST-STATUS. Besides being incorrectly listed under > Section 8 New Properties (REQUEST-STATUS is _not_ a new property) the > proposed change has no technical need for CAP or any actual WG > discussion. Read the archives and you will find that YOU posted the following on the subject of CAP as part of the the error code debate. "Imprecise statement on my part and assumptions on the part of others. My most recent suggestion to Lisa was "... the current RFC 2445 format for Response-Status cannot be used.". [and we assumed you meant REQUEST-STATUS as there is no 'RESPONSE-STATUS'] There was no unilateral change or addition to CAP even i f the the text entered was or was not exactly what you posted. Now you seem to be saying that it can be used. "as is". That is fine, but please do not say there was no actual WG discussion as you participated in that actual WG discussion. (that is just one of several posts you made on the subject) So what are you now saying? Also, it is not a compatibility issue as ALL iTIP messages must be first processed by a CUA and in many cases already tweaked for the CS. And yes I agree it would be a pain, but as no CS objects exist yet, it can not be a compatibly issue. So as it has been in CAP for a while and the chairs have not called any consensus to change it, and as it was discussed, and as it is not in the action item list (bugzilla); I for one can not unilaterally change it back to be the current RFC 2445 format for Request-Status. Does anyone else care which format we use? AND: I have entered a bugzilla issue to move it FROM the 'new' properties section. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms020401070106020608060005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwMTE5MTk1NTIyWjAjBgkqhkiG9w0BCQQxFgQUFXT6BjJ2wR3XmT//mHvV jglMXCYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAitn51SdY5CAimF12A1ffh4OtbBseB7KFNAIaW4A08jGy7DvHIVrDOvb2gnvOoKUW 12qQnf5z5U0maVu0EmKK/cUdO44YRkqJIBgLs+A11Brky32W/hm9EKoWf/tMNJlPjTjeAcAM dUVFYVC01FS/pl7sieQggUvRv5+Nz+WQlIUkgR5jIXmq7KsIvwYrKrzvwPLE+DnSIYcq53fa w5OnH9h5lZN5Si6QbL8VeAvOTYb8EkvYxNiX7BX8+dXD2QiKRlHQR0YTT6YuigLHTia+/H8g sy5IcF2ScwNRyT2GhGdHjulS42hyv1NlvnncKTJaHUJacsu4+Lz0wYwImrFc9gAAAAAAAA== --------------ms020401070106020608060005-- From owner-ietf-calendar@mail.imc.org Mon Jan 19 15:06:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05331 for ; Mon, 19 Jan 2004 15:06:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JJvvib035385; Mon, 19 Jan 2004 11:57:57 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JJvvjQ035384; Mon, 19 Jan 2004 11:57:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JJvtib035379 for ; Mon, 19 Jan 2004 11:57:56 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i0JJvqkN008506 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 Jan 2004 11:57:54 -0800 Message-ID: <400C36C0.2040601@Royer.com> Date: Mon, 19 Jan 2004 12:57:52 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Errors in RRULE examples in RFC2445? References: <002f01c3b418$d0401020$2a01a8c0@persistent.co.in> <031001c3dea3$c3a609e0$2a01a8c0@persistent.co.in> In-Reply-To: <031001c3dea3$c3a609e0$2a01a8c0@persistent.co.in> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040702000000020808050409" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040702000000020808050409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I added a bug to track this. (BUG #573) Shriram V wrote: >Hi all, > > >Is this an error in the RRULE examples in RFC 2445, in section 4.8.5.4? > >I have found that two of the rules in the RFC include the last occurrence, >even though it occurs later than the UNTIL date-time. > >I tried searching though the mailing list archives, but could not find any >previous postings on these errors. > > > >======= >[Page 119] >Everyday in January, for 3 years: > > DTSTART;TZID=US-Eastern:19980101T090000 > RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; > BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA > or > RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 > > ==> (1998 9:00 AM EDT)January 1-31 > (1999 9:00 AM EDT)January 1-31 > (2000 9:00 AM EDT)January 1-31 >======= > >1. It should be EST instead of EDT? (A typo?) >2. Last occurrence (2000 09:00 Jan 31) should not be included. > >The last occurrence is on (2000 09:00 EST Jan 31) >which is equivalent to (2000 14:00 UTC Jan 31). > >This is definitely later than UNTIL (2000 09:00 UTC Jan 31), >so should be excluded. > > >======= >[Page 125] >Every 3 hours from 9:00 AM to 5:00 PM on a specific day: > > DTSTART;TZID=US-Eastern:19970902T090000 > RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z > > ==> (September 2, 1997 EDT)09:00,12:00,15:00 >======= > > >1. Again last occurrence (1997 15:00 PM Sep 2) should not be included. > >The last occurrence is on (1997 15:00 EDT Sep 2) >which is equivalent to (1997 19:00 UTC Sep 2). > >This is definitely later than UNTIL (1997 17:00 UTC Sep 2), >so should be excluded. > > > > > >Somebody please comment. >Let me know if my interpretation is correct or not? > > > >Thanks, >Shriram. > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040702000000020808050409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwMTE5MTk1NzUyWjAjBgkqhkiG9w0BCQQxFgQUI4m9gzYqjWpk4MyI1g6I olcZhXgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA1mU/7ZC2hf/t4TPu4R2cDGDnR28ZWrt3DcMmUn8kUmGWYAhz4ATgBaVpuhS+0Sr5 VFOtvDVzkKNnw/5Zg6rmSFGW2XQjfKHEcDps228wecT544fTs3RUIz+PyLpEYVRKxiu3c0PQ SqOsR0Iqp48sTchsUCVowHdUCpQqQoymaPi2542hkWOyWz9kqgZ8xMdYAkh+Fgv2pCKfuheL z5l0yvwwtUroT9/TyvmKENsR+qNOBPcq3zwmJdyf3tzAfKr2Im2aqs9Yfm8ovJDSv97enYe+ Gk0aE2/XLdq4OjI7nNPNKvUsWIbrbETEN52Xl0HZYSASIVMMzKEu4+aHm9+OVgAAAAAAAA== --------------ms040702000000020808050409-- From owner-ietf-calendar@mail.imc.org Mon Jan 19 15:14:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06125 for ; Mon, 19 Jan 2004 15:14:42 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JK70ib035825; Mon, 19 Jan 2004 12:07:00 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JK70sV035824; Mon, 19 Jan 2004 12:07:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JK6wib035819 for ; Mon, 19 Jan 2004 12:06:58 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i0JK6ukN008718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 Jan 2004 12:06:58 -0800 Message-ID: <400C38E0.7080902@Royer.com> Date: Mon, 19 Jan 2004 13:06:56 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12: 10.12.1 Searching for VFREEBUSY (expand) References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030004040808030606030407" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030004040808030606030407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > First off, why is VFREEBUSY contingent on the CS's ability or > inability to RECUR-EXPAND? Since RECUR-EXPAND is defined as: If the CS allows the CUA to store non-expanted objects. AND IF the CS can NOT expand objects. Then there is NO WAY the CS can auto-expand them and create a dynamic VFREEBUSY object as many on this WG list want. This is an iTIP problem as well as there is NO requirement for iTIP endpoints to all support recurring rules. And we covered this already last month and in the discussions that led up to the text being inserted. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030004040808030606030407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwMTE5MjAwNjU2WjAjBgkqhkiG9w0BCQQxFgQUKKFLE2M4zRqj3jEGfyOe hGkoPQEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA0Rh1sC5Pl77jF9h+yG/KQi6yawOOSb8a4LMI1YIrLcb9DtczqJd+mNs06rzyW8gR JzkgAwd//esxZrIw/ei0a07KmaevJ3xHs3bOWFsjx8T/s5dT7JmRfSHP0Stk8jN4mzCklJ+e Oat6gfh9Cblszt9RoKQmXUBTHVKL7w06JpGpInvFgZIjFzUIY8WcZyilEKIRgeSl+E7lTg5l tM6jOyZvlG5t6/yfAbakDZuCZO2AcTtuFILvetdEimAQ+ErxJE3INXTFUlq63+xtOfflx/Gp Dyd8PTI8Dpv74Re8cHtsakBxKHZHElWXPyDZcrYB1UbF80xsaYwo8PQcDB1+8gAAAAAAAA== --------------ms030004040808030606030407-- From owner-ietf-calendar@mail.imc.org Mon Jan 19 15:29:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07591 for ; Mon, 19 Jan 2004 15:29:58 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JKHbib036532; Mon, 19 Jan 2004 12:17:37 -0800 (PST) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0JKHbXS036531; Mon, 19 Jan 2004 12:17:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0JKHZib036524 for ; Mon, 19 Jan 2004 12:17:36 -0800 (PST) (envelope-from Doug@Royer.com) Received: from Royer.com (inet-products.com [12.110.13.100]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i0JKHUkN008874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 19 Jan 2004 12:17:32 -0800 Message-ID: <400C3B5A.7010801@Royer.com> Date: Mon, 19 Jan 2004 13:17:30 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP-12: 10.12.1 Searching for VFREEBUSY References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080508000602080609040702" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080508000602080609040702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > As I read the text above it appears as if BOTH the "RECUR-EXPAND:TRUE" > and "RECUR-EXPAND:FALSE" CSs will do the same thing anyway (or close > to it). That is, for the TRUE case: > > a CS MUST dynamically create the results of a search for > "VFREEBUSY" components at search time when searching for STATE() = > 'BOOKED' items. > > and for the FALSE case: > > These CSs then MUST return a "VFREEBUSY" component calculated > from the stored components. > > These are nearly identical except that in the FALSE case it appears as > if the data could reflect STATE() != BOOKED items. This is not good > and probably a phrasing issue rather than a technical one. After all, > I doubt the intent is to have the CS, in this case, return VFREEBUSY > that reflects pending invitations or reschedules that the CU has not > yet taken any action on. Now it is up to the CUA and it can ask and get what it wants in both cases. What is the problem? > > Secondly, the text in the 3rd cited paragraph above is self > contradictory. First it says "CUA MAY store the "VFREEBUSY" > information on the CS" but then it goes on to say "These CSs then MUST > return a "VFREEBUSY" component calculated from the stored components." > I believe the former sentence is incorrect or at least poorly phrased > and that the latter sentence is 100% accurate (with the caveat about > "stored components" above). A CUA should NOT be able to modify the > VFREEBUSY for a calendar in such a way that it does NOT reflect the > calendars contents. Otherwise it is possible for a CUA to make the > VFREEBUSY data not reflect the calendars contents at all and this is > not goodness. As we discussed already, the current iTIP VFREEBUSY model is calculated by the CUA taking into account optionally more than one calendars. The CAP VFREEBUSY is calculated by the CS without knowledge of other calendars. > > I think that by simply removing the text "a CUA MAY store the > "VFREEBUSY" information on the CS" should resolve this (although it > would mean a slight editorial change to the first half of that > sentence to be useful) will resolve this potential disastrous feature. If we remove that, then we do not keep iTIP compatibility. As currently the CUA send and calculate the VFREEBUSY components that may or might not be the same as the busy time on the one specific CAP calendar. > > Finally, I wonder about the text: > > A CUA sets the > "VFREEBUSY" time on a those calendars by creating a "VFREEBUSY" > component without a "METHOD" creating a "BOOKED" entry. > > This appears to allow a CUA to create VFREEBUSY data (for the CS to > preserve) that does NOT reflect the actual contents of the actual > calendar. Why would we want to make the VFREEBUSY data NOT accurately > represent the state of the calendars booked contents?? That is the way iTIP works now. The CUA and not the CS calculates the VFREEBUSY time. Now both work. > If there is nothing on the calendar or it ALL entries that have > TRANSP:TRANSPARENT or TRANSP:TRANSPARENT-NOCONFLICT properties then > one would expect a VFREEBUSY with no FREEBUSY properties in it, NOT > something the CUA may have forged. No more or less than now with iTIP and pre-CAP. And again ask for the calculated VFREEBUSY if you want the CS calculated VFREEBUSY. And ask for any iTIP VFREEBUSY when you want the CUA calculated VFREEBUSY. We keep 100% compatibility with pre-CAP iTIP. And add the ability to get CS calculated VFREEBUSY results. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms080508000602080609040702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwOTA1MDAw MDAwWhcNMDQwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDi FrziCN+FurdNQ/2OjWQ2cPma6FA/JclI72S1HGVR4O26cGshcVxF+88JJrmaUzq+6+gtwYdb MjxtcxhaR7EZNyxXA/f212YKUPeJ3pS78c+DHECtoI7lh+bumUBG9PjZwpoTu6bPP3wnubWg X8BhyF+4GGUd0bivtJ3qUtc3HeN2WQYgeThrGkfiPr4iRMkb1WEQOyH5Mh6RH6LxZeDPu3gE 1LEFltsW4nzIbvJKQpsBRTMTa3ydV9xt/IPb3IGXwYVp+3U+/NXszPq1OWPZkPeBSwKnZb91 OpY1Ojc+WYxyQnIeVe25KwRvd6SEzEZeQUl/+UQMiDyaIYxJNIb9AgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAg54AMDj1T1zZRJE0VFN59HFABYyC0jOHaXE4 X11kw5EsaYc4pWpQ9oAvIDxxYO+chYmzuDQ4P6ZClUUFOKw/XhMriZeGgcjL4oewSkMwzpqz ZjnXXLc/Z/nudGdYcrB/ziy9Ea5I4ba4JZUpJbOBtAkaPeMEDZO2Kx52oEDnNKIwggUBMIIE aqADAgECAhAx/45t+4N8u/W/18pTNBTCMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkwNTAwMDAwMFoXDTA0MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4ha84gjfhbq3TUP9 jo1kNnD5muhQPyXJSO9ktRxlUeDtunBrIXFcRfvPCSa5mlM6vuvoLcGHWzI8bXMYWkexGTcs VwP39tdmClD3id6Uu/HPgxxAraCO5Yfm7plARvT42cKaE7umzz98J7m1oF/AYchfuBhlHdG4 r7Sd6lLXNx3jdlkGIHk4axpH4j6+IkTJG9VhEDsh+TIekR+i8WXgz7t4BNSxBZbbFuJ8yG7y SkKbAUUzE2t8nVfcbfyD29yBl8GFaft1PvzV7Mz6tTlj2ZD3gUsCp2W/dTqWNTo3PlmMckJy HlXtuSsEb3ekhMxGXkFJf/lEDIg8miGMSTSG/QIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBAIOeADA49U9c2USRNFRTefRxQAWMgtIzh2lxOF9dZMORLGmHOKVq UPaALyA8cWDvnIWJs7g0OD+mQpVFBTisP14TK4mXhoHIy+KHsEpDMM6as2Y511y3P2f57nRn WHKwf84svRGuSOG2uCWVKSWzgbQJGj3jBA2TtisedqBA5zSiMYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/X ylM0FMIwCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQwMTE5MjAxNzMwWjAjBgkqhkiG9w0BCQQxFgQUkRJuqvIbW4DuyAxAFHs2 o59gp1EwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAHQsM/RczS/WrJ/6VKZ4noY9386Kpjrg/z2uJ7NFd9/J3BNVkY/fwV4TyGcbiLq0b XKVt+9Y/TwUfZE4aKM5Ta+8pmkyN/zPlEbL5cKM8kJt0dLYCcBjHFxB2WJR3BohKJ8krdd57 47daWlvHslzrFR0T+MIFk4OvATrNDT4LOGesX4hoinBjESv4afZpN1RJ3NnzhaGCYXq6Fsob 5AbSy3NReTS429hpzIPmiYgZSJ8/bccQlhi45fH4ZmGL/Q5qXtMdP4JtbwgT41fPpgOAvoWA qi1Eg+ORayq8gKa1tW/BvXLxoQQD+inopWHe3qeAHD7uIGPXiXLQ3GgkhC9zugAAAAAAAA== --------------ms080508000602080609040702--