From owner-ietf-calendar@mail.imc.org Wed Jun 2 21:05: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 VAA08152 for ; Wed, 2 Jun 2004 21:05:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i530kErN028945; Wed, 2 Jun 2004 17:46:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i530kERH028944; Wed, 2 Jun 2004 17:46:14 -0700 (PDT) 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.11/8.12.9) with ESMTP id i530kDOs028919 for ; Wed, 2 Jun 2004 17:46:14 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40B7B082.4030604@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-12-e: TRANSP and -NOCONFLICT changes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Jun 2004 18:21:59 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/02/2004 08:42:50 PM, Serialize complete at 06/02/2004 08:42:50 PM Content-Type: multipart/alternative; boundary="=_alternative 007ABB9585256EA7_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007ABB9585256EA7_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 05/28/2004 05:34:58 PM: > It is true that CAP adds to the OPAQUE object types in 2445. It however > cap does not introduce OPAQUE > objects as a new concept and even if CAP did not add new OPAQUE object > types, the problem still exists > in existing 2445/2446 objects. > > Again, not a CAP issue. Im sorry but I have to disagree. CAP is changing TRANSP from simply indicating if an entry "is transparent or not to busy time searches" to also convey conflict controls. That makes this a CAP issue. Unless CAP defines the changes clearly and unambiguously, it will be a problem later on. Also lets be perfectly clear on something. RFC 2445 defined TRANSP simply as how an entry appears in busytime. It has NO concept of conflict control for calendars or for booking one entry on top of another; that was CAPs addition. So the claim that if there were an issue, its belongs to RFC 2445 is simply incorrect. The new role for TRANSP was introduced by CAP and thus CAP needs to deal the ambiguities it introduced. Perhaps if you could explain in greater detail how you see "a button performing this new user friendly feature" and how CAP specifys a consistant behaviour for my 2 scenarios (or even my simple 1 day scenario) I could better understand why you think there is no issue. So far I have not see any technical info or analysis as to where in CAP this is clearly described. If it is there and I'm simply missing it, please point me to it. If its not there, we need to add a bit more to CAP I think. 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 007ABB9585256EA7_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 05/28/2004 05:34:58 PM:
> It is true that CAP adds to the OPAQUE object types in 2445. It however
> cap does not introduce OPAQUE
> objects as a new concept and even if CAP did not add new OPAQUE object
> types, the problem still exists
> in existing 2445/2446 objects.
>
> Again, not a CAP issue.

Im sorry but I have to disagree.  CAP is changing TRANSP from simply indicating if an entry "is transparent or not to busy time searches" to also convey conflict controls.  That makes this a CAP issue.  Unless CAP defines the changes clearly and unambiguously, it will be a problem later on.  

Also lets be perfectly clear on something.  RFC 2445 defined TRANSP simply as how an entry appears in busytime.  It has NO concept of conflict control for calendars or for booking one entry on top of another; that was CAPs addition.  So the claim that if there were an issue, its belongs to RFC 2445 is simply incorrect.  The new role for TRANSP was introduced by CAP and thus CAP needs to deal the ambiguities it introduced.

Perhaps if you could explain in greater detail how you see "a button performing this new user friendly feature" and how CAP specifys a consistant behaviour for my 2 scenarios (or even my simple 1 day scenario) I could better understand why you think there is no issue.  So far I have not see any technical info or analysis as to where in CAP this is clearly described.  If it is there and I'm simply missing it, please point me to it.  If its not there, we need to add a bit more to CAP I think.

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 007ABB9585256EA7_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 3 00:01:00 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 AAA18042 for ; Thu, 3 Jun 2004 00:01:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i533hvBi047429; Wed, 2 Jun 2004 20:43:57 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i533hvnO047428; Wed, 2 Jun 2004 20:43:57 -0700 (PDT) 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.11/8.12.9) with ESMTP id i533hu6D047398 for ; Wed, 2 Jun 2004 20:43:56 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Jun 2004 23:07:19 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/02/2004 11:40:34 PM, Serialize complete at 06/02/2004 11:40:34 PM Content-Type: multipart/alternative; boundary="=_alternative 0010C8D385256EA8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0010C8D385256EA8_= Content-Type: text/plain; charset="US-ASCII" While trying to do a resync to CAP-13 I was reading the example descriptions (because as Frank loved to point out people will live by them as gospel) and I think I found an example in Section 6.1.1 CAL-QUERY Value Type that is wrong or Im just misreading it. The example given is: (d) SELECT * FROM VEVENT and the description that follows is: (d) Selects every property and every component that is in any "VEVENT" component, with each "VEVENT" component wrapped in a BEGIN/END VALARM tags. I strongly suspect that the bit about wrapping in BEGIN:VALARM/END:VALARM is residual from a previous example that was to contrast the (c) case above it. I think that everything after the ',' on the second line really should just be removed. Or am I misunderstanding something? The other example that I found seemingly incorrectly described is: (e) SELECT * FROM VEVENT WHERE VALARM.TRIGGER < '20020201T000000Z' AND VALARM.TRIGGER > '20020101T000000Z' which is later described as: (e) Selects all properties and all contained components in all "VEVENT" components that have a "VALARM" component with a "TRIGGER" property value between the provided dates and times, with each "VEVENT" component wrapped in a BEGIN/END VALARM tags. Again, Im not sure that the bits at the end about wrapping the VEVENT in a BEGIN:VALARM/END:VALARM are correct. Again, I think that everything after the ',' on the last line should be removed. Would that be a correct thing to do?? Bruce PS: Why is the spacing skewed? Isn't it supposed to be all left edge aligned when indented like that?? =========================================================================== 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 0010C8D385256EA8_= Content-Type: text/html; charset="US-ASCII"
While trying to do a resync to CAP-13 I was reading the example descriptions (because as Frank loved to point out people will live by them as gospel) and I think I found an example in Section 6.1.1 CAL-QUERY Value Type that is wrong or Im just misreading it.  The example given is:

       (d) SELECT * FROM VEVENT

and the description that follows is:

       (d) Selects every property and every component
           that is in any "VEVENT" component, with each "VEVENT"
           component wrapped in a BEGIN/END VALARM tags.

I strongly suspect that the bit about wrapping in BEGIN:VALARM/END:VALARM is residual from a previous example that was to contrast the (c) case above it.  I think that everything after the ',' on the second line really should just be removed.  Or am I misunderstanding something?

The other example that I found seemingly incorrectly described is:

       (e) SELECT * FROM VEVENT WHERE
            VALARM.TRIGGER < '20020201T000000Z'
            AND VALARM.TRIGGER > '20020101T000000Z'

which is later described as:

       (e) Selects all properties and all contained
           components in all "VEVENT" components that have a "VALARM"
           component with a "TRIGGER" property value between
           the provided dates and times, with each "VEVENT"
           component wrapped in a BEGIN/END VALARM tags.

Again, Im not sure that the bits at the end about wrapping the VEVENT in a BEGIN:VALARM/END:VALARM are correct.   Again, I think that everything after the ',' on the last line should be removed.  Would that be a correct thing to do??

Bruce
PS: Why is the spacing skewed?  Isn't it supposed to be all left edge aligned when indented like that??
===========================================================================
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 0010C8D385256EA8_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 3 01:09: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 BAA23242 for ; Thu, 3 Jun 2004 01:09:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i534rSdh061021; Wed, 2 Jun 2004 21:53:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i534rSax061020; Wed, 2 Jun 2004 21:53:28 -0700 (PDT) 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.11/8.12.9) with ESMTP id i534rRSs060994 for ; Wed, 2 Jun 2004 21:53:27 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i534rNus021054 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Jun 2004 21:53:26 -0700 Message-ID: <40BEAEC2.8040906@Royer.com> Date: Wed, 02 Jun 2004 22:53:22 -0600 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-e: TRANSP and -NOCONFLICT changes References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010500070209050509030208" 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. --------------ms010500070209050509030208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Still irrelevant as even without CAP you have the same problem. CU's currently want to mark time around exiting objects. And with CAP the solution is 100% solvable with exiting objects - BUSY time. And some CUA' s already allow that from the UI. You seem to be asking for a new smart NO-CONFLICT object or command. The fact that CAP allows a CS to force a no-conflict feature upon a CUA for BOOKed objects is new to CAP. The problem is not new to CU's. Currently they solved the problem simply by marking all time as busy - and you still can. You can mark the entire week as busy and not have ANY no-conflict objects in your calendar. With CAP no-conflict means you can not BOOK an object. It does not mean that a REQUEST or other METHOD's can not be in the calendar. And existing CUA's will not have a clue what to do with NOCONFLICT anyway. So the solution needs to exist for iCal objects, not just CAP. And FYI I voted for the ALLOW-CONFLICT property to be used in objects and not extend the TRANSP property. -- 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 --------------ms010500070209050509030208 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 9w0BCQUxDxcNMDQwNjAzMDQ1MzIyWjAjBgkqhkiG9w0BCQQxFgQU5Dn3j16UvvlQvwtsBp6p Kthg9wgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAj5wszBYqFhy4RBQuplZBmmJFmrAX+qno75rLwvcMFv1A06J4ewri2Qcv6Olte04F PjqLXNVVG3dZEuSK4r+OYsS9wYEkM2GWWjDrcHj+lp9OMh+ginlIYzRjpW4+YQNoRm2sdFCs RInK9HnXz3v6rwSOIpkUKc++0jKrj8w1X19fo0Y3oEV8Xa1NdCUxtN8GrJaIf7yXI3iPD7ZN 7hS0n/cmeHtNBHPUOjRqdXIZrydcggiUMFIeVGSMqB1G5WKlFrbyMGlwlMtp5VXhybXWDlo6 2fBakd727mmCMztoke20lLruIj3UE4pKqcqcFX0KpGrEEozRpUyM2DBP8KS47wAAAAAAAA== --------------ms010500070209050509030208-- From owner-ietf-calendar@mail.imc.org Thu Jun 3 01:14:37 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 BAA23535 for ; Thu, 3 Jun 2004 01:14:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5350Vlh062973; Wed, 2 Jun 2004 22:00:31 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5350VPI062971; Wed, 2 Jun 2004 22:00:31 -0700 (PDT) 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.11/8.12.9) with ESMTP id i5350UQF062923 for ; Wed, 2 Jun 2004 22:00:30 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i5350Tus021167 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Jun 2004 22:00:31 -0700 Message-ID: <40BEB06C.3040001@Royer.com> Date: Wed, 02 Jun 2004 23:00:28 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030605030801060607090503" 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. --------------ms030605030801060607090503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > (d) Selects every property and every component > that is in any "VEVENT" component, with each "VEVENT" > component wrapped in a BEGIN/END VALARM tags. Fixed to say VEVENT tags. > > which is later described as: > > (e) Selects all properties and all contained > components in all "VEVENT" components that have a "VALARM" > component with a "TRIGGER" property value between > the provided dates and times, with each "VEVENT" > component wrapped in a BEGIN/END VALARM tags. Fixed to say VEVENT tags. I left that in because in the past that was a question. Should the properties be in the VREPLY, or inside of a VEVENT? Inside the VREPLY would make it difficult to parse separate vevent objects. > > Bruce > PS: Why is the spacing skewed? Isn't it supposed to be all left edge > aligned when indented like that?? Bug in XML->RFC. Those kinds of fixes will have to be hand edited in the final approved push to the IETF. -- 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 --------------ms030605030801060607090503 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 9w0BCQUxDxcNMDQwNjAzMDUwMDI4WjAjBgkqhkiG9w0BCQQxFgQUPw5xznQmbbSpBNwT8m75 Pn8MbCowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA2/U8xgAJjkzLcq8hRlOgHNdGe+JHxLvOfDoDLd9i5KVqgoYEe8BgYd3VrqDUG+wd o8UHRSrl4mjSCS7Xr2YYm5tFy9frh29mdeG8dfJq7cTOidmKH79NKldmxuUYIEygHVWBEjYu PU+YJ4vHKTxOQyR7uXbjAb5HTGOvGZ53lrMx781Prg20iWIbiDZXjkyB6uXgxmhLHVcqW4a9 iuDx0enEA77bDhFWnCkCJ/KgWYjD241IKC1EA1T6tKpVXHIxOcerEggyR12FHwj198JkPw+K y11+dNq/ioEZR+a0+I9wn0FO/3DX92cHe1Ll8uzuaHwNmUYynrg7Fd/TdxhEZQAAAAAAAA== --------------ms030605030801060607090503-- From owner-ietf-calendar@mail.imc.org Thu Jun 3 10:15: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 KAA14374 for ; Thu, 3 Jun 2004 10:15:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53DeDFC054888; Thu, 3 Jun 2004 06:40:13 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53DeDmW054887; Thu, 3 Jun 2004 06:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53DeBkq054880 for ; Thu, 3 Jun 2004 06:40:12 -0700 (PDT) (envelope-from mike@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [82.133.12.165]) by smtp.nildram.co.uk (Postfix) with ESMTP id 0F851250FA8 for ; Thu, 3 Jun 2004 14:40:08 +0100 (BST) Received: from 192.168.66.51 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Thu, 3 Jun 2004 14:31:07 +0100 To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? References: Message-ID: Date: Thu, 03 Jun 2004 14:31:03 +0100 From: "Mike Higginbottom" Organization: PSCS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/7.50 (Win32, build 3778) X-Server: VPOP3 Enterprise V2.1.0RC7 - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Wed, 2 Jun 2004 23:07:19 -0400, wrote: > > (d) Selects every property and every component > that is in any "VEVENT" component, with each "VEVENT" > component wrapped in a BEGIN/END VALARM tags. > > I strongly suspect that the bit about wrapping in BEGIN:VALARM/END:VALARM > is residual from a previous example that was to contrast the (c) case > above it. I think that everything after the ',' on the second line > really > should just be removed. Or am I misunderstanding something? > > (e) Selects all properties and all contained > components in all "VEVENT" components that have a "VALARM" > component with a "TRIGGER" property value between > the provided dates and times, with each "VEVENT" > component wrapped in a BEGIN/END VALARM tags. > > Again, Im not sure that the bits at the end about wrapping the VEVENT in > a > BEGIN:VALARM/END:VALARM are correct. Again, I think that everything I've been looking at exactly the same section this morning. Are you following me Bruce? I think replacing 'in a BEGIN/END VALARM tags' with 'in BEGIN/END VEVENT tags' would fix this in both cases d) and e). Unless I'm misunderstanding something as well ;) -- Regards Mike Higginbottom Paul Smith Computer Services 01484 855800 support@pscs.co.uk www.pscs.co.uk From owner-ietf-calendar@mail.imc.org Thu Jun 3 11:34: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 LAA20736 for ; Thu, 3 Jun 2004 11:34:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53FA2Dw073524; Thu, 3 Jun 2004 08:10:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53FA2X8073523; Thu, 3 Jun 2004 08:10:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53FA15X073513 for ; Thu, 3 Jun 2004 08:10:02 -0700 (PDT) (envelope-from mike@pscs.co.uk) Received: from mail.pscs.co.uk (unknown [82.133.12.165]) by smtp.nildram.co.uk (Postfix) with ESMTP id 627112541B0 for ; Thu, 3 Jun 2004 16:10:01 +0100 (BST) Received: from 192.168.66.51 by mail.pscs.co.uk ([192.168.57.70] running VPOP3) with ESMTP for ; Thu, 3 Jun 2004 16:08:58 +0100 Date: Thu, 03 Jun 2004 16:08:57 +0100 To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? References: From: "Mike Higginbottom" Organization: PSCS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/7.50 (Win32, build 3778) X-Server: VPOP3 Enterprise V2.1.0RC7 - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Wed, 2 Jun 2004 23:07:19 -0400, wrote: > > (d) Selects every property and every component > that is in any "VEVENT" component, with each "VEVENT" > component wrapped in a BEGIN/END VALARM tags. > > I strongly suspect that the bit about wrapping in BEGIN:VALARM/END:VALARM > is residual from a previous example that was to contrast the (c) case > above it. I think that everything after the ',' on the second line > really > should just be removed. Or am I misunderstanding something? Changed my mind. I think it should be: (d) Selects every property and every component that is in any "VEVENT" component, with each contained component wrapped in BEGIN/END tags. This whole section seems confusing to me though. What query do I need to get a list of all the BEGIN/END tagged VEVENTS in a VAGENDA? SELECT VEVENT FROM VAGENDA would seem right. What about without the BEGIN/END tags? SELECT VEVENT.* FROM VAGENDA sounds good. But what's the difference between that and SELECT * FROM VEVENT? -- Regards Mike Higginbottom Paul Smith Computer Services 01484 855800 support@pscs.co.uk www.pscs.co.uk From owner-ietf-calendar@mail.imc.org Thu Jun 3 15:11:54 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 PAA04710 for ; Thu, 3 Jun 2004 15:11:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53ItPPk023754; Thu, 3 Jun 2004 11:55:25 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53ItPfw023749; Thu, 3 Jun 2004 11:55:25 -0700 (PDT) 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.11/8.12.9) with ESMTP id i53ItOiK023717 for ; Thu, 3 Jun 2004 11:55:24 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 3 Jun 2004 14:51:12 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/03/2004 02:51:59 PM, Serialize complete at 06/03/2004 02:51:59 PM Content-Type: multipart/alternative; boundary="=_alternative 00676A9185256EA8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00676A9185256EA8_= Content-Type: text/plain; charset="US-ASCII" Mike wrote on 06/03/2004 11:08:57 AM: > Changed my mind. I think it should be: > > (d) Selects every property and every component > that is in any "VEVENT" component, with each contained > component wrapped in BEGIN/END tags. > > This whole section seems confusing to me though. What query do I need to > get a list of all the BEGIN/END tagged VEVENTS in a VAGENDA? SELECT > VEVENT FROM VAGENDA would seem right. Actually that query would return to you all the VEVENTS and all their data, not a list of them. > What about without the BEGIN/END > tags? SELECT VEVENT.* FROM VAGENDA sounds good. Hmm, thats the right query but it does point out something I was going to (You following me Mike??). Doing that would effectively strip off all VEVENT 'wrappers' and blur all VEVENTs into 1 big stream. Not very useful really since theres no way to separate them back out into separate VEVENTs. The same concern applys to the (c) example in that same place: (c) SELECT VALARM.* FROM VEVENT If there are multiple VALARMs on a single VEVENT then this would effectively strip away the BEGIN:VALARM/END:VALARM wrappers and mix those VALARM properties into the VEVENT properties. There would be no way for a CUA to properly distinguish those VALARM properties from the VEVENT properties (had others been part of the SELECT clause) or to distingush the different VALARMs from each other. Not a very useful thing to do in my mind. > But what's the > difference between that and SELECT * FROM VEVENT? This query will NOT strip away the BEGING:VEVENT/END:VEVENT wrappers for each VEVENT. The other query would. Thats the difference. The former is not desirable (at least not that I can picture). The latter example is desirable because it allows distinct parsing of each VEVENT properly. So I guess the question of usefulness arrises from this. Whats the use of (c) if it has the undesirable effect of bleeding multiple VALARMs into 1 big mush of properties? (The same can be asked of Mikes SELECT VEVENT.* FROM VAGENDA example...) 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 00676A9185256EA8_= Content-Type: text/html; charset="US-ASCII"
Mike wrote on 06/03/2004 11:08:57 AM:
> Changed my mind.  I think it should be:
>
>          (d) Selects every property and every component
>           that is in any "VEVENT" component, with each contained
>              component wrapped in BEGIN/END tags.
>
> This whole section seems confusing to me though.  What query do I need to  
> get a list of all the BEGIN/END tagged VEVENTS in a VAGENDA?  SELECT  
> VEVENT FROM VAGENDA would seem right.

Actually that query would return to you all the VEVENTS and all their data, not a list of them.

>                                       What about without the BEGIN/END  
> tags?  SELECT VEVENT.* FROM VAGENDA sounds good.  

Hmm, thats the right query but it does point out something I was going to (You following me Mike??).  Doing that would effectively strip off all VEVENT 'wrappers' and blur all VEVENTs into 1 big stream.  Not very useful really since theres no way to separate them back out into separate VEVENTs.  The same concern applys to the (c) example in that same place:

       (c) SELECT VALARM.* FROM VEVENT

If there are multiple VALARMs on a single VEVENT then this would effectively strip away the BEGIN:VALARM/END:VALARM wrappers and mix those VALARM properties into the VEVENT properties.  There would be no way for a CUA to properly distinguish those VALARM properties from the VEVENT properties (had others been part of the SELECT clause) or to distingush the different VALARMs from each other.  Not a very useful thing to do in my mind.  

>                                                   But what's the  
> difference between that and SELECT * FROM VEVENT?
This query will NOT strip away the BEGING:VEVENT/END:VEVENT wrappers for each VEVENT.  The other query would.  Thats the difference.  The former is not desirable (at least not that I can picture).  The latter example is desirable because it allows distinct parsing of each VEVENT properly.

So I guess the question of usefulness arrises from this.  Whats the use of (c) if it has the undesirable effect of bleeding multiple VALARMs into 1 big mush of properties?  (The same can be asked of Mikes SELECT VEVENT.* FROM VAGENDA example...)

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 00676A9185256EA8_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 3 16:57:01 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 QAA15854 for ; Thu, 3 Jun 2004 16:57:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53Kcw31045069; Thu, 3 Jun 2004 13:38:58 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53KcwFN045068; Thu, 3 Jun 2004 13:38:58 -0700 (PDT) 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.11/8.12.9) with ESMTP id i53Kcvaj045036 for ; Thu, 3 Jun 2004 13:38:57 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@inet-products.com [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i53Kcqus005929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 3 Jun 2004 13:38:54 -0700 Message-ID: <40BF8C5B.3070805@Royer.com> Date: Thu, 03 Jun 2004 14:38:51 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030108000107010202030000" 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. --------------ms030108000107010202030000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > > So I guess the question of usefulness arrises from this. Whats the > use of (c) if it has the undesirable effect of bleeding multiple > VALARMs into 1 big mush of properties? (The same can be asked of > Mikes SELECT VEVENT.* FROM VAGENDA example...) The example shows you what you get if you do that, for what ever reason you might want it. I would agree that in most cases that is not what you want. It answers the quetion, what property names are in any VEVENTs in my calendar. If that is usful :-) -- 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 --------------ms030108000107010202030000 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 9w0BCQUxDxcNMDQwNjAzMjAzODUxWjAjBgkqhkiG9w0BCQQxFgQUhS9Kz35kpHKHkLlVXNqu Upk4DY4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAX0kHwGypMuYYE8WA8bLfnPAGZXgkfDNKhv+ZLqp9+SeHBBpHB4TLNiyZeh4WucuL fxyYzQ8h7XP6QbWFU+gv3Tbs4Bg8uROxQ+RjBvWW5CtwbU9u/cquqUzBFDJhwHsYbiA2QUTI t0ttd3jzc7HC0jiEorPgBvFBL7TeuS5vGeUwrk6Y4UVG7cIdIxHpUmd10kvagKoByI400HPC gMnOknxmZj84SH8Aw8dyRCaYQAAXEeQ24/b+TMnyGfzauwEg0DyeNbO8U8nkdxyVCRQmcmEM nrb0vfSbGUGzBuY3dNrnarlIfo01svZk/CPAgziF7ZwWNXS6Jh32JHZWuhOivAAAAAAAAA== --------------ms030108000107010202030000-- From owner-ietf-calendar@mail.imc.org Thu Jun 3 17:49:07 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 RAA22658 for ; Thu, 3 Jun 2004 17:49:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53LV1rW055751; Thu, 3 Jun 2004 14:31:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53LV1d2055750; Thu, 3 Jun 2004 14:31:01 -0700 (PDT) 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.11/8.12.9) with ESMTP id i53LV1ai055710 for ; Thu, 3 Jun 2004 14:31:01 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40BF8C5B.3070805@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Thu, 3 Jun 2004 17:30:47 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/03/2004 05:27:36 PM, Serialize complete at 06/03/2004 05:27:36 PM Content-Type: multipart/alternative; boundary="=_alternative 0076065885256EA8_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076065885256EA8_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 06/03/2004 04:38:51 PM: > > So I guess the question of usefulness arrises from this. Whats the > > use of (c) if it has the undesirable effect of bleeding multiple > > VALARMs into 1 big mush of properties? (The same can be asked of > > Mikes SELECT VEVENT.* FROM VAGENDA example...) > > The example shows you what you get if you do that, for what ever reason > you might want it. > I would agree that in most cases that is not what you want. Out of curiosity, can anyone describe a case when you would want this (VEVENT.* or VALARM.*) as opposed to no ".*"? If so, is it one we would see often? If not, why did we have this feature? > It answers the quetion, what property names are in any VEVENTs in my > calendar. > If that is usful :-) If thats the sole benefit / usage then I sure wish that there would be a much simpler and faster way than having my poor CUA sort thru all the data in my calendar using a brute force linear scan while cloging up my LAN and keeping the CS busy streaming all that mush. %^| Given that there is an example describing this already: SELECT VALARM.* FROM VEVENT WHERE UID = "123" Will return all of the properties in each "VALARM" component in the matching "VEVENT" component: TRIGGER;RELATED=END:PT5M REPEAT:4 ... TRIGGER;RELATED=START:PT5M DURATION:PT10M ... ... Id like to suggest we update the paragraph above to indicate that using VALARM.* (or any WIDGET.*) with multiple VALARMs (WIDGETs) is not particularly useful or that the results could not be accurately interpreted because the bounding wrappers are missing. Something like: Will return all of the properties in each "VALARM" component in the matching "VEVENT" component. If there are multiple "VALARM" components then the results will be an mix of all "VALARM" properties in one incoherent stream of data such as: Finesse it as you will but the point is to indicate that amalgumated results are not really useful as there is no way to safely rebundle them up in any meaningful way. Perhaps that kind of text would belong to the #7 bullet item text just above the example instead... 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 0076065885256EA8_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 06/03/2004 04:38:51 PM:
> > So I guess the question of usefulness arrises from this.  Whats the
> > use of (c) if it has the undesirable effect of bleeding multiple
> > VALARMs into 1 big mush of properties?  (The same can be asked of
> > Mikes SELECT VEVENT.* FROM VAGENDA example...)
>
> The example shows you what you get if you do that, for what ever reason
> you might want it.
> I would agree that in most cases that is not what you want.
Out of curiosity, can anyone describe a case when you would want this (VEVENT.* or VALARM.*) as opposed to no ".*"?  If so, is it one we would see often?  If not, why did we have this feature?

> It answers the quetion, what property names are in any VEVENTs in my
> calendar.
> If that is usful :-)
If thats the sole benefit / usage then I sure wish that there would be a much simpler and faster way than having my poor CUA sort thru all the data in my calendar using a brute force linear scan while cloging up my LAN and keeping the CS busy streaming all that mush.  %^|

Given that there is an example describing this already:

   SELECT VALARM.* FROM VEVENT WHERE UID = "123"

   Will return all of the properties in each "VALARM" component
   in the matching "VEVENT" component:

   TRIGGER;RELATED=END:PT5M
   REPEAT:4
   ...
   TRIGGER;RELATED=START:PT5M
   DURATION:PT10M
   ...
   ...

Id like to suggest we update the paragraph above to indicate that using VALARM.* (or any WIDGET.*) with multiple VALARMs (WIDGETs) is not particularly useful or that the results could not be accurately interpreted because the bounding wrappers are missing.  Something like:

   Will return all of the properties in each "VALARM" component
   in the matching "VEVENT" component.  If there are multiple
   "VALARM" components then the results will be an mix of all
   "VALARM" properties in one incoherent stream of data such as:

Finesse it as you will but the point is to indicate that amalgumated results are not really useful as there is no way to safely rebundle them up in any meaningful way.  Perhaps that kind of text would belong to the  #7 bullet item text just above the example instead...

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 0076065885256EA8_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 3 18:50:07 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 SAA01551 for ; Thu, 3 Jun 2004 18:50:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i53MQSo8067301; Thu, 3 Jun 2004 15:26:28 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i53MQSHD067300; Thu, 3 Jun 2004 15:26:28 -0700 (PDT) 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.11/8.12.9) with ESMTP id i53MQQG6067272 for ; Thu, 3 Jun 2004 15:26:26 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@inet-products.com [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i53MQKus008275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 3 Jun 2004 15:26:22 -0700 Message-ID: <40BFA58C.1040708@Royer.com> Date: Thu, 03 Jun 2004 16:26:20 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000508050001000601000708" 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. --------------ms000508050001000601000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 06/03/2004 04:38:51 PM: > > > So I guess the question of usefulness arrises from this. Whats the > > > use of (c) if it has the undesirable effect of bleeding multiple > > > VALARMs into 1 big mush of properties? (The same can be asked of > > > Mikes SELECT VEVENT.* FROM VAGENDA example...) > > > > The example shows you what you get if you do that, for what ever reason > > you might want it. > > I would agree that in most cases that is not what you want. > > Out of curiosity, can anyone describe a case when you would want this > (VEVENT.* or VALARM.*) as opposed to no ".*"? Please read the rest of my reply - where I did. -- 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 --------------ms000508050001000601000708 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 9w0BCQUxDxcNMDQwNjAzMjIyNjIwWjAjBgkqhkiG9w0BCQQxFgQU9Sc7TuHeXQbm73EMthAQ najt+awwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAbs5kQqkcRt2yHR7MIoSBAcd7idus+cwzRhZS34LE5uubdXFKMAQ3P9Vd0BKWHE8m 8AtKaKcOP6d6aN/4rvYHATjTBB/8za0MJDmKGmiKfwR+6m3vR2YYTr6THvEqHZa18SWFI+1e mlt1GynvE/GYVDiXTThdAPFHuhcQrOnM9FvCTMFVTAIfxsIwZl9PcIoR+nocOT4Gmh+NDK7X cUZAXnmv2p7A/wx9oovTuLaMdb8X54o7KI6zHWoM0B6rlyUOdTV4wO9T27PrLy0fcpixYy1d DqpKuK4B89d/7TyF64kp995ZmrUb4hF0/sUDhWym14DV4a0PLlmDyJdsSfJMBAAAAAAAAA== --------------ms000508050001000601000708-- From owner-ietf-calendar@mail.imc.org Thu Jun 3 23:09:55 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 XAA23041 for ; Thu, 3 Jun 2004 23:09:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i542oYR6024979; Thu, 3 Jun 2004 19:50:34 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i542oYDC024978; Thu, 3 Jun 2004 19:50:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i542oWm9024946 for ; Thu, 3 Jun 2004 19:50:33 -0700 (PDT) (envelope-from TimHare@comcast.net) Received: from thare.comcast.net (pcp05187528pcs.micske01.fl.comcast.net[68.46.236.19]) by comcast.net (sccrmhc12) with SMTP id <20040604025034012001ip5ke> (Authid: TimHare); Fri, 4 Jun 2004 02:50:34 +0000 Message-Id: <6.0.3.0.0.20040603224108.0281c1e0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 03 Jun 2004 22:49:10 -0400 To: ietf-calendar@imc.org From: TimHare@comcast.net Subject: Re: CAP 13: Bad CAL-QUERY example / description? In-Reply-To: <40BFA58C.1040708@Royer.com> References: <40BFA58C.1040708@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems to me that some of the queries we are discussing allow us to get only properties with no component context, or expect the CUA to maintain the context as it awaits the result of the query, i.e., Store the event that I'm finding the VALARMs for, then query for the VALARMs and relate the results to the stored event. Isn't this opening up huge possibilities for errors and mixed-up data (as someone pointed out merging all of the VALARMS or VEVENT properties into one big thing has little purpose)? With the complexity of CAP the last thing I'd want to do would be introduce ambiguity like that. It seems to me that a component should be the "atomic" element retrieved for queries, and the CUA should do its own parsing/query of properties to find out more of the details, but that's just my opinion. I would like to go back and read some of the QUERY development process in the archives - does anyone have a guess about what timeframes this was taking place? Thanks Tim Hare Interested Bystander, Non-Inc. At 06:26 PM 6/3/04, you wrote: >Bruce_Kahn@notesdev.ibm.com wrote: > >> >>Doug replied on 06/03/2004 04:38:51 PM: >> > > So I guess the question of usefulness arrises from this. Whats the >> > > use of (c) if it has the undesirable effect of bleeding multiple >> > > VALARMs into 1 big mush of properties? (The same can be asked of >> > > Mikes SELECT VEVENT.* FROM VAGENDA example...) >> > >> > The example shows you what you get if you do that, for what ever reason >> > you might want it. >> > I would agree that in most cases that is not what you want. >> >>Out of curiosity, can anyone describe a case when you would want this >>(VEVENT.* or VALARM.*) as opposed to no ".*"? > >Please read the rest of my reply - where I did. > >-- > >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 > > > > Tim Hare Interested Bystander, Non-Inc. From owner-ietf-calendar@mail.imc.org Fri Jun 4 01:38:02 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 BAA28817 for ; Fri, 4 Jun 2004 01:38:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i545OUfk061852; Thu, 3 Jun 2004 22:24:30 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i545OU1H061851; Thu, 3 Jun 2004 22:24:30 -0700 (PDT) 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.11/8.12.9) with ESMTP id i545OTQs061800 for ; Thu, 3 Jun 2004 22:24:29 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i545ORus015297 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 3 Jun 2004 22:24:30 -0700 Message-ID: <40C0078B.3030700@Royer.com> Date: Thu, 03 Jun 2004 23:24:27 -0600 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 13: Bad CAL-QUERY example / description? References: <40BFA58C.1040708@Royer.com> <6.0.3.0.0.20040603224108.0281c1e0@mail.comcast.net> In-Reply-To: <6.0.3.0.0.20040603224108.0281c1e0@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060102000401010602010305" 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. --------------ms060102000401010602010305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit TimHare@comcast.net wrote: > ...does anyone have a guess about what timeframes this was taking place? Queries evolved over the last several years. There is not one single time frame. -- 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 --------------ms060102000401010602010305 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 9w0BCQUxDxcNMDQwNjA0MDUyNDI3WjAjBgkqhkiG9w0BCQQxFgQU/ESs589oONsQQJDBJ1qH pbyy6W0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAPZcq5guRZU5t15ut4pI788QSxYgNoqGZIPr5Z8DslQPqf1+aCJc8NZVY8xlqAF0M HPEZ7+Jr6nY3E6oq9syQnTEktGEERS5gwKr19YQAd0AcHkMfedJ75bKM45uFpAZqEXoI09hU oeaH0HrKV9DKDL7lQfXH/td38kUrO4dSdr1nizUlKkkNhZUojlwR6U+uOGlDLiNJoDaytpxr 2NsXsuMwxWxONv740+ovL/YRtlCFE4TgKMmw6KEmRDD1PDSwntXvOmWs9QzJ5MXbSd8ZEOcR b2zzrFKv46kkoZRBval6YoChoipDQha8VMy6pD0/6P+ne3fUamIL+amg88oD3wAAAAAAAA== --------------ms060102000401010602010305-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 10:50: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 KAA15076 for ; Fri, 4 Jun 2004 10:50:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54EaXt0026129; Fri, 4 Jun 2004 07:36:33 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54EaX9x026128; Fri, 4 Jun 2004 07:36:33 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54EaXBO026087 for ; Fri, 4 Jun 2004 07:36:33 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-13: Another CAL-QUERY / VAGENDA question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 4 Jun 2004 10:36:21 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/04/2004 10:33:06 AM, Serialize complete at 06/04/2004 10:33:06 AM Content-Type: multipart/alternative; boundary="=_alternative 0050109B85256EA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0050109B85256EA9_= Content-Type: text/plain; charset="US-ASCII" In looking at CAP-13 while digesting Dougs recent response to another question I ran across an another apparent ambiguity in CAP-13. In Section 6.1.1 CAL-QUERY Value Type there is the example: (d) SELECT * FROM VEVENT which is described as: (d) Selects every property and every component that is in any "VEVENT" component, with each "VEVENT" component wrapped in a BEGIN/END VALARM tags. This indicates that the use of "*" in query will return every property and component in the FROM component (VEVENT in this case). However in Section 9.1 VAGENDA Component I find: To fetch all of the properties from the targeted "VAGENDA" component. This does not fetch any components: SELECT * FROM VAGENDA To fetch all of the properties from the targeted VAGENDA and all of the contained components, use the special '*.*' value: SELECT *.* FROM VAGENDA which is seemingly contraditory to that of the stuff in Section 6.1.1. Why isn't the first example interpreted the same way as (d) was: Every property and every component in the VAGENDA? The same can be asked of VCALSCALE as well. There are 2 references to " the special '*.*' value" but I can find only _those_ actual uses of "*.*" in the draft. There is nothing anywhere in CAP-13 that describes a special "*.*" sequence. No text or any ABNF that I can find. Can anyone point me to the parts I missing that describe "*.*"? I also question the need/use of "*.*" for VAGENDA and VCALSCALE. Why aren't the same rules from Section 6.1.1 sufficient for VAGENDA and VCALSCALE but they are sufficient for all other components that have the same nesting structure? 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 0050109B85256EA9_= Content-Type: text/html; charset="US-ASCII"
In looking at CAP-13 while digesting Dougs recent response to another question I ran across an another apparent ambiguity in CAP-13.  In Section 6.1.1 CAL-QUERY Value Type there is the example:

       (d) SELECT * FROM VEVENT

which is described as:

       (d) Selects every property and every component
           that is in any "VEVENT" component, with each "VEVENT"
           component wrapped in a BEGIN/END VALARM tags.

This indicates that the use of "*" in query will return every property and component in the FROM component (VEVENT in this case).  However in Section 9.1 VAGENDA Component I find:

   To fetch all of the properties from the targeted "VAGENDA" component.
   This does not fetch any components:

   SELECT * FROM VAGENDA

   To fetch all of the properties from the targeted VAGENDA and all of
   the contained components, use the special '*.*' value:

   SELECT *.* FROM VAGENDA

which is seemingly contraditory to that of the stuff in Section 6.1.1.   Why isn't the first example interpreted the same way as (d) was: Every property and every component in the VAGENDA?  

The same can be asked of VCALSCALE as well.  There are 2 references to "the special '*.*' value" but I can find only _those_ actual uses of "*.*" in the draft.  There is nothing anywhere in CAP-13 that describes a special "*.*" sequence.  No text or any ABNF that I can find.  

Can anyone point me to the parts I missing that describe "*.*"?  I also question the need/use of "*.*" for VAGENDA and VCALSCALE.  Why aren't the same rules from Section 6.1.1 sufficient for VAGENDA and VCALSCALE but they are sufficient for all other components that have the same nesting structure?

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 0050109B85256EA9_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 10:59: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 KAA15434 for ; Fri, 4 Jun 2004 10:59:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54Eivdw027063; Fri, 4 Jun 2004 07:44:57 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54Eivbu027062; Fri, 4 Jun 2004 07:44:57 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54EivU3027049 for ; Fri, 4 Jun 2004 07:44:57 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40BFA58C.1040708@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 4 Jun 2004 10:44:18 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/04/2004 10:41:30 AM, Serialize complete at 06/04/2004 10:41:30 AM Content-Type: multipart/alternative; boundary="=_alternative 0050CAC685256EA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0050CAC685256EA9_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 06/03/2004 06:26:20 PM: > > Out of curiosity, can anyone describe a case when you would want this > > (VEVENT.* or VALARM.*) as opposed to no ".*"? > > Please read the rest of my reply - where I did. I did read your entire post and I took it to be more a tongue in cheek example rather than a pratical usage example. Sorry if my follow up wasnt that clear. From the previous reply: > It answers the quetion, what property names are in any VEVENTs in my > calendar. > If that is usful :-) It _could_ be useful if I needed to know "Is there a X-Hinkey-Minkey on any VEVENT in my calendar?" but I dont think thats a common need really or even necessary actually given most queries would just use "*" or can list any desired properties on the SELECT and then see what comes back. Put another way: Why should I care if it exists on any entry anywhere in the calendar when I can easily tell by simply looking for it on any VEVENT when I retrieve it normally? Knowing it exists on a component _somewhere_ in the calendar is not that useful as it does not tell me on which one(s) and if I needed to just see those kinds of entries I simply use that as part of my WHERE clause to begin with... (SELECT * FROM VEVENT WHERE X-HINKEY-MINKEY IS NOT NULL) Given most queries would typically be of the form: SELECT * FROM VEVENT WHERE UID = "123" to get a specific VEVENT or like: SELECT VEVENT FROM VAGENDA WHERE STATE() = 'UNPROCESSED' to get unprocessed requests, is there any _practical_ use for VALARM.* or VEVENT.* that Im just not groking?? BTW: The "This does not fetch any components" part above is inaccurate. It actually fetches them ALL but combines them into one long massive stream of data. There has been nothing said about 'unwrappering' sub-components like VALARMs so I would expect them to be still wrappered in the amalgamated stream of VEVENT (and VTODO and VJOURNAL and VTIMEZONE and VQUERY and ... ) mush. 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 0050CAC685256EA9_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 06/03/2004 06:26:20 PM:
> > Out of curiosity, can anyone describe a case when you would want this
> > (VEVENT.* or VALARM.*) as opposed to no ".*"?
>
> Please read the rest of my reply - where I did.
I did read your entire post and I took it to be more a tongue in cheek example rather than a pratical usage example.  Sorry if my follow up wasnt that clear.  From the previous reply:

> It answers the quetion, what property names are in any VEVENTs in my
> calendar.
> If that is usful :-)

It _could_ be useful if I needed to know "Is there a X-Hinkey-Minkey on any VEVENT in my calendar?" but I dont think thats a common need really or even necessary actually given most queries would just use "*" or can list any desired properties on the SELECT and then see what comes back.  

Put another way: Why should I care if it exists on any entry anywhere in the calendar when I can easily tell by simply looking for it on any VEVENT when I retrieve it normally?  Knowing it exists on a component _somewhere_ in the calendar is not that useful as it does not tell me on which one(s) and if I needed to just see those kinds of entries I simply use that as part of my WHERE clause to begin with...  (SELECT * FROM VEVENT WHERE X-HINKEY-MINKEY IS NOT NULL)

Given most queries would typically be of the form:

        SELECT * FROM VEVENT WHERE UID = "123"

to get a specific VEVENT or like:

        SELECT VEVENT FROM VAGENDA WHERE STATE() = 'UNPROCESSED'

to get unprocessed requests, is there any _practical_ use for VALARM.* or VEVENT.* that Im just not groking??  

BTW: The "This does not fetch any components" part above is inaccurate.  It actually fetches them ALL but combines them into one long massive stream of data.  There has been nothing said about 'unwrappering' sub-components like VALARMs so I would expect them to be still wrappered in the amalgamated stream of VEVENT (and VTODO and VJOURNAL and VTIMEZONE and VQUERY and ... ) mush.

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 0050CAC685256EA9_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 11:06: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 LAA15850 for ; Fri, 4 Jun 2004 11:06:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54Esv7O028755; Fri, 4 Jun 2004 07:54:57 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54EsvRw028754; Fri, 4 Jun 2004 07:54:57 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54EsudR028740 for ; Fri, 4 Jun 2004 07:54:57 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <6.0.3.0.0.20040603224108.0281c1e0@mail.comcast.net> To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 4 Jun 2004 10:55:03 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/04/2004 10:51:30 AM, Serialize complete at 06/04/2004 10:51:30 AM Content-Type: multipart/alternative; boundary="=_alternative 0051B6D185256EA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0051B6D185256EA9_= Content-Type: text/plain; charset="US-ASCII" Tim replied on 06/03/2004 10:49:10 PM: > It seems to me that a component should be the "atomic" element retrieved > for queries, and the CUA should do its own parsing/query of properties to > find out more of the details, but that's just my opinion. I would like to > go back and read some of the QUERY development process in the archives - > does anyone have a guess about what timeframes this was taking place? Pat has an online Full Text indexed copy of the WG archive going back to 1996 when the WG was created. I dont have the URL she posted but it should be available here or you can poke her in case shes not following this thread. That should allow you to full text search the archives for phrases like "VEVENT.*" or whatever. 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 0051B6D185256EA9_= Content-Type: text/html; charset="US-ASCII"
Tim replied on 06/03/2004 10:49:10 PM:
> It seems to me that a component should be the "atomic" element retrieved
> for queries, and the CUA should do its own parsing/query of properties to
> find out more of the details, but that's just my opinion. I would like to
> go back and read some of the QUERY development process in the archives -
> does anyone have a guess about what timeframes this was taking place?
Pat has an online Full Text indexed copy of the WG archive going back to 1996 when the WG was created.  I dont have the URL she posted but it should be available here or you can poke her in case shes not following this thread.  That should allow you to full text search the archives for phrases like "VEVENT.*" or whatever.

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 0051B6D185256EA9_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 12:06: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 MAA19617 for ; Fri, 4 Jun 2004 12:06:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54Fp6Z1036815; Fri, 4 Jun 2004 08:51:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54Fp63C036812; Fri, 4 Jun 2004 08:51:06 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54Fp5LM036766 for ; Fri, 4 Jun 2004 08:51:05 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i54Fowus027071 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 4 Jun 2004 08:51:00 -0700 Message-ID: <40C09A61.3070306@Royer.com> Date: Fri, 04 Jun 2004 09:50:57 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080709050000070604070401" 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. --------------ms080709050000070604070401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 06/03/2004 06:26:20 PM: > > > Out of curiosity, can anyone describe a case when you would want this > > > (VEVENT.* or VALARM.*) as opposed to no ".*"? > > > > Please read the rest of my reply - where I did. > > I did read your entire post and I took it to be more a tongue in cheek > example rather than a practical usage example. Sorry if my follow up > wasn't that clear. From the previous reply: > > > It answers the quetion, what property names are in any VEVENTs in my > > calendar. > > If that is usful :-) > > It _could_ be useful if I needed to know "Is there a X-Hinkey-Minkey > on any VEVENT in my calendar?" but I dont think thats a common need > really or even necessary actually given most queries would just use > "*" or can list any desired properties on the SELECT and then see what > comes back. I think it is a very much needed feature. Have you looked at all of the custom X- properties and specific sub-sets of iTIP objects that are coming back? As I learn them I add the ability for the CUA to use them, or translate their features at run time into CAP properties or x- properties that I use, when they overlap. Just check out how people define time zones with special property names as one example. When getting a VCALEDNAR object back from a random source. The only way to figure out which set of x- properties they use, is to scan for properties and figure it out. I have generated several compliant VCALENDAR objects that crash popular CUAs. So I translate them into what the CUA can handle. Try pointing several of the CUAs that exist at a full featured CAP VCALENDAR object, I have been able to crash all of the CUAs so far that I can find with various valid objects. The real solution is more RFCs on how to do specific things, but for now they all seem to be using valid (or nearly valid) iCal objects that are mostly compatible with each other. At this point run time checking is the only way to determine what you will be getting before trying to use the data. -- 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 --------------ms080709050000070604070401 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 9w0BCQUxDxcNMDQwNjA0MTU1MDU3WjAjBgkqhkiG9w0BCQQxFgQUfGCdxRwIbd5eIHKPMkRj QxKn48cwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAHCGpYEfay4DZsGdI3xtcu/G9vtleWDasO1PnLbx/4yZOGE3pYdMIsS9I4plQHwHr rtoe9bFa/vrbkhkJDdFFkYx/bptatReJs2lZuOG++6VybMbIEsSSbPxNDRuWtgtdDW2caSsI AwnPyqlG9WjL6bc+bU3ebVTEjLw2RCF1ACdab5dzsI3qmmXcIaLkYudwkD2igLR5ukSX1sBQ 0pg7TP5UgEl2g2sF/mkCNhn5hOkMsW3jRc4nLI1xYiF6xxzAej7nESzw3mr12/AHZlBREXLL 4VRcMjEOqE6TtFBglaab9draiGQz8ozbRNJWn+EFMGw5F1jibyETy/TImOKNwwAAAAAAAA== --------------ms080709050000070604070401-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 12:22: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 MAA20570 for ; Fri, 4 Jun 2004 12:22:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54G5jtm039190; Fri, 4 Jun 2004 09:05:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54G5jVW039189; Fri, 4 Jun 2004 09:05:45 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54G5iZ7039170 for ; Fri, 4 Jun 2004 09:05:44 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i54G5bus027472 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 4 Jun 2004 09:05:39 -0700 Message-ID: <40C09DD0.3040600@Royer.com> Date: Fri, 04 Jun 2004 10:05:36 -0600 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-13: Another CAL-QUERY / VAGENDA question References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000408000007090103010001" 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. --------------ms000408000007090103010001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Can anyone point me to the parts I missing that describe "*.*"? I > also question the need/use of "*.*" for VAGENDA and VCALSCALE. Why > aren't the same rules from Section 6.1.1 sufficient for VAGENDA and > VCALSCALE but they are sufficient for all other components that have > the same nesting structure? Originally * was designed to NOT get components, later the WG decided that it was to get components except for VAGENDA and VCALSORE. Then there was no way to get the properties only for a VAGENDA and VCALSTORE, so we added '*.*' We had 1 or 2 interim meeting and phone calls (remember the ones that you organized?) that kept (among other things) evolving the query syntax. Then there were several edits over time. We need a way to get top level properties and not contained components. And we need to way to get everything. '*' vs '*.*' just strings as far as I am concerned. -- 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 --------------ms000408000007090103010001 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 9w0BCQUxDxcNMDQwNjA0MTYwNTM2WjAjBgkqhkiG9w0BCQQxFgQUGw6Jl3Z8+61pQvxNzqrK 2il0STswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAuXeE0jzdqxnWhckPIanj5qOY1D1iNiMCsadyCkThFxrjxCx++Gd7E0scIsaa/VF4 v0MYC/RG/x6xhCqoS5lzrTO1L97jsMoU3JbTfz5jom/84uWTlxAwH/smfT3HXw5r+OEPOXT6 JfO74aCdhFQxbtIxQf7AXDbMsUv3FwqcnPM8N4/NmDjpNNQeMceAkhPgbE6xRjavwczYNFNo IipaFp/7coV88aRXw0QQo67GQvdf0jN7sY4O6J+q+MGaBGQCT5+M+VOGa7MDpK9aQ/V8KwgR nbnIGHtyTKlqguvxTVlFAybxkQ+XzfCayy3a4VTAY/nV19p2G4A9hyb25p9HkQAAAAAAAA== --------------ms000408000007090103010001-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 13:18: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 NAA24226 for ; Fri, 4 Jun 2004 13:18:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54H5Ycb047336; Fri, 4 Jun 2004 10:05:35 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54H5Y2m047335; Fri, 4 Jun 2004 10:05:34 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54H5Y6h047318 for ; Fri, 4 Jun 2004 10:05:34 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) To: ietf-calendar@imc.org Subject: CAP-13: Defining the meaning of "*" MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 4 Jun 2004 13:05:17 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/04/2004 01:02:08 PM, Serialize complete at 06/04/2004 01:02:08 PM Content-Type: multipart/alternative; boundary="=_alternative 005DB35785256EA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DB35785256EA9_= Content-Type: text/plain; charset="US-ASCII" In looking up the defintiion of "*" and "*.*" I tried to find it in the CAP-13 text or the ABNF and I cant find it actually defined anywhere really. I did find 1 defintion in relation to permissions: all = "*" and this bit related to UPNs in Section 9.3 VCAR Component: "All CUs and UGs" are specified by the UPN value "*". but I found no other text or ABNF that defined the use of "*" to mean "All sub-components and all properties" the way we use it in Section 6.1.1 CAL-QUERY Value Type and throughout CAP. I know we all take it to be "all matches" or "all items" as in a regexp match but we really should explicitly define what "*" means since we use it frequently in CAP. I propose we add the following line to Section 6.1.1 somewhere near the top: All contained properties and subcomponents are specified by the cap-cols value "*". Bruce PS: Note to editor: The leading DQUOTE on that cited sentence from Section 9.3 should be removed. =========================================================================== 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 005DB35785256EA9_= Content-Type: text/html; charset="US-ASCII"
In looking up the defintiion of "*" and "*.*" I tried to find it in the CAP-13 text or the ABNF and I cant find it actually defined anywhere really.  I did find 1 defintion in relation to permissions:

   all         = "*"

and this bit related to UPNs in Section 9.3 VCAR Component:

                                   "All CUs and UGs" are
   specified by the UPN value "*".

but I found no other text or ABNF that defined the use of "*" to mean "All sub-components and all properties" the way we use it in Section 6.1.1 CAL-QUERY Value Type and throughout CAP.  I know we all take it to be "all matches" or "all items" as in a regexp match but we really should explicitly define what "*" means since we use it frequently in CAP.

I propose we add the following line to Section 6.1.1 somewhere near the top:

        All contained properties and subcomponents are specified by the cap-cols value "*".

Bruce
PS: Note to editor: The leading DQUOTE on that cited sentence from Section 9.3 should be removed.
===========================================================================
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 005DB35785256EA9_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 15:32: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 PAA05172 for ; Fri, 4 Jun 2004 15:32:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54JD1tT066946; Fri, 4 Jun 2004 12:13:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54JD17f066945; Fri, 4 Jun 2004 12:13:01 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54JD0TN066898 for ; Fri, 4 Jun 2004 12:13:00 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40C09A61.3070306@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 4 Jun 2004 15:12:34 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/04/2004 03:09:35 PM, Serialize complete at 06/04/2004 03:09:35 PM Content-Type: multipart/alternative; boundary="=_alternative 0069595985256EA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069595985256EA9_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 06/04/2004 11:50:57 AM: > > > It answers the quetion, what property names are in any VEVENTs in my > > > calendar. > > > If that is usful :-) > > > > It _could_ be useful if I needed to know "Is there a X-Hinkey-Minkey > > on any VEVENT in my calendar?" but I dont think thats a common need > > really or even necessary actually given most queries would just use > > "*" or can list any desired properties on the SELECT and then see what > > comes back. > > I think it is a very much needed feature. Have you looked at all of the > custom X- properties > and specific sub-sets of iTIP objects that are coming back? As I learn > them I add the > ability for the CUA to use them, or translate their features at run time > into CAP properties > or x- properties that I use, when they overlap. Just check out how > people define > time zones with special property names as one example. It may be useful for doing a "find me all properties and subcomponents that exist in this container" but I strongly doubt that its something done on a regular basis. It can be useful for debugging or protoyping purposes but not for normal CU day to day actions. Besides why do you care if if appears _anywhere_ in _any _ component when those properties will _always_ be returned as part of the normal "Give me this VEVENT" SEARCH: C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: TARGET:BrucesRelCal C: CMD:SEARCH C: BEGIN:VQUERY C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = '12345@acme.net' C: END:VQUERY C: END:VCALENDAR would result in: S: BEGIN:VCALENDAR S: TARGET:BrucesRelCal S: CMD:REPLY S: BEGIN:VREPLY S: BEGIN:VEVENT S: DTSTART;TZID="Eastern":20040602T090000 S: DTEND;TZID="Eastern":20040602T130000 S: TRANSP:TRANSPARENT S: DTSTAMP:20040604T181825Z S: CLASS:PRIVATE S: DESCRIPTION:Join us on Wednesday June 2nd for a presentation S: and watch the new Shrek 2 movie! S: SUMMARY:Demo Seminar and Movie S: LOCATION:AMC Burlington 10 S: ORGANIZER;CN="Bruce Kahn":mailto:Bruce_Kahn@notesdev.ibm.com S: UID:12345@acme.net S: X-Hinkey-Minkey:Some special value S: END:VEVENT S: END:VREPLY S: END:VCALENDAR The CUA is going to get _all_ the properties in the VEVENT so again I think this is only beneficial to developers who want to be able to do some form of data scanning; not that they can _interpret_ the results, just they can _see_ it. So again Ill ask what real benefit is there to the CU in being able to do a "give me all the properties that appear in an VEVENT in the calendar in a mush" dump on any kind of basis? I seriously doubt its useful to the end CU; it sounds more like something useful to developers only and only for occasional use even then. However even this kind of dump can be achieved thru other means that are just as simple (SELECT * FROM VEVENT) so again _what_ is the benefit in having the component.* in the query language?? Looking at it from a slightly different perspective, the only noticable difference between: SELECT VEVENT.* FROM VAGENDA and SELECT VEVENT FROM VAGENDA is just the 22 octets that make up the BEGIN:VEVENT / END:VEVENT wrappers of each VEVENT that would be returned. Well, that and the fact that the data from the former case is not actionable by the CUA but the data from the latter case actually is. So where is there any real benefit?? 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 0069595985256EA9_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 06/04/2004 11:50:57 AM:
> > > It answers the quetion, what property names are in any VEVENTs in my
> > > calendar.
> > > If that is usful :-)
> >
> > It _could_ be useful if I needed to know "Is there a X-Hinkey-Minkey
> > on any VEVENT in my calendar?" but I dont think thats a common need
> > really or even necessary actually given most queries would just use
> > "*" or can list any desired properties on the SELECT and then see what
> > comes back.  
>
> I think it is a very much needed feature. Have you looked at all of the
> custom X- properties
> and specific sub-sets of iTIP objects that are coming back? As I learn
> them I add the
> ability for the CUA to use them, or translate their features at run time
> into CAP properties
> or x- properties that I use, when they overlap. Just check out how
> people define
> time zones with special property names as one example.

It may be useful for doing a "find me all properties and subcomponents that exist in this container" but I strongly doubt that its something done on a regular basis.  It can be useful for debugging or protoyping purposes but not for normal CU day to day actions.

Besides why do you care if if appears _anywhere_ in _any _ component when those properties will _always_ be returned as part of the normal "Give me this VEVENT" SEARCH:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: TARGET:BrucesRelCal
   C: CMD:SEARCH
   C: BEGIN:VQUERY
   C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = '12345@acme.net'
   C: END:VQUERY
   C: END:VCALENDAR

would result in:

   S: BEGIN:VCALENDAR
   S: TARGET:BrucesRelCal
   S: CMD:REPLY
   S: BEGIN:VREPLY
   S: BEGIN:VEVENT
   S: DTSTART;TZID="Eastern":20040602T090000
   S: DTEND;TZID="Eastern":20040602T130000
   S: TRANSP:TRANSPARENT
   S: DTSTAMP:20040604T181825Z
   S: CLASS:PRIVATE
   S: DESCRIPTION:Join us on Wednesday June 2nd for a presentation
   S:  and  watch the new Shrek 2 movie!
   S: SUMMARY:Demo Seminar and Movie
   S: LOCATION:AMC Burlington 10
   S: ORGANIZER;CN="Bruce Kahn":mailto:Bruce_Kahn@notesdev.ibm.com
   S: UID:12345@acme.net
   S: X-Hinkey-Minkey:Some special value
   S: END:VEVENT
   S: END:VREPLY
   S: END:VCALENDAR

The CUA is going to get _all_ the properties in the VEVENT so again I think this is only beneficial to developers who want to be able to do some form of data scanning; not that they can _interpret_ the results, just they can _see_ it.

So again Ill ask what real benefit is there to the CU in being able to do a "give me all the properties that appear in an VEVENT in the calendar in a mush" dump on any kind of basis?  I seriously doubt its useful to the end CU; it sounds more like something useful to developers only and only for occasional use even then.   However even this kind of dump can be achieved thru other means that are just as simple (SELECT * FROM VEVENT) so again _what_ is the benefit in having the component.* in the query language??

Looking at it from a slightly different perspective, the only noticable difference between:

SELECT VEVENT.* FROM VAGENDA

and

SELECT VEVENT FROM VAGENDA

is just the 22 octets that make up the BEGIN:VEVENT / END:VEVENT wrappers of each VEVENT that would be returned.  Well, that and the fact that the data from the former case is not actionable by the CUA but the data from the latter case actually is.  So where is there any real benefit??

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 0069595985256EA9_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 16:25:55 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 QAA07705 for ; Fri, 4 Jun 2004 16:25:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54K9dPb074567; Fri, 4 Jun 2004 13:09:39 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54K9dH9074566; Fri, 4 Jun 2004 13:09:39 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54K9bxO074557 for ; Fri, 4 Jun 2004 13:09:39 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40C09DD0.3040600@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP-13: Another CAL-QUERY / VAGENDA question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 4 Jun 2004 16:05:59 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/04/2004 04:06:14 PM, Serialize complete at 06/04/2004 04:06:14 PM Content-Type: multipart/alternative; boundary="=_alternative 006E3D5685256EA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E3D5685256EA9_= Content-Type: text/plain; charset="US-ASCII" Doug responeded on 06/04/2004 12:05:36 PM: > > Can anyone point me to the parts I missing that describe "*.*"? I > > also question the need/use of "*.*" for VAGENDA and VCALSCALE. Why > > aren't the same rules from Section 6.1.1 sufficient for VAGENDA and > > VCALSCALE but they are sufficient for all other components that have > > the same nesting structure? [Snip, snip] > We need a way to get top level properties and not contained components. > And we need to way to get everything. '*' vs '*.*' just strings as far > as I am concerned. Ahh, now I see. You dont need it for _retrieving_ top level properties, you want it for top level property _discovery_ w/o having to download the other subcomponents. Thats all fine I think but there is _no_ text in CAP that actually _defines_ this explicitly. There are 2 uses of the phrase "the special '*.*' value" but there is no actual CAP text that describes this special value or its meaning (and how its different from "*"). Thats my point here. Actually, I think there has been some misunderstanding about "*.*" as well. In CAP-13 I read: To fetch all of the properties from the targeted VAGENDA and all of the contained components, use the special '*.*' value: SELECT *.* FROM VAGENDA but how is this NOT equivalent to how "*" is used in Section 6.1.1? That is: SELECT * FROM VAGENDA should be the same equivalent as "(d) SELECT * FROM VEVENT" which is interpreted as: (d) Selects every property and every component that is in any "VEVENT" component... They sure sound the same to me. Yet I think Doug is saying that the "*" case for VAGENDAs and VCALSTOREs is not the same; that "*.*" is the proper equivalent. There is also nothing in Section 6.1.1 that exempts VCALSTOREs and VAGENDAs from bullet item 7 that describes the use of "." nor is there any text at all in CAP actually defining what the meaning of "*" is in CAP-QL (see other thread). I can find no text in CAP-13 that says that "*" for VAGENDAs and VCALSTOREs is just properties and no subcontainers. If this had been part of the changes we made over time, it got lost from CAP and needs to be put back (or in). In addition, there needs It is also worth noting that the "*.*" is NOT necessary for property retrieval, merely for discovery. However its not _strinctly_ necessary since discovery can be done by using "*", you just have the added mush to wade thru. So, to summarize if I can: 1: There is no text in CAP-13 that actually defines "*."* for VCALSTORE and VAGENDA. There are 2 references to it but no actual defintion of it. 2: The addition of "*.*" for VCALSTORE and VAGENDA are strictly for top level property discovery. It is not necessary for actual top level property retrieval. 3: There is text in CAP-13 that makes "*.*" for VAGENDAs / VCALSTOREs equivalent to using "*" on all other components (including VAGENDAs / VCALSTOREs). 4: There was intent in the past to redefine "*" for VAGENDA / VCALSTORE to mean "no subcontainers, properties only" but we have no actual text to this effect. As previous WG flare ups have shown, we should not leave this kind of intent unwritten in the draft for future readers to intuit. I think we need to fill in some of the gaps with actual text expressly codifying our intentions. Anyone averse to clearing this up? 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 006E3D5685256EA9_= Content-Type: text/html; charset="US-ASCII"
Doug responeded on 06/04/2004 12:05:36 PM:
> > Can anyone point me to the parts I missing that describe "*.*"?  I
> > also question the need/use of "*.*" for VAGENDA and VCALSCALE.  Why
> > aren't the same rules from Section 6.1.1 sufficient for VAGENDA and
> > VCALSCALE but they are sufficient for all other components that have
> > the same nesting structure?
[Snip, snip]
> We need a way to get top level properties and not contained components.
> And we need to way to get everything. '*' vs '*.*' just strings as far
> as I am concerned.
Ahh, now I see.  You dont need it for _retrieving_ top level properties, you want it for top level property _discovery_ w/o having to download the other subcomponents.  

Thats all fine I think but there is _no_ text in CAP that actually _defines_ this explicitly.  There are 2 uses of the phrase "the special '*.*' value" but there is no actual CAP text that describes this special value or its meaning (and how its different from "*").  Thats my point here.

Actually, I think there has been some misunderstanding about "*.*" as well.  In CAP-13 I read:

   To fetch all of the properties from the targeted VAGENDA and all of
   the contained components, use the special '*.*' value:

   SELECT *.* FROM VAGENDA

but how is this NOT equivalent to how "*" is used in Section 6.1.1?  That is:

   SELECT * FROM VAGENDA

should be the same equivalent as "(d) SELECT * FROM VEVENT" which is interpreted as:

       (d) Selects every property and every component
           that is in any "VEVENT" component...

They sure sound the same to me.  Yet I think Doug is saying that the "*" case for VAGENDAs and VCALSTOREs is not the same; that "*.*" is the proper equivalent.

There is also nothing in Section 6.1.1 that exempts VCALSTOREs and VAGENDAs from bullet item 7 that describes the use of "."  nor is there any text at all in CAP actually defining what the meaning of "*" is in CAP-QL (see other thread).

I can find no text in CAP-13 that says that "*" for VAGENDAs and VCALSTOREs is just properties and no subcontainers.  If this had been part of the changes we made over time, it got lost from CAP and needs to be put back (or in).  In addition, there needs

It is also worth noting that the "*.*" is NOT necessary for property retrieval, merely for discovery.  However its not _strinctly_ necessary since discovery can be done by using "*", you just have the added mush to wade thru.

So, to summarize if I can:

1: There is no text in CAP-13 that actually defines "*."* for VCALSTORE and VAGENDA.  There are 2 references to it but no actual defintion of it.
2: The addition of "*.*" for VCALSTORE and VAGENDA are strictly for top level property discovery.  It is not necessary for actual top level property retrieval.
3: There is text in CAP-13 that makes "*.*" for VAGENDAs / VCALSTOREs equivalent to using "*" on all other components (including VAGENDAs / VCALSTOREs).  
4: There was intent in the past to redefine "*" for VAGENDA / VCALSTORE to mean "no subcontainers, properties only" but we have no actual text to this effect.

As previous WG flare ups have shown, we should not leave this kind of intent unwritten in the draft for future readers to intuit.   I think we need to fill in some of the gaps with actual text expressly codifying our intentions.  Anyone averse to clearing this up?

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 006E3D5685256EA9_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 16:46:42 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 QAA09851 for ; Fri, 4 Jun 2004 16:46:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54KOMll076878; Fri, 4 Jun 2004 13:24:22 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54KOMke076877; Fri, 4 Jun 2004 13:24:22 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54KOL9D076858 for ; Fri, 4 Jun 2004 13:24:21 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i54KOHus032066 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 4 Jun 2004 13:24:19 -0700 Message-ID: <40C0DA70.6070701@Royer.com> Date: Fri, 04 Jun 2004 14:24:16 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040107040303060906030708" 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. --------------ms040107040303060906030708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > It may be useful for doing a "find me all properties and subcomponents > that exist in this container" but I strongly doubt that its something > done on a regular basis. It can be useful for debugging or protoyping > purposes but not for normal CU day to day actions. It is used every time I load a calendar from an unknown source. One vendor has two modes it uses timezones and both with the same PRODID. Not all properties are in all objects even when they are the same type. The feature is documented. And works. And even if you do not want to use the feature it appears from this conversation that you did understand from CAP what that feature does when called. So it does not fall into the bug, broken, typo, or grammer category. And I thought that feature changes were off topic and we were into get CAP done mode. -- 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 --------------ms040107040303060906030708 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 9w0BCQUxDxcNMDQwNjA0MjAyNDE2WjAjBgkqhkiG9w0BCQQxFgQUnBIZztXXou5xvTIZYmls Lz4EuxIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAhoRYEfSFlinXUT7mf/LQbd3MRpnvOEa6o9XS2PklF0A1S2EhT/ZOKfkcQD5062O/ t+EktUwNb2r48K5JR3sF8aDwwSSpBedjVDj//pLawnlMy91Ov0xLXGkC88iTi+oz0vnEIGPJ 8z+EnzlAPc8U+/rrSE98BKvArqA03WRP841OcJo1g6jAnItl0uleBC2/bdSLYnAPhpo1so2m jffvvUVxdFNNvIpLcKzqW2xnd550i6NRaXxv5fPZln2VSN/OC3q/eJ4TV179zitjOuS5Z5sB RSHIF2cPtoCQ3gOIFvE/YWvrzgr8XkRbSbcoDmaJ8MhYMVbsf+6aEoEsnkbaVQAAAAAAAA== --------------ms040107040303060906030708-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 18:15: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 SAA22086 for ; Fri, 4 Jun 2004 18:15:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54M2ejP090711; Fri, 4 Jun 2004 15:02:40 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54M2eKg090710; Fri, 4 Jun 2004 15:02:40 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54M2dSx090689 for ; Fri, 4 Jun 2004 15:02:39 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40C0DA70.6070701@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 4 Jun 2004 18:02:23 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/04/2004 05:59:15 PM, Serialize complete at 06/04/2004 05:59:15 PM Content-Type: multipart/alternative; boundary="=_alternative 0078E57C85256EA9_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0078E57C85256EA9_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 06/04/2004 04:24:16 PM: > > It may be useful for doing a "find me all properties and subcomponents > > that exist in this container" but I strongly doubt that its something > > done on a regular basis. It can be useful for debugging or protoyping > > purposes but not for normal CU day to day actions. > > It is used every time I load a calendar from an unknown source. Im not sure where you are finding many calendars "from an unknown source" but doing a "full property and subcomponent mush" extraction of all properties and subcomponents is NOT something you really should be doing every time. It just doesnt scale well, especially if there is lots of data in the calendar. Hmm, perhaps this is why it looks different, the wrappers have been stripped away. Plus, in case you missed it in my reply, you only save 22 octets per subcomponent by having the CS remove the top most container wrapper. Thats hardly a big justification for this feature give the hassles it causes with multiple subcomponents (ie: multiple VALARMs or multiple VEVENTs) being all mushed together. > The feature is documented. And works. And even if you do not want to use > the feature > it appears from this conversation that you did understand from CAP > what that > feature does when called. I fully get the technical aspects of the bits Im questioning. Im questioning their actual pratical use / benefit. Just because you have protoyped up code based on the current text does not mean that its the correct thing to have in CAP. Having the CS strip off the BEGIN/END markers has 2 effects: 1: It saves a mere 22 octets of data per subcomponent being returned and 2: Causes the data belonging to all subcomponents to bleed together into a mush that makes separate subcomponent identification and use impossible Please show me how this is useful. > And I thought that feature changes were off topic and we were into get > CAP done mode. This thread has evolved into a questioning of the CAP design from my original question. Asking questions of the design is still allowed in the WG last I checked. By now it should be simple enough to give a good justification for everying in CAP; otherwise it has not been properly thought out and clearly described. Given the 2 points above I find it hard to say that this was fully thought out and this part may need some reworking (or simplification). Perhaps this is an artifact of our backtracking from using SQL as the query lingua (as evident by the column / table phrasing in Section 6.1.1 still). Perhaps its an artifact of having so many editors over time that some things just did not make it into the current text like they should have. If the "component.*" concept was removed from 6.1.1, you can _still_ get all your data from all the unknown sources you want. It would just be a few octets longer AND all subcomponents would be fully parsable, separatable and usable. How would that be bad?? 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 0078E57C85256EA9_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 06/04/2004 04:24:16 PM:
> > It may be useful for doing a "find me all properties and subcomponents
> > that exist in this container" but I strongly doubt that its something
> > done on a regular basis.  It can be useful for debugging or protoyping
> > purposes but not for normal CU day to day actions.
>
> It is used every time I load a calendar from an unknown source.
Im not sure where you are finding many calendars "from an unknown source" but doing a "full property and subcomponent mush" extraction of all properties and subcomponents is NOT something you really should be doing every time.  It just doesnt scale well, especially if there is lots of data in the calendar.   Hmm, perhaps this is why it looks different, the wrappers have been stripped away.

Plus, in case you missed it in my reply, you only save 22 octets per subcomponent by having the CS remove the top most container wrapper.  Thats hardly a big justification for this feature give the hassles it causes with multiple subcomponents (ie: multiple VALARMs or multiple VEVENTs) being all mushed together.  

> The feature is documented. And works. And even if you do not want to use
> the feature
> it appears from this conversation that you did understand from  CAP  
> what that
> feature does when called.

I fully get the technical aspects of the bits Im questioning.  Im questioning their actual pratical use / benefit.  Just because you have protoyped up code based on the current text does not mean that its the correct thing to have in CAP.

Having the CS strip off the BEGIN/END markers has 2 effects:

1: It saves a mere 22 octets of data per subcomponent being returned and
2: Causes the data belonging to all subcomponents to bleed together into a mush that makes separate subcomponent identification and use impossible

Please show me how this is useful.

> And I thought that feature changes were off topic and we were into get
> CAP done mode.

This thread has evolved into a questioning of the CAP design from my original question.  Asking questions of the design is still allowed in the WG last I checked.  By now it should be simple enough to give a good justification for everying in CAP; otherwise it has not been properly thought out and clearly described.  

Given the 2 points above I find it hard to say that this was fully thought out and this part may need some reworking (or simplification).  Perhaps this is an artifact of our backtracking from using SQL as the query lingua (as evident by the column / table phrasing in Section 6.1.1 still).  Perhaps its an artifact of having so many editors over time that some things just did not make it into the current text like they should have.

If the "component.*" concept was removed from 6.1.1, you can _still_ get all your data from all the unknown sources you want.  It would just be a few octets longer AND all subcomponents would be fully parsable, separatable and usable.  How would that be bad??  

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 0078E57C85256EA9_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 4 18:40:57 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 SAA24713 for ; Fri, 4 Jun 2004 18:40:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i54MUfR2093954; Fri, 4 Jun 2004 15:30:41 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i54MUfwr093953; Fri, 4 Jun 2004 15:30:41 -0700 (PDT) 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.11/8.12.9) with ESMTP id i54MUeOk093936 for ; Fri, 4 Jun 2004 15:30:40 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i54MUXus002461 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 4 Jun 2004 15:30:35 -0700 Message-ID: <40C0F808.9040601@Royer.com> Date: Fri, 04 Jun 2004 16:30:32 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050405050502080807020906" 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. --------------ms050405050502080807020906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 06/04/2004 04:24:16 PM: > > > It may be useful for doing a "find me all properties and > subcomponents > > > that exist in this container" but I strongly doubt that its something > > > done on a regular basis. It can be useful for debugging or > protoyping > > > purposes but not for normal CU day to day actions. > > > > It is used every time I load a calendar from an unknown source. > > Im not sure where you are finding many calendars "from an unknown source" Hint - from other CUA's that I did not write. -- 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 --------------ms050405050502080807020906 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 9w0BCQUxDxcNMDQwNjA0MjIzMDMyWjAjBgkqhkiG9w0BCQQxFgQU7MrlKjywn1EMlmDH3T8L WfVclB0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA1yvTb9qHt1rLNzb+dzwqvW4wPBPfPru53M1dQKr6PIHcME9WFXy2qiqyAAq4Sq8i vCazziDtHS2xQX/GwGdr87aZ9xc148BYIgRG/kty48XXXwDdnwYOTKiliLeoQgDEN41YxB/4 wG+OsDRUEIXz9tZQEj0itcWLR0INb9nclDDlSDyxSAT+ztxa+9VYpFxgETK6ZI2iRh+g4uSb 03206hzV7tyznzryxxiwS6THB4lMK44IRmY7tw0aEFfjbv4cRAOeDWLf80J7JIMpzefyMXXt zB6P+g+EEhh2l7vxUb9XgIGmctgN7Fu/TH2j2xPbADvYk/ikjWdAnVbT7rTc8AAAAAAAAA== --------------ms050405050502080807020906-- From owner-ietf-calendar@mail.imc.org Sat Jun 5 09:33:02 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 JAA13399 for ; Sat, 5 Jun 2004 09:33:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i55DBlui094254; Sat, 5 Jun 2004 06:11:47 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i55DBlpn094253; Sat, 5 Jun 2004 06:11:47 -0700 (PDT) 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.11/8.12.9) with ESMTP id i55DBhhs094238 for ; Sat, 5 Jun 2004 06:11:45 -0700 (PDT) (envelope-from pregen@egenconsulting.com) In-Reply-To: To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: pregen@egenconsulting.com Date: Sat, 5 Jun 2004 09:11:41 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.0.3|September 26, 2003) at 06/05/2004 09:11:48 AM, Serialize complete at 06/05/2004 09:11:48 AM Content-Type: multipart/alternative; boundary="=_alternative 0048542D85256EAA_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0048542D85256EAA_= Content-Type: text/plain; charset="US-ASCII" Here's the link. It may be a few months behind - I'll put a new copy out there next week. http://www.egenconsulting.com/ietf/ietfcns.nsf Bruce_Kahn@notesdev.ibm.com Sent by: owner-ietf-calendar@mail.imc.org 06/04/2004 10:55 AM To ietf-calendar@imc.org cc Subject Re: CAP 13: Bad CAL-QUERY example / description? Tim replied on 06/03/2004 10:49:10 PM: > It seems to me that a component should be the "atomic" element retrieved > for queries, and the CUA should do its own parsing/query of properties to > find out more of the details, but that's just my opinion. I would like to > go back and read some of the QUERY development process in the archives - > does anyone have a guess about what timeframes this was taking place? Pat has an online Full Text indexed copy of the WG archive going back to 1996 when the WG was created. I dont have the URL she posted but it should be available here or you can poke her in case shes not following this thread. That should allow you to full text search the archives for phrases like "VEVENT.*" or whatever. 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 0048542D85256EAA_= Content-Type: text/html; charset="US-ASCII"
Here's the link.  It may be a few months behind - I'll put a new copy out there next week.

http://www.egenconsulting.com/ietf/ietfcns.nsf


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

06/04/2004 10:55 AM

To
ietf-calendar@imc.org
cc
Subject
Re: CAP 13: Bad CAL-QUERY example / description?






Tim replied on 06/03/2004 10:49:10 PM:
> It seems to me that a component should be the "atomic" element retrieved
> for queries, and the CUA should do its own parsing/query of properties to
> find out more of the details, but that's just my opinion. I would like to
> go back and read some of the QUERY development process in the archives -
> does anyone have a guess about what timeframes this was taking place?

Pat has an online Full Text indexed copy of the WG archive going back to 1996 when the WG was created.  I dont have the URL she posted but it should be available here or you can poke her in case shes not following this thread.  That should allow you to full text search the archives for phrases like "VEVENT.*" or whatever.

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 0048542D85256EAA_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 7 10:48:47 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 KAA21437 for ; Mon, 7 Jun 2004 10:48:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57EDvUI056627; Mon, 7 Jun 2004 07:13:57 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i57EDvET056626; Mon, 7 Jun 2004 07:13:57 -0700 (PDT) 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.11/8.12.9) with ESMTP id i57EDvA6056608 for ; Mon, 7 Jun 2004 07:13:57 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40C0F808.9040601@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 7 Jun 2004 10:07:18 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/07/2004 10:10:30 AM, Serialize complete at 06/07/2004 10:10:30 AM Content-Type: multipart/alternative; boundary="=_alternative 004DF49185256EAC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 004DF49185256EAC_= Content-Type: text/plain; charset="US-ASCII" Doug briefly wrote on 06/04/2004 06:30:32 PM: > > Im not sure where you are finding many calendars "from an unknown source" > > Hint - from other CUA's that I did not write. Thanks for clarifying that non-question. I dont think I could have figured that out ever. BTW: I was questioning _what_ you consider "an unknown source" in the _runtime_ environments that a customer / end user (not you personally Doug) will be in but I didnt think I had to clearly define that. Mea culpa, sorry... (Please dont try to clarify that now; lets try to stay focused on the technical questions if we can shall we.) How about addressing the actual questions / issues that were in the rest my posting? 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 004DF49185256EAC_= Content-Type: text/html; charset="US-ASCII"
Doug briefly wrote on 06/04/2004 06:30:32 PM:
> > Im not sure where you are finding many calendars "from an unknown source"
>
> Hint - from other CUA's that I did not write.
Thanks for clarifying that non-question.  I dont think I could have figured that out ever.  BTW: I was questioning _what_ you consider "an unknown source" in the _runtime_ environments that a customer / end user (not you personally Doug) will be in but I didnt think I had to clearly define that.  Mea culpa, sorry...  (Please dont try to clarify that now; lets try to stay focused on the technical questions if we can shall we.)

How about addressing the actual questions / issues that were in the rest my posting?

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 004DF49185256EAC_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 7 12: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 MAA25641 for ; Mon, 7 Jun 2004 12:06:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57FigQC067279; Mon, 7 Jun 2004 08:44:42 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i57Figls067278; Mon, 7 Jun 2004 08:44:42 -0700 (PDT) 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.11/8.12.9) with ESMTP id i57Fif8O067266 for ; Mon, 7 Jun 2004 08:44:41 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i57FiZMn020863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 7 Jun 2004 08:44:37 -0700 Message-ID: <40C48D62.8040205@Royer.com> Date: Mon, 07 Jun 2004 09:44:34 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000902090000020602030208" 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. --------------ms000902090000020602030208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > How about addressing the actual questions / issues that were in the > rest my posting? I did not see any new questions that had not already been answered. -- 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 --------------ms000902090000020602030208 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 9w0BCQUxDxcNMDQwNjA3MTU0NDM0WjAjBgkqhkiG9w0BCQQxFgQU6iDcZkL59b+rqqclX63b c3oBSEQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAVqzOoZyDG9/TRqBOWZR6MAnpwa4si5qlemmw6Z+cbd9QV0yXUDuMAy3eqd/Ajwgq o0X0KQUyB8lcMTicv1DVUaKQezUagbwWFRjQjB3qdwgWwuDgt2F9TjLr7bh8Lv9u4wgjWMgi T52DfPYnBeUVfKZoEfw66ECBwKvDfK78yTOlGE6v1W81dZtKvIVYlJcNleYaKNAOFexyGfTO Wz9pFJ38C/QFVeEAw5sDK20nQiEq5sK2LZPattFglame0/HVR+tKcL6lOm1OnDcO55ZcNeFh YmK0XDM849Yu0erQIeHbReXLDYZ6qduppeFpb1OoffcuX43vXCycSsIdse10qgAAAAAAAA== --------------ms000902090000020602030208-- From owner-ietf-calendar@mail.imc.org Mon Jun 7 17:18:51 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 RAA21136 for ; Mon, 7 Jun 2004 17:18:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57L0c5G001764; Mon, 7 Jun 2004 14:00:38 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i57L0cmH001763; Mon, 7 Jun 2004 14:00:38 -0700 (PDT) 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.11/8.12.9) with ESMTP id i57L0cCj001748 for ; Mon, 7 Jun 2004 14:00:38 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40C48D62.8040205@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_05252004NP May 25, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 7 Jun 2004 16:59:54 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/07/2004 04:57:13 PM, Serialize complete at 06/07/2004 04:57:13 PM Content-Type: multipart/alternative; boundary="=_alternative 00733BA185256EAC_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00733BA185256EAC_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 06/07/2004 11:44:34 AM: > I did not see any new questions that had not already been answered. There was 1 question and one non-direct question that have not been answered yet. First the non-direct question: > Having the CS strip off the BEGIN/END markers has 2 effects: > > 1: It saves a mere 22 octets of data per subcomponent being returned and > 2: Causes the data belonging to all subcomponents to bleed together > into a mush that makes separate subcomponent identification and use impossible > > Please show me how this is useful. To make it a formal question then; Can anyone please show me how this is really useful? The undiscussed/unanswered question: > If the "component.*" concept was removed from 6.1.1, you can _still_ > get all your data from all the unknown sources you want. It would > just be a few octets longer AND all subcomponents would be fully > parsable, separatable and usable. How would that be bad?? In the interest of saving time and merging this thread with the other one about "*.*" I have a proposal that will: A: Resolve any ambiguity related to the usefulness of "component.*" vs "component" on searches B: Allow for property discovery without the need for full contained component retrieval. C: Remove the undefined "*.*" special case need for some containers that matches the (semi) defintiion of "*" in Section 6.1.1 D: Remove the useless case of returning subcomponent data without the BEGIN/END wrappers. Given: 1: There are times when a CUA wants to perform property _discovery_ instead of actual property _processing_ (implicitly described by Doug although never actually addressed in CAP text) and 2: The lack of subcomponent BEGIN/END wrappers saves a mere 22 octets BUT results in an unprocessable mush of subcomponents and properties and 3: There is at least one ambiguity/conflict between the use of "*" and "*.*" in the current text I propose we make the following simple changes to CAP that will address and resolve all the questions/issues found to date: (A) We remove any concept of "component.*" vs "component" in CAP (essentially bullet item 7 in Section 6.1.1). Whenever a subcomponent is requested, it will ALWAYS result in that entire subcomponent being returned intact (wrappers NOT removed). In the SELECT clause, there never should be a "component.*" or "*.*" usage necessary. (B) To simplify things, we define the use of "*" in the SELECT clause to only refer to properties or entire containers. We change bullet 7 to Section 6.1.1 that says: 7. When the "SELECT" clause of the query contains an "*" value, contained components are not automatically included in the returned results. Only those properties found in the component in the FROM clause (or the implicit container in the case of VCALSTOREs and VAGENDAs) are returned. If the requestor wants contained components to be included in the returned results, they need to expressly request the desired contained component(s) (or all of them) using the proper "INCLUDE" clause. Contained components are always returned with their BEGIN/END markers intact so that component integrity is maintained and no mismatching of properties will accidentally occur. To indicate all contained components should be included, the value of "*" should be used in the "INCLUDE" clause of the query. To indicate all properties but no contained components should be returned, no "INCLUDE" clause would be used in the query. 8. When the "SELECT" clause of the query contains a contained component, the entire contained component is returned along with its BEGIN/END markers so that component integrity is maintained and no mismatching of properties will accidentally occur. (C) We slightly change the cal-query ABNF to allow the requestor to simply and direclty indicate which subcontainers they want, if any. We also remove the questionable ability to SELECT subcomponet values only. We change the ABNF to: cal-query = "SELECT" SP cap-val SP [ "INCLUDE" SP cal-include SP ] ; ONLY occurs when the "SELECT" cap-val contains an "*" value "FROM" SP comp-name SP "WHERE" SP cap-expr / "SELECT" SP cap-cols SP [ "INCLUDE" SP cal-include SP ] ; ONLY occurs when the "SELECT" cap-val contains an "*" value "FROM" SP comp-name cap-val = cap-cols / param / ( cap-val "," cap-val ) cap-cols = cap-col-select / ( cap-cols "," cap-col-select) / "*" cap-col-select = comp-name / cap-prop cal-include = all ; This value indicates ALL subcomponents are desired / comp-name ; This value indicates a particular desired subcomponent / ( cal-include "," comp-name) ; This value indicates a list of desired subcomponents to reflect that the CUA now clearly indicates if they want any subcomponents or not and which ones even (so its not an "all or nothing" deal). "all" is already defined elsewhere in CAP ABNF. Also, the ability to use subcomponent properties in "WHERE" clauses is still intact. This means that you can still use queries like that of (e) in Section 6.1.1 without actually having to retreive the VALARM too. (D) We remove the text in CAP that special cases "*.*" for VCALSTORE and VAGENDA since it is no longer necessary with the above changes. Thoughts / comments / feedback? 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 00733BA185256EAC_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 06/07/2004 11:44:34 AM:
> I did not see any new questions that had not already been answered.
There was 1 question and one non-direct question that have not been answered yet.  First the non-direct question:

> Having the CS strip off the BEGIN/END markers has 2 effects:
>
> 1: It saves a mere 22 octets of data per subcomponent being returned and
> 2: Causes the data belonging to all subcomponents to bleed together
> into a mush that makes separate subcomponent identification and use impossible
>
> Please show me how this is useful.

To make it a formal question then; Can anyone please show me how this is really useful?

The undiscussed/unanswered question:

> If the "component.*" concept was removed from 6.1.1, you can _still_
> get all your data from all the unknown sources you want.  It would
> just be a few octets longer AND all subcomponents would be fully
> parsable, separatable and usable.  How would that be bad??  

In the interest of saving time and merging this thread with the other one about "*.*" I have a proposal that will:

A: Resolve any ambiguity related to the usefulness of "component.*" vs "component" on searches
B: Allow for property discovery without the need for full contained component retrieval.
C: Remove the undefined "*.*" special case need for some containers that matches the (semi) defintiion of "*" in Section 6.1.1
D: Remove the useless case of returning subcomponent data without the BEGIN/END wrappers.

Given:

1: There are times when a CUA wants to perform property _discovery_ instead of actual property _processing_ (implicitly described by Doug although never actually addressed in CAP text) and
2: The lack of subcomponent BEGIN/END wrappers saves a mere 22 octets BUT results in an unprocessable mush of subcomponents and properties and
3: There is at least one ambiguity/conflict between the use of "*" and "*.*" in the current text

I propose we make the following simple changes to CAP that will address and resolve all the questions/issues found to date:

        (A) We remove any concept of "component.*" vs "component" in CAP (essentially bullet item 7 in Section 6.1.1).  Whenever a subcomponent is requested, it will ALWAYS result in that entire subcomponent being returned intact (wrappers NOT removed).  In the SELECT clause, there never should be a "component.*" or "*.*" usage necessary.

        (B) To simplify things, we define the use of "*" in the SELECT clause to only refer to properties or entire containers.  We change bullet 7 to Section 6.1.1 that says:

        7. When the "SELECT" clause of the query contains an "*" value, contained
           components are not automatically included in the returned results.  Only
           those properties found in the component in the FROM clause (or the
           implicit container in the case of VCALSTOREs and VAGENDAs) are returned.
           If the requestor wants contained components to be included in
           the returned results, they need to expressly request the desired
           contained component(s) (or all of them) using the proper "INCLUDE"
           clause.  Contained components are always returned with their
           BEGIN/END markers intact so that component integrity is maintained
           and no mismatching of properties will accidentally occur.  To indicate
           all contained components should be included, the value of "*" should
           be used in the "INCLUDE" clause of the query.  To indicate all properties
           but no contained components should be returned, no "INCLUDE" clause would
           be used in the query.
        8. When the "SELECT" clause of the query contains a contained component,
           the entire contained component is returned along with its BEGIN/END
           markers so that component integrity is maintained and no mismatching of
           properties will accidentally occur.

        (C) We slightly change the cal-query ABNF to allow the requestor to simply and direclty indicate which subcontainers they want, if any.  We also remove the questionable ability to SELECT subcomponet values only.  
        We change the ABNF to:

     cal-query  = "SELECT" SP cap-val SP
                  [ "INCLUDE" SP cal-include SP ]        ; ONLY occurs when the "SELECT" cap-val contains an "*" value
                  "FROM" SP comp-name SP
                  "WHERE" SP cap-expr

                / "SELECT" SP cap-cols SP
                  [ "INCLUDE" SP cal-include SP ]        ; ONLY occurs when the "SELECT" cap-val contains an "*" value
                  "FROM"   SP comp-name

     cap-val  = cap-cols
           / param
                / ( cap-val "," cap-val )

     cap-cols = cap-col-select
           / ( cap-cols "," cap-col-select)
           / "*"

     cap-col-select    = comp-name
                       / cap-prop

     cal-include  = all   ; This value indicates ALL subcomponents are desired
                / comp-name    ; This value indicates a particular desired subcomponent
                / ( cal-include "," comp-name) ; This value indicates a list of desired subcomponents

        to reflect that the CUA now clearly indicates if they want any subcomponents or not and which ones even (so its not an "all or nothing" deal).  
        "all" is already defined elsewhere in CAP ABNF.  
        Also, the ability to use subcomponent properties in "WHERE" clauses is still intact.  This means that you can still use queries like that of (e) in Section 6.1.1 without actually having to retreive the VALARM too.

        (D) We remove the text in CAP that special cases "*.*" for VCALSTORE and VAGENDA since it is no longer necessary with the above changes.

Thoughts / comments / feedback?

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 00733BA185256EAC_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 7 17:55:08 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 RAA26437 for ; Mon, 7 Jun 2004 17:55:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57LdwIC005232; Mon, 7 Jun 2004 14:39:58 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i57Ldw96005231; Mon, 7 Jun 2004 14:39:58 -0700 (PDT) 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.11/8.12.9) with ESMTP id i57LdvRx005220 for ; Mon, 7 Jun 2004 14:39:58 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i57LdoMn028061 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 7 Jun 2004 14:39:52 -0700 Message-ID: <40C4E0A5.6040200@Royer.com> Date: Mon, 07 Jun 2004 15:39:49 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040703060606040509010809" 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. --------------ms040703060606040509010809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 06/07/2004 11:44:34 AM: > > I did not see any new questions that had not already been answered. > > There was 1 question and one non-direct question that have not been > answered yet. First the non-direct question: > > > Having the CS strip off the BEGIN/END markers has 2 effects: > > > > 1: It saves a mere 22 octets of data per subcomponent being returned > and > > 2: Causes the data belonging to all subcomponents to bleed together > > into a mush that makes separate subcomponent identification and use > impossible > > > > Please show me how this is useful. > > To make it a formal question then; Can anyone please show me how this > is really useful? I made no argument that it was or was smaller per object. > > The undiscussed/unanswered question: > > > If the "component.*" concept was removed from 6.1.1, you can _still_ > > get all your data from all the unknown sources you want. It would > > just be a few octets longer AND all subcomponents would be fully > > parsable, separatable and usable. How would that be bad?? You forgot embedded object are included in the other form. MUCH more that 22 octets per object. And again it works as documented, is it really worth rewriting simply becuase you want it another way? What is your justification for wanting to change this at this late date? -- 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 --------------ms040703060606040509010809 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 9w0BCQUxDxcNMDQwNjA3MjEzOTQ5WjAjBgkqhkiG9w0BCQQxFgQUnvS2ryISxLF3EZjZhME7 ZPVw41MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAXPS7SZ+d1sdLHH6cV08bp0A6rnPy6ljt4Oa0/kHUOsK8CinkTzyi/7zmsjE0wm6b mqRzvKMeKwkhiEHo6e66n3iBX3ziAZ3ptmUeng94HjsQIJXVfLlbeprm0vy+Q9Wud5udzodH 6o44IYV03BhGUV2G4Nn+3b6IZY7cdF437EIoZcIPuG2PQ95NHB1DETIZxMashiH3NriGezNG GTA2EmlR5pTY9ThsAf1bNYirmospEOONM1IZFUcbmwvNF88FerFAhS8UX7yF6zWsvs5FRuyu imZNZIrRYsjLOvCurID1ZU/2agsLD4rZbzqKangR3guXmpK8NihfVfPY4ZfoIgAAAAAAAA== --------------ms040703060606040509010809-- From owner-ietf-calendar@mail.imc.org Tue Jun 8 14:42:24 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 OAA15465 for ; Tue, 8 Jun 2004 14:42:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i58IOEiE031565; Tue, 8 Jun 2004 11:24:14 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i58IOE46031564; Tue, 8 Jun 2004 11:24:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from fed1rmmtao12.cox.net (fed1rmmtao12.cox.net [68.230.241.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i58IOCl0031547 for ; Tue, 8 Jun 2004 11:24:13 -0700 (PDT) (envelope-from Dave.Thewlis@calconnect.org) Received: from NetVista ([68.227.176.136]) by fed1rmmtao12.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040608182411.XCPW1034.fed1rmmtao12.cox.net@NetVista> for ; Tue, 8 Jun 2004 14:24:11 -0400 Message-ID: <200406081124050904.0129FB34@smtp.west.cox.net> References: <200405030712010382.003A2EBC@smtp.west.cox.net> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Tue, 08 Jun 2004 11:24:05 -0700 Reply-To: Dave.Thewlis@calconnect.org From: "David C. Thewlis" To: "IETF CALSCH" Subject: Reminder: Calendaring Interop at UCB July 29-30 2004 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a reminder that the first Interop sponsored by The Calendaring and Scheduling Consortium will be held 29-30 July 2004 at the University of California in Berkeley. The primary goal of this Interop will be testing RFC 2445-6 and 7: icalendar, iMIP and iTIP. We will have a test script to follow and will be working to get all MUSTS and SHOULDs in all three drafts working between at least two vendors or implementations, with the goal of moving the RFCs forward to standards status. Logistical and Registration information on this event is posted on the Consortium website at http://www.calconnect.org (choose Future Interops). If you are thinking about or contemplating participating, I would like to encourage you to let me know soon, and to register as soon as possible. We need to have a good notion of the number of attendees and participants soon to ensure facilties and other logistics can be arranged. If you've got any questions my contact information is below. Hope to see you in Berkeley. Dave Thewlis, Executive Director The Calendaring and Scheduling Consortium 1550 Dena Drive McKinleyville CA 95519-4146 +1 707 840 9391 (voice) +1 415 946 3454 (fax) Dave.Thewlis@calconnect.org www.calconnect.org From owner-ietf-calendar@mail.imc.org Fri Jun 11 12:37: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 MAA15949 for ; Fri, 11 Jun 2004 12:37:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BGK1rJ029479; Fri, 11 Jun 2004 09:20:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BGK1bp029478; Fri, 11 Jun 2004 09:20:01 -0700 (PDT) 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.11/8.12.9) with ESMTP id i5BGK0Md029451 for ; Fri, 11 Jun 2004 09:20:00 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40C4E0A5.6040200@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_06082004NP June 08, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 11 Jun 2004 12:19:38 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/11/2004 12:16:34 PM, Serialize complete at 06/11/2004 12:16:34 PM Content-Type: multipart/alternative; boundary="=_alternative 00597D4B85256EB0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00597D4B85256EB0_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 06/07/2004 05:39:49 PM: > > > If the "component.*" concept was removed from 6.1.1, you can _still_ > > > get all your data from all the unknown sources you want. It would > > > just be a few octets longer AND all subcomponents would be fully > > > parsable, separatable and usable. How would that be bad?? > > You forgot embedded object are included in the other form. MUCH more > that 22 octets per object. Please show me how I forgot embedded objects? I fully took into account subcontainers and preserving their integrity when returning them so they would be intact and useable. When using component names in the SELECT clause, they are to be returned with wrappers intact. When using "SELECT *" and an INCLUDE clause, the specified subcontainers are returned with wrappers intact. Nowhere in any current CAP text did it say that all wrappers for nested subcontainers are to be stripped away. That is, nowhere does it say that: SELECT VEVENT.* FROM VAGENDA would result in all VALARMs in all the VEVENTS would be returned without the BEGIN/END wrappers. Go recheck bullet #7, it only talks about the given components wrappers. > And again it works as documented, is it really worth rewriting simply > becuase you want > it another way? What is your justification for wanting to change this at > this late date? Im not sure if this is a case of miscommunication of the issues, personality conflict or the normal vendor desire to get something RFCd out so products can be shipped so Ill opt for the first one and try again. There are ambiguities and questionable cases in the query language that I think should be resolved before we go to Last Call. "Works as documented" does not address the ambiguities or justify seemingly useless aspects of the query language. The core issues I have are simply put: 1: Component integrity is not always preserved. There has been no justification given for the component-name.* use in the SELECT clause. It results in data that is all mushed togther and not useable as returned. 2: There are "special cases" in CAP that result in different formats returning the same data. So far there has been no reason given for why we need the special cases really. I want to have a query language thats clear, concise and unambiguious. That is why I made my proposal. The changes are not that drastic as you would make it sound and I think they even simplify things. 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 00597D4B85256EB0_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 06/07/2004 05:39:49 PM:
> > > If the "component.*" concept was removed from 6.1.1, you can _still_
> > > get all your data from all the unknown sources you want.  It would
> > > just be a few octets longer AND all subcomponents would be fully
> > > parsable, separatable and usable.  How would that be bad??  
>
> You forgot embedded object are included in the other form. MUCH more
> that 22 octets per object.
Please show me how I forgot embedded objects?  I fully took into account subcontainers and preserving their integrity when returning them so they would be intact and useable.  

When using component names in the SELECT clause, they are to be returned with wrappers intact.  

When using "SELECT *" and an INCLUDE clause, the specified subcontainers are returned with wrappers intact.

Nowhere in any current CAP text did it say that all wrappers for nested subcontainers are to be stripped away.  That is, nowhere does it say that:

        SELECT VEVENT.* FROM VAGENDA

would result in all VALARMs in all the VEVENTS would be returned without the BEGIN/END wrappers.  Go recheck bullet #7, it only talks about the given components wrappers.

> And again it works as documented, is it really worth rewriting simply
> becuase you want
> it another way? What is your justification for wanting to change this at
> this late date?
Im not sure if this is a case of miscommunication of the issues, personality conflict or the normal vendor desire to get something RFCd out so products can be shipped so Ill opt for the first one and try again.

There are ambiguities and questionable cases in the query language that I think should be resolved before we go to Last Call.  "Works as documented" does not address the ambiguities or justify seemingly useless aspects of the query language.

The core issues I have are simply put:

1: Component integrity is not always preserved.  There has been no justification given for the component-name.* use in the SELECT clause.  It results in data that is all mushed togther and not useable as returned.
2: There are "special cases" in CAP that result in different formats returning the same data.  So far there has been no reason given for why we need the special cases really.

I want to have a query language thats clear, concise and unambiguious.  That is why I made my proposal.  The changes are not that drastic as you would make it sound and I think they even simplify things.
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 00597D4B85256EB0_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 11 13:56:18 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 NAA21365 for ; Fri, 11 Jun 2004 13:56:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BHekG5049492; Fri, 11 Jun 2004 10:40:46 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BHekfG049491; Fri, 11 Jun 2004 10:40:46 -0700 (PDT) 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.11/8.12.9) with ESMTP id i5BHeifs049448 for ; Fri, 11 Jun 2004 10:40:45 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i5BHeXMn029391 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 11 Jun 2004 10:40:36 -0700 Message-ID: <40C9EE8F.5050804@Royer.com> Date: Fri, 11 Jun 2004 11:40:31 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040102030804010702050408" 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. --------------ms040102030804010702050408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > 1: Component integrity is not always preserved. So you say. EXACTLY HOW? > There has been no justification given for the component-name.* use in > the SELECT clause. It results in data that is all mushed togther and > not useable as returned. > 2: There are "special cases" in CAP that result in different formats > returning the same data. So far there has been no reason given for > why we need the special cases really. Simply not true. -- 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 --------------ms040102030804010702050408 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 9w0BCQUxDxcNMDQwNjExMTc0MDMxWjAjBgkqhkiG9w0BCQQxFgQU4G+5EeKMkZNQptZ0dBJD sNvaKYIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEA4hYodWrFtkmXo5NfWAfIQee7XtgWx/AnOvPzlwhb/Bg8VZiWFv5eF1KWSl1J0rXR 8xCgUmxxS6Y3AfRXAhdKKN3qfO/PtBn5XlAovYJ8UxtxqmG0/dW3zYL6PljuS5tIwvtn1EMt Qe+k+AsPF7U65yg0KqZxcizXDxazfMvZ5Sy678r+72zKWGhffdk3CaDvimJbBOvFa3wESaop Pik3r5BVGAe5RAZpP7YV6vnk33ZQS8yw88RHXLXyJBTLMaOnAxCKwLZJ1wJk9dzDwZQ/OPGc ZSgmScu77PrheXU/wRjAA0jUKI30zUk2w4srfE/ccieNuXytaNqHVe2EnwwPNAAAAAAAAA== --------------ms040102030804010702050408-- From owner-ietf-calendar@mail.imc.org Fri Jun 11 15:24:37 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 PAA27031 for ; Fri, 11 Jun 2004 15:24:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BJ7jZ5065967; Fri, 11 Jun 2004 12:07:45 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BJ7jlF065966; Fri, 11 Jun 2004 12:07:45 -0700 (PDT) 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.11/8.12.9) with ESMTP id i5BJ7jx6065948 for ; Fri, 11 Jun 2004 12:07:45 -0700 (PDT) (envelope-from Bruce_Kahn@notesdev.ibm.com) In-Reply-To: <40C9EE8F.5050804@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_06082004NP June 08, 2004 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 11 Jun 2004 15:07:35 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Release 6.0.2CF1|June 9, 2003) at 06/11/2004 03:04:20 PM, Serialize complete at 06/11/2004 03:04:20 PM Content-Type: multipart/alternative; boundary="=_alternative 0068DD4885256EB0_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068DD4885256EB0_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 06/11/2004 01:40:31 PM: > > 1: Component integrity is not always preserved. > > > So you say. EXACTLY HOW? Go reread my previous posts in this thread for citations and examples. I wont repeat them here ad infinitum. > > There has been no justification given for the component-name.* use in > > the SELECT clause. It results in data that is all mushed togther and > > not useable as returned. > > 2: There are "special cases" in CAP that result in different formats > > returning the same data. So far there has been no reason given for > > why we need the special cases really. > > Simply not true. Actually it is true. I have based all my points on actual CAP text and included relevant citations. Please feel free to go and check them for accuracy and make corrections if I missed something. Please show us how removing the BEGIN/END markers so that all properties and subcontainer properties are mixed together in an unusable is _not_ true? One only has to try an actual example to see how useless this is. Try a VEVENT with 3 VALARMs: a display, an email and an audio alarm. The VALARM ATTENDEE, ATTACH, DURATION, DESCRIPTION and SUMMARY properties of each VALARM will be freely mixed in with each others and those of the VEVENT making them inseparable in any meaningful way. I am now strongly inclined to believe that this "component.*" concept is residual from the original SQL query modeling and serves no productive purpose in CAP-QL. Please show us where in CAP it actually defines "*" in the SELECT clause as meaning "all properties and subcontainers" or "all properties and no subcontainers". Please show us where in Section 6.1.1 where it gives an special meaning to "*" on VAGENDAs and VCALSTOREs thats different from other containers. Now that I reread 6.1.1 in greater detal, please show how bullet item 4 in Section 6.1.1 does NOT actually prohibit querying for subcomponents? That is, "SELECT DTSTART,DTEND,VALARM FROM VEVENT WHERE UID = '12345@acme.net'" is illegal by: 4. Everything in the "SELECT" clause and "WHERE" clauses in MUST BE from the same component type, or "VAGENDA" component OR "VCALSTORE" component in the "FROM" clause. My proposal is intended to fix up all these ambiguities and unspecified things so that query behaviour is clear and consistant for all containers. (Actually I just noticed that bullet #4 bit now and didnt address it but I think we should...) 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 0068DD4885256EB0_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 06/11/2004 01:40:31 PM:
> > 1: Component integrity is not always preserved.
>
>
> So you say. EXACTLY HOW?
Go reread my previous posts in this thread for citations and examples.  I wont repeat them here ad infinitum.

> >  There has been no justification given for the component-name.* use in
> > the SELECT clause.  It results in data that is all mushed togther and
> > not useable as returned.
> > 2: There are "special cases" in CAP that result in different formats
> > returning the same data.  So far there has been no reason given for
> > why we need the special cases really.
>
> Simply not true.

Actually it is true.  I have based all my points on actual CAP text and included relevant citations.  Please feel free to go and check them for accuracy and make corrections if I missed something.

Please show us how removing the BEGIN/END markers so that all properties and subcontainer properties are mixed together in an unusable is _not_ true?  One only has to try an actual example to see how useless this is.

Try a VEVENT with 3 VALARMs: a display, an email and an audio alarm.  The VALARM ATTENDEE, ATTACH, DURATION, DESCRIPTION and SUMMARY properties of each VALARM will be freely mixed in with each others and those of the VEVENT making them inseparable in any meaningful way.  I am now strongly inclined to believe that this "component.*" concept is residual from the original SQL query modeling and serves no productive purpose in CAP-QL.

Please show us where in CAP it actually defines "*" in the SELECT clause as meaning "all properties and subcontainers" or "all properties and no subcontainers".

Please show us where in Section 6.1.1 where it gives an special meaning to "*" on VAGENDAs and VCALSTOREs thats different from other containers.

Now that I reread 6.1.1 in greater detal, please show how bullet item 4 in Section 6.1.1 does NOT actually prohibit querying for subcomponents?  That is, "SELECT DTSTART,DTEND,VALARM FROM VEVENT WHERE UID = '12345@acme.net'" is illegal by:

   4.  Everything in the "SELECT" clause and "WHERE" clauses in MUST BE
       from the same component type, or "VAGENDA" component OR
       "VCALSTORE" component in the "FROM" clause.
 
My proposal is intended to fix up all these ambiguities and unspecified things so that query behaviour is clear and consistant for all containers.  (Actually I just noticed that bullet #4 bit now and didnt address it but I think we should...)

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 0068DD4885256EB0_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 11 16:18: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 QAA29706 for ; Fri, 11 Jun 2004 16:18:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5BK4oSp072636; Fri, 11 Jun 2004 13:04:50 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5BK4oUq072635; Fri, 11 Jun 2004 13:04:50 -0700 (PDT) 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.11/8.12.9) with ESMTP id i5BK4ncY072619 for ; Fri, 11 Jun 2004 13:04:49 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i5BK4hMn032225 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 11 Jun 2004 13:04:45 -0700 Message-ID: <40CA105B.6060008@Royer.com> Date: Fri, 11 Jun 2004 14:04:43 -0600 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 13: Bad CAL-QUERY example / description? References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020308090700060501010000" 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. --------------ms020308090700060501010000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug responded on 06/11/2004 01:40:31 PM: > > > 1: Component integrity is not always preserved. > > > > > > So you say. EXACTLY HOW? > > Go reread my previous posts in this thread for citations and examples. > I wont repeat them here ad infinitum. I consider this thread closed. I see no new points raised and I have not been convinced that it is any more than a disire to get something changed that you do not like. You have said that you and your company are not implemeting CAP, has that changed? Everyone that I personally know that is impleminting CAP have proposed no changes in this area. We seem to be able to parse it and implment it. There is at least one company that is (or soon will be) shipping a CAP product based on the drafts, yet they can make it work. I do not see this as a technical problem with the spec. The missing ABNF will be fixed, other than that it seems to work. -- 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 --------------ms020308090700060501010000 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 9w0BCQUxDxcNMDQwNjExMjAwNDQzWjAjBgkqhkiG9w0BCQQxFgQUkAIf5ylb9sCYuG3/9Jrb k7QkQjswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEABQex8e730Q4hV5Wdxml/wEYYocq8mzuXfBbWjXuZwAHZivGgsDbk3SMd9j+mfJMb acQPysBOraAxQ4nv4tEKNoLZ/YW9XiWy76XCts1E2iC5gjYLCPQH0rOe0d+JZN2K5GCHo3qT dEEGxHPoF79PLaVrCs5gsOgrU9L1xGCi0r8OgbUimauckljJOmrZj2ywTfyHtcdMqcKC3uDa gVSie6E1Bn49ENR9QlWBnAKp9OlTxdMLfb9kF9xhOQA40KaBKq444YGw4Ve3jR+Gui6sDgS+ 8MRrY9Q7mHMgk4b60xFDb4VcOi9gGCPXFDobiwKLdmRbQ9wlrQJr9W/ywfgakQAAAAAAAA== --------------ms020308090700060501010000-- From owner-ietf-calendar@mail.imc.org Mon Jun 14 12:22:14 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 MAA12788 for ; Mon, 14 Jun 2004 12:22:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EG82LT057809; Mon, 14 Jun 2004 09:08:02 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5EG82od057808; Mon, 14 Jun 2004 09:08:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5EG81TY057797 for ; Mon, 14 Jun 2004 09:08:01 -0700 (PDT) (envelope-from hardie@qualcomm.com) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5EG7s3T017727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jun 2004 09:07:55 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i5EG7mo4025665; Mon, 14 Jun 2004 09:07:48 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <40CA105B.6060008@Royer.com> References: <40CA105B.6060008@Royer.com> Date: Mon, 14 Jun 2004 09:07:53 -0700 To: ietf-calendar@imc.org From: Ted Hardie Subject: Re: CAP 13: Bad CAL-QUERY example / description? Cc: Doug Royer , Bruce_Kahn@notesdev.ibm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Given the discussion on these points, I believe it would be appropriate to have the chairs make the determination that the issues raised have been resolved. Until the chairs declare the issue closed, I believe it should remain open, so that others may comment. I encourage others to comment on the issues raised and the proposed resolution. Please also note that one is not required to implement a specificaiton to be an effective reviewer; in my own experience, folks who are not steeped in the code often find both doc bugs and assumption issues that those who are steeped in the code miss. regards, Ted Hardie co-Area Director, Applications At 2:04 PM -0600 6/11/04, Doug Royer wrote: >Bruce_Kahn@notesdev.ibm.com wrote: > >> >>Doug responded on 06/11/2004 01:40:31 PM: >>> > 1: Component integrity is not always preserved. >>> >>> >>> So you say. EXACTLY HOW? >> >>Go reread my previous posts in this thread for citations and >>examples. I wont repeat them here ad infinitum. > >I consider this thread closed. I see no new points raised and I have >not been convinced that it is any >more than a disire to get something changed that you do not like. >You have said that you and your >company are not implemeting CAP, has that changed? Everyone that I >personally know that >is impleminting CAP have proposed no changes in this area. We seem >to be able to parse >it and implment it. There is at least one company that is (or soon >will be) shipping a CAP >product based on the drafts, yet they can make it work. I do not see >this as a technical >problem with the spec. The missing ABNF will be fixed, other than >that it seems to work. > >-- > >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 > > > >Content-Type: application/x-pkcs7-signature; name="smime.p7s" >Content-Disposition: attachment; filename="smime.p7s" >Content-Description: S/MIME Cryptographic Signature > >Attachment converted: Macintosh HD:smime 193.p7s ( / ) (0017ED25) From owner-ietf-calendar@mail.imc.org Wed Jun 16 19:43:20 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 TAA01701 for ; Wed, 16 Jun 2004 19:43:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GNS1kn086905; Wed, 16 Jun 2004 16:28:01 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5GNS1hn086904; Wed, 16 Jun 2004 16:28:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5GNS09l086885 for ; Wed, 16 Jun 2004 16:28:00 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5GNRwBu002899 for ; Wed, 16 Jun 2004 16:28:03 -0700 Received: from D-140-142-21-3.dhcp4.washington.edu (D-140-142-21-3.dhcp4.washington.edu [140.142.21.3]) (authenticated bits=0) by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5GNRwJ2017119 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 16 Jun 2004 16:27:58 -0700 Date: Wed, 16 Jun 2004 16:27:49 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: "ietf-calendar@imc.org" Subject: Re: CAP 13: Bad CAL-QUERY example / description? In-Reply-To: <40CA105B.6060008@Royer.com> Message-ID: References: <40CA105B.6060008@Royer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As Ted points out, when an issue is contentious it is the chairs who will declare closure after seeking consensus. I think the reasonable interpretation of Doug's comment is that he sees no consensus to change the document at this time based on Bruce's comments. The chairs are inclined to agree with that view, even though we understand Bruce's points. If no other implementors (or other reviewers) are prepared to support the position that these constructs need to be changed or removed, then they will stand as written, at least for purposes of producing a last-callable CAP document; so please comment *now* if you want to see changes. We are inclined to think that the discussion indicates a need for actual response data along with the example queries in this section, to clarify what the response is supposed to be (and maybe support the "mush" point of view). But we won't ask the editor to make that change unless others also think it would be useful. - RL "Bob" and Pat From owner-ietf-calendar@mail.imc.org Fri Jun 18 04:41:54 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 EAA06657 for ; Fri, 18 Jun 2004 04:41:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I8FaES089844; Fri, 18 Jun 2004 01:15:36 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5I8Fa4X089843; Fri, 18 Jun 2004 01:15:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mid-2.inet.it (mid-2.inet.it [213.92.5.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5I8FYTR089767 for ; Fri, 18 Jun 2004 01:15:34 -0700 (PDT) (envelope-from harrie@inet.it) Received: from hhazewinkel.inet.it [::ffff:213.92.1.191] by mid-2.inet.it via I-SMTP-4.8.4-483 id ::ffff:213.92.1.191+yh0JVsCGEsTp; Fri, 18 Jun 2004 10:15:26 +0200 Message-ID: <40D29FBF.4070003@inet.it> Date: Fri, 18 Jun 2004 09:54:39 +0200 From: Harrie Hazewinkel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: CAP 13: Bad CAL-QUERY example / description? References: <40C0DA70.6070701@Royer.com> In-Reply-To: <40C0DA70.6070701@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: > > >> >> It may be useful for doing a "find me all properties and subcomponents >> that exist in this container" but I strongly doubt that its something >> done on a regular basis. It can be useful for debugging or protoyping >> purposes but not for normal CU day to day actions. > > > It is used every time I load a calendar from an unknown source. One > vendor has > two modes it uses timezones and both with the same PRODID. Not all > properties are in all objects > even when they are the same type. This looks like, virtual hosting. I start wondering and thinking of the need for this. This can be done with the VCALSTORE or the hostpart in the CALID. I think it is dangerous to use for instance a timezone in order to choose a different set of features. In the long-term this is not providing inter-operability, but non inter-operability. Maybe it could be wise to make a draft for this (or include it). > > The feature is documented. And works. And even if you do not want to use > the feature > it appears from this conversation that you did understand from CAP > what that > feature does when called. So it does not fall into the bug, broken, > typo, or grammer category. > And I thought that feature changes were off topic and we were into get > CAP done mode. > Understanding the draft well, I believe a GET-CAPABILITY could be used for this. Although, modifications are needed. It may also be useful, to indicate which properties are required by the CS for instance. An example discovered by trying to synchronize a telephone with a CAP server (telephone <-SYNCML-> syncserver <-CAP-> CAP server). The telephone does not support the UID property, but implicitly expresses it be some other means outside the VEVENT. This is sufficient for the communication between the telephone and sync server. While transfering the VEVENT to the CAP server it refused the new VEVENT due to the missing UID property. I have no real way of learning this in the sync server. Asking for a complete list of supported properties is not the same, since it does not tell me if it is required. For this example one can say, "but the UID property is required by the protocol definition". Yes, I agree, but it is applicable for other properties. Harrie From owner-ietf-calendar@mail.imc.org Fri Jun 18 10:35:19 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 KAA27664 for ; Fri, 18 Jun 2004 10:35:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IEJ6Ym000540; Fri, 18 Jun 2004 07:19:06 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5IEJ6gp000539; Fri, 18 Jun 2004 07:19:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5IEJ5iH000518 for ; Fri, 18 Jun 2004 07:19:05 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i5IEIwMn024574 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 18 Jun 2004 07:19:00 -0700 Message-ID: <40D2F9D1.2080502@Royer.com> Date: Fri, 18 Jun 2004 08:18:57 -0600 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 13: Bad CAL-QUERY example / description? References: <40C0DA70.6070701@Royer.com> <40D29FBF.4070003@inet.it> In-Reply-To: <40D29FBF.4070003@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030609020008060006000305" 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. --------------ms030609020008060006000305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Harrie Hazewinkel wrote: > > Doug Royer wrote: > >> >> >>> >>> It may be useful for doing a "find me all properties and >>> subcomponents that exist in this container" but I strongly doubt >>> that its something done on a regular basis. It can be useful for >>> debugging or protoyping purposes but not for normal CU day to day >>> actions. >> >> >> >> It is used every time I load a calendar from an unknown source. One >> vendor has >> two modes it uses timezones and both with the same PRODID. Not all >> properties are in all objects >> even when they are the same type. > > > This looks like, virtual hosting. No. It has nothing to do with virtual hosting. It has to do with not all implementations comply with the RFC's. The time zone text was just one example. -- 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 --------------ms030609020008060006000305 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 9w0BCQUxDxcNMDQwNjE4MTQxODU3WjAjBgkqhkiG9w0BCQQxFgQUij23bcrgJHJZcZsZagwT 4Z3oNTQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEALHc4rgUeGRVvYrprht0AuSuDXySZb8XvMQHPBDfiwlQGeeavuqKpYJVOwPDJXcZK jfGwKucPQDouNHz2raLXv7JQbLARF3mUFmRbU3A7tsF6xINCYvDbFzrWXikQwwDXs/ikeMBK YiRuwTv19N1Mtac9GYeAZ9O/Zv0/Rjzrv7KNZQ9ki3VjaFQBY22Q0/tK5ZCdCtvRnAeIADrd 4IwqouAPUCuhlSklDKvw3pS/U9q+VGV68euz7y1EQ2tFxo4QlI1uAQIzGVqW2mU1c+z8C0MY 5lhLs/T14rNVj5xyQKlQN0X7cl/82rWmYGeNyAlLKh6TiDFBMv1LsYSkXkjHQwAAAAAAAA== --------------ms030609020008060006000305-- From owner-ietf-calendar@mail.imc.org Wed Jun 23 16:23:49 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 QAA13771 for ; Wed, 23 Jun 2004 16:23:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NK3W20067264; Wed, 23 Jun 2004 13:03:32 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NK3WAC067263; Wed, 23 Jun 2004 13:03:32 -0700 (PDT) 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.11/8.12.9) with ESMTP id i5NK3VEf067220 for ; Wed, 23 Jun 2004 13:03:31 -0700 (PDT) (envelope-from Doug@Royer.com) Received: from Royer.com (doug@69-20-163-158.ida.net [69.20.163.158]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i5NK3NMn019211 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 23 Jun 2004 13:03:25 -0700 Message-ID: <40D9E20B.4060203@Royer.com> Date: Wed, 23 Jun 2004 14:03:23 -0600 From: Doug Royer 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" , "ietf-calendar@imc.org" Subject: CALSCH at IETF Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080307050200050504040608" 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. --------------ms080307050200050504040608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit CALSCH is not on the draft agenda. Are we meeting? -- 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 --------------ms080307050200050504040608 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 9w0BCQUxDxcNMDQwNjIzMjAwMzIzWjAjBgkqhkiG9w0BCQQxFgQUtctUTf4szTOMpyyDFmVn 6OiNKo0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQMf+ObfuD fLv1v9fKUzQUwjCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEDH/jm37g3y79b/XylM0FMIwDQYJKoZIhvcNAQEB BQAEggEAk2VDNdfrmM20UR6T6/CYDBokgzjG7Q97toxSMFMLLbwCVIkH9//+EW5CY+ImF3Dz PbbvB+pBhK36OFgSJCiLNqvBLzf2/Y0QIyodFdH9f/g65rcJhcygroKMAKcwM0pR/KbkZxm9 2wehT55ds/gM/CijWcltFa2bXeAqUUHRpVZDx1pMJIokHvJVwXHq/hXM1+abQRZmi6JxQSzR nnP0D3Ox1zkKFftcsa+APx7VpczNYBYPcqaPdOg1lvAstffsx7H5sONW7Q0Mmj16CYIekgTc UneXXOyJCJBJMH1CjOjvUXzT7oahnvVfILzyf3rl8L/9d+vLJ26n/RvWz2BqCwAAAAAAAA== --------------ms080307050200050504040608-- From owner-ietf-calendar@mail.imc.org Wed Jun 23 16:50:19 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 QAA16479 for ; Wed, 23 Jun 2004 16:50:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKZHd3073167; Wed, 23 Jun 2004 13:35:17 -0700 (PDT) (envelope-from owner-ietf-calendar@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i5NKZHqE073166; Wed, 23 Jun 2004 13:35:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-calendar@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5NKZHCi073159 for ; Wed, 23 Jun 2004 13:35:17 -0700 (PDT) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5NKZ8DU013692; Wed, 23 Jun 2004 13:35:13 -0700 Received: from D-140-142-21-14.dhcp4.washington.edu (D-140-142-21-14.dhcp4.washington.edu [140.142.21.14]) (authenticated bits=0) by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i5NKZ8nc018294 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 23 Jun 2004 13:35:08 -0700 Date: Wed, 23 Jun 2004 13:35:00 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perp.cac.washington.edu To: Doug Royer cc: "ietf-calendar@imc.org" Subject: Re: CALSCH at IETF In-Reply-To: <40D9E20B.4060203@Royer.com> Message-ID: References: <40D9E20B.4060203@Royer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > CALSCH is not on the draft agenda. Are we meeting? Yes, I'll be putting the request in shortly. - RL "Bob"