From owner-ietf-calendar@mail.imc.org Wed Oct 2 15:52:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05653 for ; Wed, 2 Oct 2002 15:52:43 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g92JfBd10211 for ietf-calendar-bks; Wed, 2 Oct 2002 12:41:11 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g92Jf2v10207 for ; Wed, 2 Oct 2002 12:41:08 -0700 (PDT) In-Reply-To: <7558294D-CC00-11D6-8F78-003065A8EEFC@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: Revised proposal MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Oct 2002 15:40:55 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/02/2002 03:35:03 PM, Serialize complete at 10/02/2002 03:35:03 PM Content-Type: multipart/alternative; boundary="=_alternative 006C50CA85256C46_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C50CA85256C46_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 09/19/2002 02:48:59 PM: > I simply added: we may want to leave: the CS MUST support > GET-CAPABILITY, the CUA MAY. Im with Doug on this and think that it MUST for both is probably the best thing to do. Its not that a burden on a CUA coder to do it and it may actually be useful/necessary as CAP develops/expands. A good example why MUST is best: CUA1 puts a very robust entry (ie:ATTACHments and ALTREPs galore) into the calendar. The CS is multiparty savy and saves the data as given. The CU uses a different CUA (or a 'newer' CUA or 'evaluation trys' or...) to retrieve their data. If the CS blindly sends back the multipart data to the CUA that cannot handle multipart data (ie: no ALTREPs or non-inlined ATTACHments) then the CUA may have big problems that prevent the CU from correctly seeing their existing data. 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 006C50CA85256C46_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 09/19/2002 02:48:59 PM:
> I simply added: we may want to leave: the CS MUST support
> GET-CAPABILITY, the CUA MAY.
Im with Doug on this and think that it MUST for both is probably the best thing to do.  Its not that a burden on a CUA coder to do it and it may actually be useful/necessary as CAP develops/expands.

A good example why MUST is best:
CUA1 puts a very robust entry (ie:ATTACHments and ALTREPs galore) into the calendar.  The CS is multiparty savy and saves the data as given.  The CU uses a different CUA (or a 'newer' CUA or 'evaluation trys' or...) to retrieve their data.  If the CS blindly sends back the multipart data to the CUA that cannot handle multipart data (ie: no ALTREPs or non-inlined ATTACHments) then the CUA may have big problems that prevent the CU from correctly seeing their existing data.

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 006C50CA85256C46_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 2 16:15:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06453 for ; Wed, 2 Oct 2002 16:15:22 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g92JwpU12061 for ietf-calendar-bks; Wed, 2 Oct 2002 12:58:51 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g92Jwov12055 for ; Wed, 2 Oct 2002 12:58:50 -0700 (PDT) In-Reply-To: <3D85DFF1.6C586A37@oracle.com> To: George Babics Cc: ietf-calendar@imc.org Subject: Re: Proposal about multipart etc MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 2 Oct 2002 15:58:40 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/02/2002 03:52:43 PM, Serialize complete at 10/02/2002 03:52:43 PM Content-Type: multipart/alternative; boundary="=_alternative 006DF0D985256C46_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006DF0D985256C46_= Content-Type: text/plain; charset="US-ASCII" George replied on 09/16/2002 09:43:13 AM: > I know we have no such protocol. My point is that shouldn't the > CUA be able to see the event (except for the attachment) even > though the attachment is too big for it? There are some possible courses of action for the CUA to take if it gets a failure response from the CS. One it to rerequest w/o SELECTing the ATTACHments. This is not 100% guaranteed since the cause may be the ALTREPs rather than just the ATTACHments. We have no means to request no multipart data even if the CUA supports it because the entry exceedes the CUAs max size but that wont solve the case 100% either. It could be that a different CUA w/a larger capacity created the entry and as such we have no clear course of action for the 'smaller' CUA to take short of taking 'shots in the dark' about what to not request. If we distinguished between the max iCalendar object size, max ATTACHment size (in total??) and max 'external' size (ie: all mulitipart body parts outside the iCalendar object) then that gives us a finer grain of control but it still wont solve the "my buffer is bigger than yours" issues. We should codify some reasonable behaviours for CUAs to take when encountering this since we did create the concept of the limiting size. Do you have any suggestions on how to deal w/this? > It may not even depend much on the implementation and how much the > owner pays for bandwidth. It will depend much on usage. Id change that last line to be "It will depend much on users." since the CUs are the ones creating the entries. Some folks consistanly put in lots more than others; kind of like email responses chains or discussions. > Most events will > probably have a SUMMARY, a DTSTART, a DTEND/DURATION, a LOCATION, two or > three attendees, an ORGANIZER, a UID, a VERSION, a PRODID, and not much more. Well, minimally you will need what you listed (perhaps omitting LOCATION and ATTENDEEs if you are doing a non-workflow 'Appointment'). However in ~5 years of having to look at folks calendars here to see why something didnt look right in their calendar or in the busytime system Ive seen entries all over the spectrum with no real common size or usage (usage being whats in properties like DESCRIPTION, etc). A REQUEST to the mailing list members would have over 300 (400??) ATTENDEE properties alone and each could be longer than a single line if property parameters like CN, ROLE, RSVP, PART-STAT and others are included. No ATTTACHments, just lots of data... > How many bytes can that be? Not very much. However, once you add a huge > attachment to the event, the CU will not be able to see it, if its CUA has > limits to the sizes of objects. Its not just a factor of large ATTACHments, its possible to have a very large entry w/o any ATTACHments or ALTREPs. Try creating an "All Hands Meeting" entry for Oracle (or just your division) and see how big it gets... 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 006DF0D985256C46_= Content-Type: text/html; charset="US-ASCII"
George replied on 09/16/2002 09:43:13 AM:
> I know we have no such protocol. My point is that shouldn't the
> CUA be able to see the event (except for the attachment) even
> though the attachment is too big for it?
There are some possible courses of action for the CUA to take if it gets a failure response from the CS.  One it to rerequest w/o SELECTing the ATTACHments.  This is not 100% guaranteed since the cause may be the ALTREPs rather than just the ATTACHments.   We have no means to request no multipart data even if the CUA supports it because the entry exceedes the CUAs max size but that wont solve the case 100% either.  It could be that a different CUA w/a larger capacity created the entry and as such we have no clear course of action for the 'smaller' CUA to take short of taking 'shots in the dark' about what to not request.

If we distinguished between the max iCalendar object size, max ATTACHment size (in total??) and max 'external' size (ie: all mulitipart body parts outside the iCalendar object) then that gives us a finer grain of control but it still wont solve the "my buffer is bigger than yours" issues.  We should codify some reasonable behaviours for CUAs to take when encountering this since we did create the concept of the limiting size.

Do you have any suggestions on how to deal w/this?

>   It may not even depend much on the implementation and how much the
> owner pays for bandwidth. It will depend much on usage.

Id change that last line to be "It will depend much on users." since the CUs are the ones creating the entries.  Some folks consistanly put in lots more than others; kind of like email responses chains or discussions.

>                                                          Most events will
> probably have a SUMMARY, a DTSTART, a DTEND/DURATION, a LOCATION, two or
> three attendees, an ORGANIZER, a UID, a VERSION, a PRODID, and not much more.
Well, minimally you will need what you listed (perhaps omitting LOCATION and ATTENDEEs if you are doing a non-workflow 'Appointment').  However in ~5 years of having to look at folks calendars here to see why something didnt look right in their calendar or in the busytime system Ive seen entries all over the spectrum with no real common size or usage (usage being whats in properties like DESCRIPTION, etc).

A REQUEST to the mailing list members would have over 300 (400??) ATTENDEE properties alone and each could be longer than a single line if property parameters like CN, ROLE, RSVP, PART-STAT and others are included.  No ATTTACHments, just lots of data...

> How many bytes can that be? Not very much. However, once you add a huge
> attachment to the event, the CU will not be able to see it, if its CUA has
> limits to the sizes of objects.
Its not just a factor of large ATTACHments, its possible to have a very large entry w/o any ATTACHments or ALTREPs.  Try creating an "All Hands Meeting" entry for Oracle (or just your division) and see how big it gets...

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 006DF0D985256C46_=-- From owner-ietf-calendar@mail.imc.org Thu Oct 3 05:59:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00404 for ; Thu, 3 Oct 2002 05:59:45 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g939qE413937 for ietf-calendar-bks; Thu, 3 Oct 2002 02:52:14 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g939qDv13933 for ; Thu, 3 Oct 2002 02:52:13 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 6F6011556C; Thu, 3 Oct 2002 11:52:12 +0200 (CEST) Date: Thu, 3 Oct 2002 11:52:12 +0200 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: George Babics , ietf-calendar@imc.org Subject: Re: Proposal about multipart etc Message-ID: <20021003095212.GJ55771@inet.it> References: <3D85DFF1.6C586A37@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 02, 2002 at 03:58:40PM -0400, Bruce_Kahn@notesdev.ibm.com wrote: > ALTREPs rather than just the ATTACHments. We have no means to request no > multipart data even if the CUA supports it because the entry exceedes the > CUAs max size but that wont solve the case 100% either. It could be that [...] > > Do you have any suggestions on how to deal w/this? One way would be adding a new value for OPTIONS, such that if the first SEARCH failed, the CUA can retry with something like: CMD;OPTIONS=STRIP:SEARCH Which really means "ok, give me only the the absolute minimum to satisfy the CU". Not that I advocate this, it's just one possible solution... Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Oct 3 06:05:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00501 for ; Thu, 3 Oct 2002 06:05:39 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g939xjL14934 for ietf-calendar-bks; Thu, 3 Oct 2002 02:59:45 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g939xiv14927 for ; Thu, 3 Oct 2002 02:59:45 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id C8BF61556C; Thu, 3 Oct 2002 11:59:44 +0200 (CEST) Date: Thu, 3 Oct 2002 11:59:44 +0200 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: Revised proposal Message-ID: <20021003095944.GK55771@inet.it> References: <7558294D-CC00-11D6-8F78-003065A8EEFC@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Oct 02, 2002 at 03:40:55PM -0400, Bruce_Kahn@notesdev.ibm.com wrote: > Andrea wrote on 09/19/2002 02:48:59 PM: > > I simply added: we may want to leave: the CS MUST support > > GET-CAPABILITY, the CUA MAY. > Im with Doug on this and think that it MUST for both is probably the best > thing to do. Its not that a burden on a CUA coder to do it and it may > actually be useful/necessary as CAP develops/expands. Agreed, it's not that a burder on the programmer, but it would be a waste of time in a scenario like I descrived (CGI interface). Anyway, as I said: I will go with the majority. > A good example why MUST is best: > CUA1 puts a very robust entry (ie:ATTACHments and ALTREPs galore) into the > calendar. The CS is multiparty savy and saves the data as given. The CU > uses a different CUA (or a 'newer' CUA or 'evaluation trys' or...) to > retrieve their data. If the CS blindly sends back the multipart data to > the CUA that cannot handle multipart data (ie: no ALTREPs or non-inlined > ATTACHments) then the CUA may have big problems that prevent the CU from > correctly seeing their existing data. Sorry but I don't get it. We have agreed that the CS and the CUA must negotiate multipart capabilities, right? I was merely proposed that, if a CS sends a GET-CAPABILITY to the CUA and it gets back an error, it MUST assume all capabilities are default - which for multipart happens to be "no multipart". In your example, the CS can't blindly send back the multipart data, because the new CUA told it it doesn't support it - it doesn't matter whether it told it explicitely (by replying to GET-CAPABILITY) or implicitely (by not replying). Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Oct 10 18:58:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26479 for ; Thu, 10 Oct 2002 18:58:20 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9AMjg411496 for ietf-calendar-bks; Thu, 10 Oct 2002 15:45:42 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9AMjfv11492 for ; Thu, 10 Oct 2002 15:45:41 -0700 (PDT) Received: from [216.126.164.111] (09-034.089.popsite.net [66.19.2.34]) by mail1.panix.com (Postfix) with ESMTP id B494B487AC for ; Thu, 10 Oct 2002 17:46:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: gmcgath@popserver.panix.com (Unverified) Message-Id: Date: Thu, 10 Oct 2002 17:45:47 -0400 To: ietf-calendar@imc.org From: Gary McGath Subject: Linked calendars Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: How should links between different calendars be handled in RFC 2445? The scenario which I have in mind is one in which one calendar provides an overview, perhaps a list of conferences for the upcoming year, and other documents, which may be independently maintained, provided detailed information for each of these conferences. A conference would be a single VEVENT in the overview calendar, but would be broken out in detail in the referenced conference's calendar. Is this an appropriate usage for the "RELATED-TO" property of the VEVENT in the overview calendar? Since a UID is globally unique, this would be semantically valid, but there isn't any general way to locate the object to which the UID refers if it's buried in the middle of somebody else's calendar. Alternatively, the "URL" property could be used to point at the detailed calendar, but the format of the resource which the URL points to is undefined. Software following URL links could, of course, check if the link finds a valid iCalendar document (and should anyway, just on general principles). Is one of these, or something else which I may have overlooked, an recommended way to handle linked calendars? -- Gary McGath, Software Consultant http://www.mcgath.com/consulting/ From owner-ietf-calendar@mail.imc.org Thu Oct 10 20:08:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27197 for ; Thu, 10 Oct 2002 20:08:31 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9B01PM13919 for ietf-calendar-bks; Thu, 10 Oct 2002 17:01:25 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9B01Nv13915 for ; Thu, 10 Oct 2002 17:01:23 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9B01PHC001263; Thu, 10 Oct 2002 17:01:25 -0700 Message-ID: <3DA6115E.8090009@Royer.com> Date: Thu, 10 Oct 2002 17:46:38 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Linked calendars References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060909040102090102010803" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060909040102090102010803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Both a "UID" and "RELATED-TO" are vendor specific text values. So far we have not addressed this issue. And it is independent of CAP (the current and warmest topic on this list). I would go for using a CAL-ADDRESS (CAP or MAILTO URL) in the "RELATED-TO" property value. The "URL" property is used to point to a URL for the containing object and I think that "RELATED-TO" would be more appropriate. One of the reasons that this issue has not be solved here is that is starts up a debate about "fan out". For example, what if something changes in one of the related calendars? How is propagation handled? How is any notification handled? What if two related calendars each change their time independently - to the same time? So "fan out" was going to be discussed at a later time. It would be interesting to see if others (Bruce :) have used the "RELATED-TO" property for this reason. Gary McGath wrote: > > How should links between different calendars be handled in RFC 2445? The > scenario which I have in mind is one in which one calendar provides an > overview, perhaps a list of conferences for the upcoming year, and other > documents, which may be independently maintained, provided detailed > information for each of these conferences. A conference would be a > single VEVENT in the overview calendar, but would be broken out in > detail in the referenced conference's calendar. > > Is this an appropriate usage for the "RELATED-TO" property of the VEVENT > in the overview calendar? Since a UID is globally unique, this would be > semantically valid, but there isn't any general way to locate the object > to which the UID refers if it's buried in the middle of somebody else's > calendar. > > Alternatively, the "URL" property could be used to point at the detailed > calendar, but the format of the resource which the URL points to is > undefined. Software following URL links could, of course, check if the > link finds a valid iCalendar document (and should anyway, just on > general principles). > > Is one of these, or something else which I may have overlooked, an > recommended way to handle linked calendars? -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms060909040102090102010803 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAxMDIzNDYzOFowIwYJKoZIhvcNAQkEMRYEFGWW08xH BgjtHVwfjrb7vIxgbd96MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAnLC8e2PTO0kT1uYeF iKBp3LVlLvxDJ3JDT0eea0taMHKoCY7Qvm5QHiq5lV5OUURztCyqIdML63oSu8VX5FQ+7miw 7Vxo8C3uE9WjWelhIOj2pf7LMSYVhOB3BS6E+XvBAMC3C/w8hlVH1chiHq50XVQ5AJv7kGYk hJg02Fbqbm8m53sEUinMpXNJNrWFlooa3fKvliacI++J3FY2s/XD+5Rb62D60ztAi1W7kiVJ oXxas7LqU3JoyJkrWy1Heq2m0tXwMxO4sOZJ98LUx31iLjbQEso+RjePanr0MgC7SU1mphge HrANgTfT+99LWBbX2ap+Uis3ZX7ISm0QeHnvAAAAAAAA --------------ms060909040102090102010803-- From owner-ietf-calendar@mail.imc.org Sun Oct 13 20:42:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26670 for ; Sun, 13 Oct 2002 20:42:41 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9E0Qsd26632 for ietf-calendar-bks; Sun, 13 Oct 2002 17:26:54 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9E0Qrv26628 for ; Sun, 13 Oct 2002 17:26:53 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9E0QZHC018529 for ; Sun, 13 Oct 2002 17:26:45 -0700 Message-ID: <3DAA0BC2.1060100@Royer.com> Date: Sun, 13 Oct 2002 18:11:46 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: COUNTER - and who sent it. Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050409010903030908070309" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050409010903030908070309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In preparation for updating CAP, I ran across this message. Unless there is some objection, I'll add it to CAP. The issue is that there would be no way to know who sent the COUNTER method once stored in the CS so that a possible DECLINE-COUNTER could be sent at a later time. A CUA that processes iMIP or CUA originated COUNTER objects MUST add the ATT-COUNTER PROPERTY to any COUNTER objects that are stored in the CS. For iMIP messages, the CUA MUST put the originators e-mail address as the value to the ATT-COUNTER property. And all CUAs MUST add the users CAL-ADDRESS (which might be the CUs e-mail address) to the ATT-COUNTER property. -Doug * From: Frank_Dawson@lotus.com * Date: Tue, 29 Aug 2000 11:33:12 -0400 Folks: I have thought about this some more. I think that the proposal to add an ATT-COUNTER parameter to the ATTENDEE property present backwards compatibility with iCalendar RFC2445 products. An alternative proposal would be to have an ATT-COUNTER property, instead. If we think about what this semantic means, it is similar to the ORGANIZER property. The attendee making the COUNTER proposal is effectively proposing a new event, similar to a tentative invitation proposal. As such, I believe that you all would agree that making this a property, instead of an ATTENDEE property parameter is a better design approach. For backwards compatibility, a RFC2445 compatible parser is supposed to skip any unrecognized properties, as these may have been IANA registered extensions anyway. Don't you all agree? -- Frank -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms050409010903030908070309 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAxNDAwMTE0NlowIwYJKoZIhvcNAQkEMRYEFCXjJH/X NH7HK0BN8h0Z9MxyZ4XXMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQA+wghAsFNzG2+liez6 FFdDsCYm89Ir2BsPrb6tYBO0b4aRxLKWh5NdOxOt0+Fy51ncykSC4d8JG0PVR3HUXvs/4SBp pikCqzNEXhs7l+ImDCuaP668N7T6XEJqCaw0DCpkjQ/XQ2IebJ0VIORFL/CXEAEo0hy58FBr HhfJXvqDJpr3oVtAghI9KoiA0rvKvoQHPiBuaUJDg4X1C8/IePj3prYw1F9pY4U4QOUrMxGu 43IABy5P94PavvzwRhRPc/HdWZAnA7+IqyDtBk7XqOeNUDN6bVEQRYVU2PAenG86A/eEHD0/ fldmlhtuQRWGseVe55Svm+ygFVReYZMGgKllAAAAAAAA --------------ms050409010903030908070309-- From owner-ietf-calendar@mail.imc.org Mon Oct 14 18:18:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04082 for ; Mon, 14 Oct 2002 18:18:41 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9ELuak10970 for ietf-calendar-bks; Mon, 14 Oct 2002 14:56:36 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9ELuZW10966 for ; Mon, 14 Oct 2002 14:56:35 -0700 (PDT) Received: from 216.126.165.80 (06-080.089.popsite.net [216.126.165.80]) by mail1.panix.com (Postfix) with ESMTP id 39C0648AAC; Mon, 14 Oct 2002 17:56:36 -0400 (EDT) Date: Mon, 14 Oct 2002 17:55:01 -0400 From: Gary McGath Subject: Sosigenes 1.0P3 To: RDF Calendar List , ICalendar list X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.4 (Blindsider) Demo Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A new update (version 1.0P3) of Sosigenes, my open-source Java package for accessing XML-formatted iCalendar documents, is now available. Source, Jar file, Javadoc and release notes are available at . This is still a "preview" release, but people are encouraged to look it over and try it out. Comments are always welcome. Gary McGath http://www.mcgath.com From owner-ietf-calendar@mail.imc.org Sun Oct 20 17:17:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03270 for ; Sun, 20 Oct 2002 17:17:37 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9KL1WY08673 for ietf-calendar-bks; Sun, 20 Oct 2002 14:01:32 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9KL1UW08669 for ; Sun, 20 Oct 2002 14:01:31 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9KL1KqN009834; Sun, 20 Oct 2002 14:01:20 -0700 Message-ID: <3DB3199D.3030206@Royer.com> Date: Sun, 20 Oct 2002 15:01:17 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Diffs - ftp://royer.com/pub/CALSCH/cap.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090607080903060004050803" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090607080903060004050803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have edited several changes into CAP. Mostly fixing the quoting and capitalization. Plus some of the minor changes that have been discussed on the net. After this, I am starting to modify CAP as noted on this WG list. The -b rev of 09 is at (Note -09 is not yet pushed, -09b was the last published on the WG list only): http://inet-consulting.com/cap-09-b.txt The current changes in context diff format are at: http://inet-consulting.com/cap-09-b-diffs.txt And as it currently looks (cap-09-b.txt + diffs): http://inet-consulting.com/cap-09-b-1.txt --->> More changes on the way... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms090607080903060004050803 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMDIxMDExN1owIwYJKoZIhvcNAQkEMRYEFMcDr6Yq 1eqdOpc926nOH13bMjzcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB10BTj6V0c1WudGhWh K4xvRZY5mQ+ptMAsaBnW3XLufLslvGqd0fBITW0daN2YJNp4tkYHS53gECG/QqWLJDElTj4a KJCjWG6MtD7KldnTdj8WFosDTNxAPdb6GzggYVIAoNX1QvnF6GSZiTuF2185wNJJTQ3h/hNi Y/xFEpqZsP8ubNZ8A6OTXwBaayyDKti+6YXXp0CIXSpFcE5MXBwz8eWol/HFitETKw7SUFYg eims43r1ZvpHGmk/M2jwJ43eXP2nQ90rDGvYZb2X5/7qK8UxaUOHkr4YBJh7rje7NLhh7KvY Qg7s4n2GKLn0iSCtdK3VKTepN9M0ddu+pawGAAAAAAAA --------------ms090607080903060004050803-- From owner-ietf-calendar@mail.imc.org Sun Oct 20 20:48:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05492 for ; Sun, 20 Oct 2002 20:48:26 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9L0er017704 for ietf-calendar-bks; Sun, 20 Oct 2002 17:40:53 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9L0epW17700 for ; Sun, 20 Oct 2002 17:40:51 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9L0erqN011242 for ; Sun, 20 Oct 2002 17:40:53 -0700 Message-ID: <3DB34D12.90109@Royer.com> Date: Sun, 20 Oct 2002 18:40:50 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Updated CAL-QUERY Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030408020404080906040901" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030408020404080906040901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I added cap-val and included the 'PARAM()' call, so we can select ATTACH types and help with the ATTACH problems. I moved 'STATE()' to cap-factor because that is the only place it can be used + I enumerated the values it can be compared to.. I added the 'param' element as PARAM() is now used twice. cal-query = "SELECT" SP cap-val SP "FROM" SP comp-name SP "WHERE" SP cap-expr / "SELECT" SP cap-cols SP "FROM" SP comp-name ; NOTE: there is NO space around the "," on ; the next line cap-val = cap-cols / param / ( cap-val "," cap-val ) ; NOTE: there is NO space around the "," on ; the next line cap-cols = cap-col / ( cap-cols "," cap-col) / "*" cap-col = ; Any property name found in the component ; named in the comp-name used in the "FROM" clause. ; ; SELECT ORGANIZER FROM VEVENT ... ; ; OR ; ; A component name of an existing component contained ; inside of the comp-name used in the "FROM" clause. ; ; SELECT VALARM FROM VEVENT ... comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VAGENDA" / "VCAR" / "VCALSTORE" / "VQUERY" / iana-name / x-comp cap-expr = "(" cap-expr ")" / cap-term cap-term = cap-expr SP cap-logical SP cap-expr / cap-factor cap-logical = "AND" / "OR" cap-factor = cap-colval SP cap-oper SP col-value / cap-colval SP "NOT LIKE" SP col-value / cap-colval SP "LIKE" SP col-value / cap-colval SP "IS NULL" / cap-colval SP "IS NOT NULL" / col-value SP "NOT IN" cap-colval" / col-value SP "IN" cap-colval" / "STATE()" "=" ( "BOOKED" / "UNPROCESSED" / "DELETED" ) cap-colval = cap-col / param param = "PARAM(" cap-col "," cap-param ")" cap-param = ; Any parameter that may be contained in the cap-col ; in the supplied PARAM() function col-value = col-literal / "SELF()" / "CAL-OWNERS()" / "CAL-OWNERS(" cal-address ")" / "CURRENT-TARGET()" cal-address = ; A CALID as define by CAP col-literal = "'" literal-data "'" literal-data = ; Any data that matches the value type of the ; column that is being compared. That is you can ; not compare PRIORITY to "some string" because ; PRIORITY has a value type of integer. If it is ; not preceded by the LIKE element, any '%' and '_' ; characters in the literal data are not treated as ; wildcard characters and do not have to be backslash ; escaped. ; ; OR ; ; If the literal-data is preceded by the LIKE ; element it may also contain the '%' and '_' ; wildcard characters. And if the literal data ; that is comparing contains any '%' or '_' ; characters, they MUST BE backslash escaped as ; described in the notes below in order for them not ; to be treated as wildcard characters. cap-oper = "=" / "!=" / "<" / ">" / "<=" / ">=" SP = ; A single white space ascii character ; (value in HEX %x20). x-comp = ; As defined in RFC 2445. iana-name = ; As defined in RFC 2445. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms030408020404080906040901 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMTAwNDA1MFowIwYJKoZIhvcNAQkEMRYEFL7Fju68 2L3DlUXN3pOdmJN/dVh1MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAQMjtMKN+wjvjizhui v6HpIagOqDRqmVqmH6DftjUo2Fbo6kRySqfwC8GiSBrE9Cteg7KyWlc4VCmx5eXBlJwJG+af 0XGjdT/3q3eHFJIYDJSDb//T9gqieTaQeRK2267uKkXltwDKbllnW84qD77Y2iMpkN4M5Kn8 x8W79bfoWlUcsUOuUPiItaLx7pqRDpivtQJr0qFfP/ykgskN6CWzNGmHvhUhGdFo7kDk92bn szOnqkvjzdTllChI5bYyJXuO3yDdK01oasWoaNm3+vqi37q+IWxmTcnqI/HJrFA8NRLqkLrr njOee24RU00vjlfCtA5WxSWBRmJ/1F7prCkUAAAAAAAA --------------ms030408020404080906040901-- From owner-ietf-calendar@mail.imc.org Sun Oct 20 21:21:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06130 for ; Sun, 20 Oct 2002 21:21:46 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9L1Guc18713 for ietf-calendar-bks; Sun, 20 Oct 2002 18:16:56 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9L1GsW18706 for ; Sun, 20 Oct 2002 18:16:54 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9L1GvqN011548 for ; Sun, 20 Oct 2002 18:16:57 -0700 Message-ID: <3DB35586.2080209@Royer.com> Date: Sun, 20 Oct 2002 19:16:54 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org, ietf-calendar@imc.org Subject: Error codes && action items Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070705030303020909030201" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070705030303020909030201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have edited in the CAL-QUERY fixes from the list plus the other items that I brought up. I am going to start fixing the error codes. Does anyone have any items other than what I already posted? Please assume that if I did not mention them in the last week or so, that they are not done! -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070705030303020909030201 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMTAxMTY1NFowIwYJKoZIhvcNAQkEMRYEFFzds8P2 jpn4DT4TJXDoNWju6pVgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB67oOrzva7/e3citIT ZAhs5ez3NzUa/d9xZwY0AZAFAYMnAM2DGVClQcJX3AEuFDyFtpYaNz/Cqzfnxq+Lc8X2sPHv CHRwI9d/GaXIQ+1F0aQQ0Sa3pgfyuDdctmCg94+XC1c4SygndmNuPA++6/hALJFhA3T5XDG2 +92vvBPG1th7hvsQ6oQtlJKSbvaBGsjYepT2wAPuKzMBphn+EjaWug54ZQGcdhw2o30h+7eR m7kPGOAg2EVlp4K/mDSaO1W8kq03CK+WKf0/K4weToZdNwh/U7P4mmH8aUEaqD9Gu3WsP/Dj Fb+2VNp0g2YLa0J96sGm/fc3+xbi3vLDVN6xAAAAAAAA --------------ms070705030303020909030201-- From owner-ietf-calendar@mail.imc.org Mon Oct 21 14:19:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09142 for ; Mon, 21 Oct 2002 14:19:06 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LI9JJ07687 for ietf-calendar-bks; Mon, 21 Oct 2002 11:09:19 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LI9FW07671 for ; Mon, 21 Oct 2002 11:09:16 -0700 (PDT) To: ietf-calendar@imc.org Subject: Draft cutoff MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Mon, 21 Oct 2002 14:09:05 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 10/21/2002 02:09:21 PM, Serialize complete at 10/21/2002 02:09:21 PM Content-Type: multipart/alternative; boundary="=_alternative 0063B5BC85256C59_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0063B5BC85256C59_= Content-Type: text/plain; charset="us-ascii" November 4th is the cut-off date for submission of draft changes. Doug has submitted three items recently. They include Diffs, Error Codes, and an Updated Cal-Query. Prior to that is a note from him regarding Counter. And then several other notes. Doug has consolidated what he feels the list has agreed to. If you are in disagreement please let us know. Even if you are not, please let us know you ok the changes so we can submit. Again, you can go to this url to read the draft. As a reminder, here are the urls again. The -b rev of 09 is at (Note -09 is not yet pushed, -09b was the last published on the WG list only): http://inet-consulting.com/cap-09-b.txt The current changes in context diff format are at: http://inet-consulting.com/cap-09-b-diffs.txt And as it currently looks (cap-09-b.txt + diffs): http://inet-consulting.com/cap-09-b-1.txt --=_alternative 0063B5BC85256C59_= Content-Type: text/html; charset="us-ascii"
November 4th is the cut-off date for submission of draft changes.  Doug has submitted three items recently.  They include Diffs, Error Codes, and an Updated Cal-Query.  Prior to that is a note from him regarding Counter.  And then several other notes.  

Doug has consolidated what he feels the list has agreed to.  If you are in disagreement please let us know.  Even if you are not, please let us know you ok the changes so we can submit.  Again, you can go to this url to read the draft.

 As a reminder, here are the urls again.

The -b rev of 09 is at (Note -09 is not yet pushed, -09b was
the last published on the WG list only):

                http://inet-consulting.com/cap-09-b.txt

The current changes in context diff format are at:

                http://inet-consulting.com/cap-09-b-diffs.txt

And as it currently looks (cap-09-b.txt + diffs):

                http://inet-consulting.com/cap-09-b-1.txt --=_alternative 0063B5BC85256C59_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 21 18:47:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17940 for ; Mon, 21 Oct 2002 18:47:33 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LMcmQ20459 for ietf-calendar-bks; Mon, 21 Oct 2002 15:38:48 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LMclW20455 for ; Mon, 21 Oct 2002 15:38:47 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9LMcmqN020471 for ; Mon, 21 Oct 2002 15:38:49 -0700 Message-ID: <3DB481F5.40204@Royer.com> Date: Mon, 21 Oct 2002 16:38:45 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: ATT-COUNTER added to CAP Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040209040800030909090602" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040209040800030909090602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Per the previous email from Frank Dawson and my reminder last week. I added the following to CAP "2.1.X New Properties (summary)" ATT-COUNTER - When storing a "METHOD" property with the "COUNTER" method, there needs to be a way to remember who sent the COUNTER. The ATT-COUNTER property MUST BE added to all "COUNTER" [iTIP] components by the CUA before storing in a CS. (Section 7.2) And: 7.X ATT-COUNTER Property Property Name: ATT-COUNTER Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST BE specified in any component with the "METHOD" value of "COUNTER". Description: This property is used to identify the CAL-ADDRESS of the entity that sent the "COUNTER" [iTIP] object. Formal Definition: The property is defined by the following notation: attcounter = "ATT-COUNTER" *(";" xparam) ":" cal-address CRLF Examples: ATT-COUNTER:cap:example.com/Doug ATT-COUNTER:mailto:Doug@Example.com -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms040209040800030909090602 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMTIyMzg0NVowIwYJKoZIhvcNAQkEMRYEFOFBe3UX 7MD3GmmMQWxGqJ/KOmAnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCjz0+KdRi9GidVPDMx bmt4OLozIpevA/TWtrW3YuvsEk64PUMTlIrAJ8axA0/kxtmbti/nve6N3AOGC17Zbu5vm0GO KuZp1TDpYuzikZJZfBFmkeVUT/7TBdeR0kAhU8Ynk4Y2l1DolZTfj/b2powYkNhthMtat9Zp pevehLgZvJmNsmibUDJniFu7EdwxkwmONTh9OKOANFunTaRzPLQZ2Fu7kQKCay2dfEWyTyVH 3UNW8AzpuVzFZij7jWPtKCzYXiOB+CFVeUM2zwT0APjvYZwQOq2gBlyvZttIvHD25xKLAGJI XH8i9YXH6rJ6LsupLKBYIOolztp+Ai7MmwpsAAAAAAAA --------------ms040209040800030909090602-- From owner-ietf-calendar@mail.imc.org Tue Oct 22 07:54:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12806 for ; Tue, 22 Oct 2002 07:54:29 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MBkVn16445 for ietf-calendar-bks; Tue, 22 Oct 2002 04:46:31 -0700 (PDT) Received: from ACM1.ARGENTCAPITAL.LOCAL (moneta-199.brick.net [209.74.147.199]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9MBkUW16439 for ; Tue, 22 Oct 2002 04:46:30 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: ATT-COUNTER added to CAP MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 22 Oct 2002 06:43:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2897D8288133FD4F85B51212EE1B8A262D4762@ACM1.ARGENTCAPITAL.LOCAL> Thread-Topic: ATT-COUNTER added to CAP Thread-Index: AcJ5VwGvnfOlpK20TUGhtorkFg9LzwAaSdTA From: "Ken Crawford" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9MBkUW16441 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Doug, I am not sure why I am receiving your e-mail messages. You may want to check your distribution list. Thank you -----Original Message----- From: Doug Royer [mailto:Doug@royer.com] Sent: Monday, October 21, 2002 5:39 PM To: ietf-calendar@imc.org Subject: ATT-COUNTER added to CAP Per the previous email from Frank Dawson and my reminder last week. I added the following to CAP "2.1.X New Properties (summary)" ATT-COUNTER - When storing a "METHOD" property with the "COUNTER" method, there needs to be a way to remember who sent the COUNTER. The ATT-COUNTER property MUST BE added to all "COUNTER" [iTIP] components by the CUA before storing in a CS. (Section 7.2) And: 7.X ATT-COUNTER Property Property Name: ATT-COUNTER Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST BE specified in any component with the "METHOD" value of "COUNTER". Description: This property is used to identify the CAL-ADDRESS of the entity that sent the "COUNTER" [iTIP] object. Formal Definition: The property is defined by the following notation: attcounter = "ATT-COUNTER" *(";" xparam) ":" cal-address CRLF Examples: ATT-COUNTER:cap:example.com/Doug ATT-COUNTER:mailto:Doug@Example.com -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug From owner-ietf-calendar@mail.imc.org Tue Oct 22 12:39:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25351 for ; Tue, 22 Oct 2002 12:39:29 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MGS4u05813 for ietf-calendar-bks; Tue, 22 Oct 2002 09:28:04 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MGS3W05807 for ; Tue, 22 Oct 2002 09:28:03 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id C130D1556F; Tue, 22 Oct 2002 18:28:03 +0200 (CEST) Date: Tue, 22 Oct 2002 18:28:03 +0200 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt Message-ID: <20021022162803.GC26975@inet.it> References: <3DB3199D.3030206@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB3199D.3030206@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, Oct 20, 2002 at 03:01:17PM -0600, Doug Royer wrote: > > I have edited several changes into CAP. Mostly fixing the quoting > and capitalization. Plus some of the minor changes that have > been discussed on the net. > A brief list of minor things (relative to cap-09-b-1.txt): - line 720 has a stray comma: In the case of "SEARCH", command - line 760 has a stray comma: However other "Attendees", may have - line 902 has a repetition ('the the'), but it could probably be rephrased - or even better, copied from line 4018: TRANSP - This is a modification the the [iCAL] "TRANSP" property and it allows more values. The new values are related to conflict control. (Section 7.25) - line 936 has a typo (I think) The "VQUERY" value type is used to fetch objects from the shouldn't this be: The "VQUERY" component is used to fetch objects from the - line 974 has a repetition ('then ... then'): Then if the CUA wished to book the UID, then the CUA would issue a - line 1587 has an extra space ('component s'): Decreed "VCAR" component s MUST BE readable by the calendar owner in - line 2099 has a stray (IMHO) "current": the owners of the current calendar that matches the provided "TARGET" property value. - line 2412 has a wrong (probably stale) reference to "next section", in addition, the sentence shouldn't start with 'And': And see the examples in the next section (IN). Should be: See the examples in the section 6.1.1.13. - line 3211 lacks a verb: If not specified, the default the first value - line 3222 (but also elsewhere): If a charset name contains a comma (,), then that comma must be backslashed escaped in the value. This is useless, as the type is TEXT. [iCAL] already states this in 4.3.11 so IMHO this sentence should be removed. -line 3746 has a typo: Description: A "QUERYID" proprety - line 3980 has two typos: It its value is a capurl as defended in Section 5. - line 5228 has a typo "VAGENDA" components s - line 6259 has a repetition (is is): If the "REQUEST-STATUS" property value is is "2.0", then the entire Hopefully tomorrow I will have time to look at the proposals that are not yet incorporated in the new draft. For now, I saw GET-CAPABILITY was updated to say: A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. The "GET-CAPABILITY" command MUST BE implemented by all CSs. The CS MAY send a "GET-CAPABILITY" command to any CUA. The "GET- CAPABILITY" command MAY be implemented by a CUA. If the CUA does not support the "GET-CAPABILITY" commmand then the CUA must return a not implemented reply. However, I was under the impression that what we had agree on was more like (look for the ***): A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. The "GET-CAPABILITY" command MUST BE implemented by all CSs. The CS ***MUST*** send a "GET-CAPABILITY" command to any CUA. The "GET- CAPABILITY" command ***MUST*** be implemented by a CUA. If the CUA does not support the "GET-CAPABILITY" commmand then the CUA must return a not implemented reply. Actually, of the two ***, in the latter I wanted to keep MAY while Doug and other argued for the MUST; over the former however it seemed to me we all were in strong agreement. Again, more on this tomorrow (with MessageIDs). Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Tue Oct 22 13:28:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27304 for ; Tue, 22 Oct 2002 13:28:44 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MHLDA09463 for ietf-calendar-bks; Tue, 22 Oct 2002 10:21:13 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MHLCW09458 for ; Tue, 22 Oct 2002 10:21:12 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9MHLCqN028334 for ; Tue, 22 Oct 2002 10:21:13 -0700 Message-ID: <3DB58905.2020409@Royer.com> Date: Tue, 22 Oct 2002 11:21:09 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt References: <3DB3199D.3030206@Royer.com> <20021022162803.GC26975@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000406090800080501080003" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000406090800080501080003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > On Sun, Oct 20, 2002 at 03:01:17PM -0600, Doug Royer wrote: > >>I have edited several changes into CAP. Mostly fixing the quoting >>and capitalization. Plus some of the minor changes that have >>been discussed on the net. >> > > > A brief list of minor things (relative to cap-09-b-1.txt): > ... Fixed in my copy ... > > This is useless, as the type is TEXT. [iCAL] already states this > in 4.3.11 so IMHO this sentence should be removed. I left the above in because it kept being asked on the list. As to the text below, I think you are correct. The CS MUST send the GET-CAPABILITY, and a CUA MAY return not-implemented. THANKS! > Hopefully tomorrow I will have time to look at the proposals that are > not yet incorporated in the new draft. For now, I saw GET-CAPABILITY > was updated to say: > > A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial > connection. The "GET-CAPABILITY" command MUST BE implemented by all > CSs. > > The CS MAY send a "GET-CAPABILITY" command to any CUA. The "GET- > CAPABILITY" command MAY be implemented by a CUA. If the CUA does not > support the "GET-CAPABILITY" commmand then the CUA must return a not > implemented reply. > > > > However, I was under the impression that what we had agree on was more > like (look for the ***): > > A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial > connection. The "GET-CAPABILITY" command MUST BE implemented by all > CSs. > > The CS ***MUST*** send a "GET-CAPABILITY" command to any CUA. The "GET- > CAPABILITY" command ***MUST*** be implemented by a CUA. If the CUA does not > support the "GET-CAPABILITY" commmand then the CUA must return a not > implemented reply. > > > Actually, of the two ***, in the latter I wanted to keep MAY while > Doug and other argued for the MUST; over the former however it seemed > to me we all were in strong agreement. - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms000406090800080501080003 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMjE3MjExMFowIwYJKoZIhvcNAQkEMRYEFF65jX3n Hq36xFAeJwszuVG4APRjMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAXNgkrPnCKqhTYby1b cbLXmpzE/8Pl+kX7rcAYHDZAyQzcc/I6NC8cMYUC00VPI8bWlCx5+BFSkEWouPv4yGa7MNky KV0QFBdsYaYoHF4/2VRzK9st93AWaC1glVnCDXvyZSNAZHnLS+aTdBq/O1okpP9i89fKm6YW Jds/ieygNggl5hGs/28eECX0641OjWnr6DmRENtvwxE+4dbBGQV7ep9g+VPwHOl8nIS9u3KN eDg4kXeYyWhBZhZMO4GiNkoTAk70wh1aqZe+8RW+pQ54qKMNJrn97uYW5fmLNrBSvFugS01L AB5+TFZK4rpbq2zkWQLWfA+johMYVY6CVM4iAAAAAAAA --------------ms000406090800080501080003-- From owner-ietf-calendar@mail.imc.org Tue Oct 22 16:14:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02798 for ; Tue, 22 Oct 2002 16:14:44 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MK38H19541 for ietf-calendar-bks; Tue, 22 Oct 2002 13:03:08 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MK36W19536 for ; Tue, 22 Oct 2002 13:03:06 -0700 (PDT) Received: from Royer.com (blackhole.dtdocs.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9MK38qN029432 for ; Tue, 22 Oct 2002 13:03:08 -0700 Message-ID: <3DB5AEF9.1040400@Royer.com> Date: Tue, 22 Oct 2002 14:03:05 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org, ietf-calendar@imc.org Subject: GET-CAPABILITY - reply Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010708030305040906010607" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010708030305040906010607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I updated the text in the GET-CAPABILITY reply: Removed the 'CS' only wording - when it could also be CUA. To support the CUA MAY send not-implemented idea PLEASE CHECK THE DEFAULT VALUES! TO BE: --------------------------------------------------------------------------- When sending a reply to a "GET-CAPABILITY" command, all of these MUST BE supplied. If the CUA does not support sending a full reply and sends not-implemented error, then the CS MUST assume the CUA supports the default values as defined below. A CS MUST always send the full reply when queried. The default values apply only to a CUA when it does not support sending a "GET-CAPABILITY" command reply. The following CS properties are returned in response to a "GET-CAPABILITY" command: Name Occurs Description ------------------------------------------------------------------ CAP-VERSION 1 Version of CAP. MUST include at least "1.0" for this version of CAP. Like the "VERSION" property, it may have a range. Uses the exact same syntax as the "VERSION" property value. The default is "1.0". CAR-LEVEL 1 Indicates level of CAR support. CAR-NONE, CAR-MIN or CAR-FULL-1. If CAR-FULL-1 is supplied then CAR-MIN MUST BE assumed. CAR = NONE MUST BE used when query-level of NONE is supplied. A CAR-MIN implementation only supports the DEFAULT-VCARS listed in the VCALSTORE and does not support the creation or modification of VCARS. The default is CAR-NONE. COMPONENTS 1 A comma separated list of the names of components that are supported. This includes any components inside of other components (VALARM for example). MUST include at least VCALSTORE, VCALENDAR, VREPLY, and VAGENDA and at least one of VEVENT, VTODO, VTIMEZONE, or VJOURNAL. The defalt is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, VEVENT,VALARM,VTIMEZONE" STORES-EXPANDED 1 If TRUE then it expands and stores multiple instances separately when they are booked. If FALSE then it expands instances dynamically during query. Default is FALSE. DATE-MAX 1 The datetime value in UTC beyond which the server cannot accept. The default and maximum value allowed is 99991231T235959Z. DATE-MIN 1 The datetime value in UTC prior to which the server cannot accept. The default and minimum value allowed is 00000101T000000Z. ITIP-VERSION 1 Version(s) of ITIP, MUST include at least the default value of "2446" to specify RFC-2446 support. Comma separated list. MAX-COMPONENT-SIZE 1 A positive integer value that specifies the size of the largest iCalendar object that can be accepted in octets. Objects larger than this will be rejected. A default value of zero (0) means no limit. This is also the maximum value of any BEEP payload that will be accepted or sent. MULTILART 1 A comma separated list of MIME multipart the sender supports in lower case. The default is no multipart support (empty list). Example: MULTIPART:related,alternate PRODID 1 The product id. If supplied in the "VCALENDAR" components, the values MUST BE identical to what is sent in the "GET-CAPABILITY" reply from the CUA or CS. The CUA and CS PRODID values may differ from each other. QUERY-LEVEL 1 Indicates level of SQL support. The default is CAL-QL-1 and NONE can be supplied. (NONE is for CS's that allow ITIP methods only to be deposited and nothing else). If set to NONE, then the 'car' capability MUST BE set to NONE. The default value RECUR-ACCEPTED 1 Whether recurrence rules are acceptable. TRUE (default) or FALSE. RECUR-EXPAND 1 Whether or not it supports the expansion of recurrence rules. TRUE (default) or FALSE. RECUR-LIMIT 1 The maximum number of occurrences of a recurrence rule that are expanded. The default of Zero (0) means unlimited. VERSION 1 Versions of iCalendar support. MUST BE at least "2.0" (the default). This is the same property as defined in [iCAL]. RECUR-ACCEPTED 1 Whether recurrence rules are acceptable. The default is TRUE. X-... 0+ May include zero or more experimental properties. These have no default and if need to be sent by an implementation, then all of the above MUST BE sent. ------------------------------------------------------- -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms010708030305040906010607 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMjIwMDMwNVowIwYJKoZIhvcNAQkEMRYEFKCHVKNu MrFoBReul04bAZbfBXKRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQA4KDF3rqURft382x77 Ll0zZKwLKVtfdY4o8UymMXjcnIGzx8fAEq3YIgA2g4bhMFhWCvzoh61pVUiO7TTro9hQNaXC AMsAT0uiBY/rkc1+viY6LBZlk4Wk8eqvRXfjKOXbOJxvU/DZv0h1XCwxx39dSb4aFTlUITlg mvsHEuxNSf2bq0AVXSvqLzYKvCxstU6MQ2Ds0RtmTwnGUG7lL8R4MrVO+53cpjVznKRZr3o1 4ZVL0qYUaMWQyU1Vw0LekB2bd+b5Vvs2hmyZnpgqy9+7cmh5pb1FHcZIMfMvxCXwk07Sh0+x p/NxYgGMuqIUEpKUJnp9Lo6uH0KEB88MANwvAAAAAAAA --------------ms010708030305040906010607-- From owner-ietf-calendar@mail.imc.org Tue Oct 22 16:25:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03215 for ; Tue, 22 Oct 2002 16:25:31 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MKIEP20298 for ietf-calendar-bks; Tue, 22 Oct 2002 13:18:14 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MKIBW20293 for ; Tue, 22 Oct 2002 13:18:12 -0700 (PDT) To: "ietf-calendar@imc.org" Subject: Re: COUNTER - and who sent it. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 22 Oct 2002 10:31:15 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/22/2002 04:11:53 PM, Serialize complete at 10/22/2002 04:11:53 PM Content-Type: multipart/alternative; boundary="=_alternative 00520BDE85256C5A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00520BDE85256C5A_= Content-Type: text/plain; charset="US-ASCII" Doug wrote: >The issue is that there would be no way to know who sent >the COUNTER method once stored in the CS so that a >possible DECLINE-COUNTER could be sent at a later time. Perhaps Im just too relaxed after a well earned vacation so Ill ask for some clarification. Why isn't the SENT-BY property parameter of the ATTENDEE sufficient enough to detect this? After all its used by someone else (ie: the AA) to ACCEPT on my behalf so why isnt it good enough for a COUNTER?? Unless the CS is removing propeties and property parameters this info should still be there once the COUNTER is deposited into the calendar, yes? I must be missing something here... Besides, the workflow should be thru the relevant ATTENDEE and NOT thru any SENT-BY address. Otherwise I could get into a case where both I and my AA COUNTER with different info and the Chair starts to do workflow to both addresses when it should only be dealing with mine. Back to my 1500+ msg backlog while I await enlightenment... (Was this so that I could see which AA COUNTERed for me?? More caffine, less spam....) 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 00520BDE85256C5A_= Content-Type: text/html; charset="US-ASCII"
Doug wrote:
>The issue is that there would be no way to know who sent
>the COUNTER method once stored in the CS so that a
>possible DECLINE-COUNTER could be sent at a later time.

Perhaps Im just too relaxed after a well earned vacation so Ill ask for some clarification.  Why isn't the SENT-BY property parameter of the ATTENDEE sufficient enough to detect this?  After all its used by someone else (ie: the AA) to ACCEPT on my behalf so why isnt it good enough for a COUNTER??  Unless the CS is removing propeties and property parameters this info should still be there once the COUNTER is deposited into the calendar, yes?  I must be missing something here...

Besides, the workflow should be thru the relevant ATTENDEE and NOT thru any SENT-BY address.  Otherwise I could get into a case where both I and my AA COUNTER with different info and the Chair starts to do workflow to both addresses when it should only be dealing with mine.

Back to my 1500+ msg backlog while I await enlightenment...  (Was this so that I could see which AA COUNTERed for me??  More caffine, less spam....)

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 00520BDE85256C5A_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 22 17:11:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04749 for ; Tue, 22 Oct 2002 17:11:45 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9ML15S21628 for ietf-calendar-bks; Tue, 22 Oct 2002 14:01:05 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9ML13W21623 for ; Tue, 22 Oct 2002 14:01:03 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9ML0tqN029850 for ; Tue, 22 Oct 2002 14:01:05 -0700 Message-ID: <3DB5BC84.8080105@Royer.com> Date: Tue, 22 Oct 2002 15:00:52 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000406010703030105090504" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000406010703030105090504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote: > >The issue is that there would be no way to know who sent > >the COUNTER method once stored in the CS so that a > >possible DECLINE-COUNTER could be sent at a later time. > > Perhaps Im just too relaxed after a well earned vacation so Ill ask for > some clarification. Why isn't the SENT-BY property parameter of the > ATTENDEE sufficient enough to detect this? After all its used by > someone else (ie: the AA) to ACCEPT on my behalf so why isnt it good > enough for a COUNTER?? Unless the CS is removing propeties and property > parameters this info should still be there once the COUNTER is deposited > into the calendar, yes? I must be missing something here... (1) We had this debate in 2000 and this group agreed that SENT-BY should not be used - I posted Franks summary a week or two ago. It and what led up to ATT-COUNTER is in the archives. (2) The 'SENT-BY' could be from the original REQUEST and that would override the who sent this 'COUNTER' to me. (3) 'SENT-BY' is limited to a 'mailto' url, ATT-COUNTER is not. (4) The COUNTER object could be a COUNTER to an updated REQUEST and might contain: METHOD:COUNTER ... ATTENDEE:...SENT-BY="MAILTO:a@a.com" ;PARTSTAT=accepted:MAILTO:a1@a.com ATTENDEE:...SENT-BY="MAILTO:b@b.com" ;PARTSTAT=accepted:MAILTO:b1@b.com ... So who sent the COUNTER? Who do you send any DECLINECOUNTER to? > Besides, the workflow should be thru the relevant ATTENDEE and NOT thru > any SENT-BY address. Otherwise I could get into a case where both I and > my AA COUNTER with different info and the Chair starts to do workflow to > both addresses when it should only be dealing with mine. Where as ATT-COUNTER is defined as who you send the accept or decline counter back to, which would be the e-mail address from an iMIP message and could also be a CAP URL. > Back to my 1500+ msg backlog while I await enlightenment... (Was this > so that I could see which AA COUNTERed for me?? More caffine, less > spam....) It was so you knew who to send a DECLINECOUNTER to. --------------ms000406010703030105090504 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMjIxMDA1MlowIwYJKoZIhvcNAQkEMRYEFBdfpPqX bgGMJDL4uycPauXdZCE5MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCZpDBgY9bssUp8yD3K Tbd+XqE6hZ/4YRNRW4MKmho+P+Sc3kuZEUk1N6wTyQCgOrmVkWsdPr1eo5fHaw4BWH4pU6GT qcNktY+7GvzgWQ++oO3WAo12sEJmaR/rFVKfffcKmsqAlHH8QkDi7q7s++ueYyQ8ggorhitG BWEA57dVxhM8kmiVLT/+7vVuSoH4KyYccPYzn9nQhOLPFJRObtQ5gyvL4eRg+vtmIxciTGzO AgZLuV5KTFBy3E31Nl8QLm9KPmfxiB44imHNgM+oVklB7anwqYBtrPFdTNjm/qIh/n6BBOiU uzghRsNKZW9raOpPfpWiVcaSrr4ORC1YdBzxAAAAAAAA --------------ms000406010703030105090504-- From owner-ietf-calendar@mail.imc.org Tue Oct 22 17:19:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05028 for ; Tue, 22 Oct 2002 17:19:26 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MLBDN21892 for ietf-calendar-bks; Tue, 22 Oct 2002 14:11:13 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MLBBW21888 for ; Tue, 22 Oct 2002 14:11:12 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9MLBA1N032219; Tue, 22 Oct 2002 23:11:11 +0200 Date: Tue, 22 Oct 2002 23:11:15 +0200 Subject: Re: GET-CAPABILITY - reply Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Doug Royer From: Andrea Campi In-Reply-To: <3DB5AEF9.1040400@Royer.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, October 22, 2002, at 10:03 PM, Doug Royer wrote: > PLEASE CHECK THE DEFAULT VALUES! > > . A CS MUST always send the full reply when > queried. [...] > The default values apply only to a CUA when it does not support > sending a "GET-CAPABILITY" command reply. The following CS > properties are returned in response to a "GET-CAPABILITY" command: > Just to double check I got this right (I have no preference either way): this is a change in that with the previous wording, a CS could leave out one or more property, and that property would then take the default value. With the new wording, the CS MUST send a complete reply which MUST include all defined properties. Is that ok for everybody? > STORES-EXPANDED > 1 If TRUE then it expands and stores > multiple instances separately when they are > booked. If FALSE then it expands > instances dynamically during query. > Default is FALSE. I'm not sure how this applies to the CUA... > MULTILART 1 A comma separated list of MIME multipart Typo. > QUERY-LEVEL 1 Indicates level of SQL support. The default > is CAL-QL-1 and NONE can be supplied. (NONE > is for CS's that allow ITIP methods only to > be deposited and nothing else). If set to > NONE, > then the 'car' capability MUST BE set to > NONE. > The default value The default value is missing ;-) Otherwise, everything is ok with me? Bye, Andrea From owner-ietf-calendar@mail.imc.org Tue Oct 22 17:29:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05246 for ; Tue, 22 Oct 2002 17:28:59 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MLLSj22182 for ietf-calendar-bks; Tue, 22 Oct 2002 14:21:28 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MLLQW22178 for ; Tue, 22 Oct 2002 14:21:26 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9MLLQqN030033; Tue, 22 Oct 2002 14:21:26 -0700 Message-ID: <3DB5C153.7080008@Royer.com> Date: Tue, 22 Oct 2002 15:21:23 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi CC: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - reply References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050800090001040104050509" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050800090001040104050509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > On Tuesday, October 22, 2002, at 10:03 PM, Doug Royer wrote: > >> PLEASE CHECK THE DEFAULT VALUES! >> > > >> . A CS MUST always send the full reply when >> queried. > > [...] > >> The default values apply only to a CUA when it does not support >> sending a "GET-CAPABILITY" command reply. The following CS >> properties are returned in response to a "GET-CAPABILITY" command: >> > > Just to double check I got this right (I have no preference either way): > this is a change in that with the previous wording, a CS could leave out > one or more property, and that property would then take the default > value. With the new wording, the CS MUST send a complete reply which > MUST include all defined properties. No change from the previous draft, the chart clearly shows and showed that they must be supplied (1). The only optional ones (0+) are the X- experimental ones. > Is that ok for everybody? > >> STORES-EXPANDED >> 1 If TRUE then it expands and stores >> multiple instances separately when they are >> booked. If FALSE then it expands >> instances dynamically during query. >> Default is FALSE. > > > I'm not sure how this applies to the CUA... A CUA from a large vendor stores each instance separately then when it sends them back out they are a series of RDATE's and no longer an RRULE. If the CS does not care - then no big deal. >> MULTILART 1 A comma separated list of MIME multipart Fixed - thanks. > >> QUERY-LEVEL 1 Indicates level of SQL support. The default >> ... > > The default value is missing ;-) > Fixed - The default is 'CAL-QL-1' -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms050800090001040104050509 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMjIxMjEyM1owIwYJKoZIhvcNAQkEMRYEFP1LLtkx LFXMERRORPSD0IZDo3j2MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCGd4TB3y4dKoxWD2Tm upDBD7iTymdUeLodGPcBvTs9xvWSd8akxBRqNoxU6hzQg8B2DmNy5700mFfgrPwlJy55z+b6 XiVo0gBr7HLiZ5h4y1IDu7xrbQP9hocxWnkq2mZWV/r9ibQBbE+rkaauqdIgsvQoHPKx1iEg D0VBNLdVbx8+ZJTyh3709sd8/ZiMOy37vrgG1lf5Wey0AatG1bUFRAbwFuWPtjUPeDe78Uuz GRx15pfb+9GuhFblhA4Bd5o6Iu0mz7+TUuL2J9gg4RD+dTaTphLm/O5hw9hV9VoOmcaY1zoz ARkIQ4D20rfF8UXbBEGZd+H498U6lGSpwNApAAAAAAAA --------------ms050800090001040104050509-- From owner-ietf-calendar@mail.imc.org Tue Oct 22 18:44:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06759 for ; Tue, 22 Oct 2002 18:44:10 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MMXjx27814 for ietf-calendar-bks; Tue, 22 Oct 2002 15:33:45 -0700 (PDT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MMXiW27809 for ; Tue, 22 Oct 2002 15:33:44 -0700 (PDT) Received: from 66.19.2.76 (10-076.089.popsite.net [66.19.2.76]) by mail1.panix.com (Postfix) with ESMTP id 87DF548951 for ; Tue, 22 Oct 2002 18:33:45 -0400 (EDT) Date: Tue, 22 Oct 2002 18:33:53 -0400 From: Gary McGath Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt To: ietf-calendar@imc.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.4 (Blindsider) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit A few more typographical nitpicks on cap-09-b-1.txt. For whatever reason, my line numbering doesn't agree with Andrea's, so I couldn't easily eliminate duplications. (I sent this before from a different address from the one which I use for this list, and it apparently was devnulled. Sorry if this shows up twice now.) Line 270, capitialized => capitalized Line 274, refered => referred Line 436, "the the" Line 696, suppled => supplied Line 1501, "the the" Line 1525-26, "the the" across a line break Line 1744, slected => selected Line 1906, propery => property Line 2107, properteis => properties Line 2287, allwod => allowed Line 2737, noew => new Line 2900, localizeable => localizable (arguable, but "localizeable" looks funny to me) Line 3043, proprety => property Line 3590, Veiw => View Line 3917, guraintee => guarantee Line 4197, create-minumum => create-minimum Line 4580, commmand => command Line 5069, "is is" From owner-ietf-calendar@mail.imc.org Tue Oct 22 19:37:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07556 for ; Tue, 22 Oct 2002 19:37:10 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MNRpo28981 for ietf-calendar-bks; Tue, 22 Oct 2002 16:27:51 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MNRnW28977 for ; Tue, 22 Oct 2002 16:27:49 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9MNRpqN030877 for ; Tue, 22 Oct 2002 16:27:52 -0700 Message-ID: <3DB5DEF4.20901@Royer.com> Date: Tue, 22 Oct 2002 17:27:48 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050506060406020104050909" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050506060406020104050909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks! - all fixed in my copy. Gary McGath wrote: > A few more typographical nitpicks on cap-09-b-1.txt. For whatever > reason, my line numbering doesn't agree with Andrea's, so I couldn't > easily eliminate duplications. > > (I sent this before from a different address from the one which I use > for this list, and it apparently was devnulled. Sorry if this shows up > twice now.) - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms050506060406020104050909 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMjIzMjc0OVowIwYJKoZIhvcNAQkEMRYEFLjJJl0x syyvQH/d2Zqa8D4KSmTUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCz/QI56hfrQs8Kn7Bx FlbVn4/v8YSFEUr4t1+4z3sgRCFlieY8TeicxdKyw8rLbDmkLiDCeYTc0QRX/7jqcjU3Ph4E gfbwg0h3Z44dpeneBpmcdKxedQeXiGjQQuVYiY3p7drCiqQs+Ynpre+S/+swegKlqBW9g3n1 fURZ0kw5PPmEhSC3P1ANfvbXs0QWIWoasFuWSfB+EPcCJocMiDKoO40XJK4RKu6qjUAY3YgL mg+qu5Py0aewQV18IMe+dfLYSf4qFEPOJN9dfM+AbeNBH2H1mg4I8aNHBCJBuQrXOOlX4T8+ 3NNhMe5/dgSWyuyCXpE8NOrzgzpiHnHPHSnoAAAAAAAA --------------ms050506060406020104050909-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 03:06:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10192 for ; Wed, 23 Oct 2002 03:06:08 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9N6uP804370 for ietf-calendar-bks; Tue, 22 Oct 2002 23:56:25 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9N6uOW04363 for ; Tue, 22 Oct 2002 23:56:24 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9N6uK1N028823; Wed, 23 Oct 2002 08:56:22 +0200 Date: Wed, 23 Oct 2002 08:56:25 +0200 Subject: Re: GET-CAPABILITY - reply Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Doug Royer From: Andrea Campi In-Reply-To: <3DB5C153.7080008@Royer.com> Message-Id: <8C291372-E654-11D6-AB8C-003065A8EEFC@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, October 22, 2002, at 11:21 PM, Doug Royer wrote: > > No change from the previous draft, the chart clearly shows and > showed that they must be supplied (1). The only optional > ones (0+) are the X- experimental ones. I see, sorry for my bad memory (and not actually checking facts). > >> Is that ok for everybody? >>> STORES-EXPANDED >>> 1 If TRUE then it expands and stores >>> multiple instances separately when they >>> are >>> booked. If FALSE then it expands >>> instances dynamically during query. >>> Default is FALSE. >> I'm not sure how this applies to the CUA... > > A CUA from a large vendor stores each instance separately then > when it sends them back out they are a series of RDATE's and > no longer an RRULE. If the CS does not care - then no big > deal. OK, it's just that it sounds a little bit strange to me, exp the part "If FALSE then it expands ... during query". Maybe changing it to something like "If FALSE then it expands... when sending out" would be more generic. Anyway, no big deal. Bye, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 05:30:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12192 for ; Wed, 23 Oct 2002 05:30:52 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9N9Epf25439 for ietf-calendar-bks; Wed, 23 Oct 2002 02:14:51 -0700 (PDT) Received: from eeyore.jsoft.com (24-240-234-245.charter.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9N9EoW25432 for ; Wed, 23 Oct 2002 02:14:50 -0700 (PDT) Received: from jsoft.com (IDENT:Tl91dbInmYm3ilhOMfnpz7VOSgToLn2x@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g9N9A8C21959 for ; Wed, 23 Oct 2002 04:10:08 -0500 Message-ID: <3DB6676F.6020108@jsoft.com> Date: Wed, 23 Oct 2002 04:10:07 -0500 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt References: <3DB5DEF4.20901@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, can you put your fixed copy up? Gary Doug Royer wrote: > > Thanks! - all fixed in my copy. > > Gary McGath wrote: > >> A few more typographical nitpicks on cap-09-b-1.txt. For whatever >> reason, my line numbering doesn't agree with Andrea's, so I couldn't >> easily eliminate duplications. >> >> (I sent this before from a different address from the one which I use >> for this list, and it apparently was devnulled. Sorry if this shows up >> twice now.) trim From owner-ietf-calendar@mail.imc.org Wed Oct 23 13:35:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26753 for ; Wed, 23 Oct 2002 13:35:54 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NHS8d28330 for ietf-calendar-bks; Wed, 23 Oct 2002 10:28:08 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NHS7W28326 for ; Wed, 23 Oct 2002 10:28:07 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NHS8qN006138 for ; Wed, 23 Oct 2002 10:28:08 -0700 Message-ID: <3DB6DC25.6040307@Royer.com> Date: Wed, 23 Oct 2002 11:28:05 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{txt,html} References: <3DB5DEF4.20901@Royer.com> <3DB6676F.6020108@jsoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080808040601050209070500" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080808040601050209070500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Done - the -09 version rev b-2 TXT and HTML dated Today 23 Oct 2002 are at: http://INET-Consulting.com/cap-09-2.txt http://INET-Consulting.com/cap-09-2.html Note: the XSLT processing removed the 'day' from the date. I am looking at that now... Gary Frederick wrote: > > Doug, can you put your fixed copy up? > > Gary > > Doug Royer wrote: > >> >> Thanks! - all fixed in my copy. >> >> Gary McGath wrote: >> >>> A few more typographical nitpicks on cap-09-b-1.txt. For whatever >>> reason, my line numbering doesn't agree with Andrea's, so I couldn't >>> easily eliminate duplications. >>> >>> (I sent this before from a different address from the one which I use >>> for this list, and it apparently was devnulled. Sorry if this shows up >>> twice now.) >> > trim -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms080808040601050209070500 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzE3MjgwNVowIwYJKoZIhvcNAQkEMRYEFHlpvIs2 Tqwh4KUPCWNqylxxKaidMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCKTmvkX1jLiYYmS/TD KmkscEyU9OGmMyjatDIOVopVUMgHJp/u8tFDn7k4sRoLqRb0v0x0HS5z8LEji51j9b4/BgiL CzOGRRxikEs0Y3SVOmFenyLVUDVxqyD4ahrDldBX1NqsbSqKDpauRtyiduKQbdVOLTH0c4Jc l9YyPuCKnY2jdi6Oea5jdHwruHquUv++CT5X0TOaGzKuvnaVTywCC2tVRoqtqdQPrYL/a2a6 nJ2fjCmOmcwBCQ2vz9ifqcIzJBH0VdyYFTUbTlQt+h/bNz48CIdXrRXRIZS0nXk2cSNEQs/O DPX1b+tzDtC1yVkfR0zss5eyQLiGNALZt6XhAAAAAAAA --------------ms080808040601050209070500-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 13:49:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27086 for ; Wed, 23 Oct 2002 13:49:35 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NHdiX29072 for ietf-calendar-bks; Wed, 23 Oct 2002 10:39:44 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NHdhW29065 for ; Wed, 23 Oct 2002 10:39:43 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NHdfqN006210; Wed, 23 Oct 2002 10:39:41 -0700 Message-ID: <3DB6DEDA.3020008@Royer.com> Date: Wed, 23 Oct 2002 11:39:38 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi CC: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - reply References: <8C291372-E654-11D6-AB8C-003065A8EEFC@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070009010704050101040208" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070009010704050101040208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > ... > OK, it's just that it sounds a little bit strange to me, exp the part > "If FALSE then it expands ... during query". Maybe changing it to > something like "If FALSE then it expands... when sending out" would be > more generic. > Anyway, no big deal. Yes - now I see your point, how about: If TRUE then it expands multiple instances separately when they are stored (RRULEs converted to RDATEs) and when sent. If FALSE then it expands instances dynamically during sending. Default is FALSE. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070009010704050101040208 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzE3MzkzOFowIwYJKoZIhvcNAQkEMRYEFIMsENt+ flzI8FiBfSDJjKxRpDsbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCCBh1LtmBqM5L9nEyW 9y/z20vNsdqz3sAMeFtONOotiXMx2Az/uYf1+Vd0DeqhP2/ZO4do7vRgP+iXIYWG0AbmjRmO zpfPad3R9R+LvjmAMd6+NCiNmkgFXljxzaflksD1porp2Q+AbgGGBxwCvUxVgveQ6ltnC0C/ QXLxuG91TVK1TmoChsz4Mj+HVJeGKoEciXV0UlScTfqHOIRUtG+0jEahUnPAi2Yx3CXB6JXc h5F07bYZx+86Rtq2tMTcXdpBwQ6fregf4v4qvcToUcKtOH7qQ+pKcahIDs0VD/veHS7qltI2 Fn6FMjw5ueQFfG51WqGMDUmUdIuVyPWaHHwpAAAAAAAA --------------ms070009010704050101040208-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 14:07:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27764 for ; Wed, 23 Oct 2002 14:07:37 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NI0js01511 for ietf-calendar-bks; Wed, 23 Oct 2002 11:00:45 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NI0iW01507 for ; Wed, 23 Oct 2002 11:00:44 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9NI0h1N023970; Wed, 23 Oct 2002 20:00:44 +0200 Date: Wed, 23 Oct 2002 20:00:46 +0200 Subject: Re: GET-CAPABILITY - reply Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Doug Royer From: Andrea Campi In-Reply-To: <3DB6DEDA.3020008@Royer.com> Message-Id: <5B47B532-E6B1-11D6-B6A3-003065A8EEFC@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, October 23, 2002, at 07:39 PM, Doug Royer wrote: > > Yes - now I see your point, how about: > > If TRUE then it expands multiple instances separately when they > are > stored (RRULEs converted to RDATEs) and when sent. If FALSE then > it > expands instances dynamically during sending. Default is FALSE. > That's fine with me. Bye, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 14:33:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28919 for ; Wed, 23 Oct 2002 14:33:12 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NIKIi01907 for ietf-calendar-bks; Wed, 23 Oct 2002 11:20:18 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NIKHW01902 for ; Wed, 23 Oct 2002 11:20:17 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NIKGqN006674; Wed, 23 Oct 2002 11:20:16 -0700 Message-ID: <3DB6E85D.4000107@Royer.com> Date: Wed, 23 Oct 2002 12:20:13 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{txt,html} References: <3DB5DEF4.20901@Royer.com> <3DB6676F.6020108@jsoft.com> <3DB6DC25.6040307@Royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010208000605030709080808" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010208000605030709080808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I just updated my copy of 'rfc2629.xslt', so it puts the day of the month in the Draft and Expire dates. Just like xml2rfc.tcl does. And I updated the cap-09-2.html copy on INET-Consulting.com . The tweaked XSLT file is at: http://INET-Consulting.com/rfc2629.xslt Doug Royer wrote: > > Note: the XSLT processing removed the 'day' from the date. I am > looking at that now... --------------ms010208000605030709080808 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzE4MjAxM1owIwYJKoZIhvcNAQkEMRYEFMPGzPP2 +5qjOT0s4rvC/JO4H6n5MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBFLYkxRB2/mNCP8w8r V2SGXKVJ4pKk4DGvDVQCluM/N1r/BTBjjkj18cvN+EB5rdKLRBAoWJyc8dcyTycbcaK8Wb4c eIwOyd/xcvsRjbP2UEOVXMHWnI+D0xgQvk0nYm/3aLVI9ZDzrTMy/+xePrfqfHmsYBRPENeb aabtGCKu30xaFNvnNbw/ogneATMki3kboJwgr1pzctjRqMUFJcQThI1Q1OK2DvMc4zIOy7kp 38ldtC+aqsbRztlRMnB4tLKwIOgufLKPzP6zFvEZ3AUvyIvCw3A2nc9iP7blu3lrAjdsSxqt Bqus8j01JRtLxdwCslrMOPzDMETcGqMRckPyAAAAAAAA --------------ms010208000605030709080808-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 14:49:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29589 for ; Wed, 23 Oct 2002 14:49:43 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NIfAM02544 for ietf-calendar-bks; Wed, 23 Oct 2002 11:41:10 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NIf8W02539 for ; Wed, 23 Oct 2002 11:41:09 -0700 (PDT) To: Doug Royer Cc: ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{txt,html} MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 23 Oct 2002 14:41:02 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 10/23/2002 02:41:12 PM, Serialize complete at 10/23/2002 02:41:12 PM Content-Type: multipart/alternative; boundary="=_alternative 0066A2D085256C5B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066A2D085256C5B_= Content-Type: text/plain; charset="us-ascii" Hi, i hope everyone is taking this opportunity to read Doug's changes. Is anyone opposed to what is there so far? If so please say so on the list. If I do not hear angry outbursts or major objections, then we will have Doug submit the changes to date. Doug Royer Sent by: owner-ietf-calendar@mail.imc.org 10/23/2002 14:20 To: ietf-calendar@imc.org cc: Subject: Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{txt,html} I just updated my copy of 'rfc2629.xslt', so it puts the day of the month in the Draft and Expire dates. Just like xml2rfc.tcl does. And I updated the cap-09-2.html copy on INET-Consulting.com . The tweaked XSLT file is at: http://INET-Consulting.com/rfc2629.xslt Doug Royer wrote: > > Note: the XSLT processing removed the 'day' from the date. I am > looking at that now... --=_alternative 0066A2D085256C5B_= Content-Type: text/html; charset="us-ascii"
Hi, i hope everyone is taking this opportunity to read Doug's changes.  Is anyone opposed to what is there so far?  If so please say so on the list.  If I do not hear angry outbursts or major objections, then we will have Doug submit the changes to date.


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

10/23/2002 14:20

       
        To:        ietf-calendar@imc.org
        cc:        
        Subject:        Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{txt,html}




I just updated my copy of 'rfc2629.xslt', so it puts the
day of the month in the Draft and Expire dates. Just like
xml2rfc.tcl does. And I updated the cap-09-2.html copy on
INET-Consulting.com .

The tweaked XSLT file is at:

                http://INET-Consulting.com/rfc2629.xslt


Doug Royer wrote:
>
> Note: the XSLT processing removed the 'day' from the date. I am
> looking at that now...

--=_alternative 0066A2D085256C5B_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 15:46:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02951 for ; Wed, 23 Oct 2002 15:46:03 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NJXCK05892 for ietf-calendar-bks; Wed, 23 Oct 2002 12:33:12 -0700 (PDT) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NJXAW05884 for ; Wed, 23 Oct 2002 12:33:11 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g9NJX9jJ012040; Wed, 23 Oct 2002 21:33:09 +0200 Date: Wed, 23 Oct 2002 21:33:10 +0200 Subject: 6.1.1 CAL-QUERY Value Type Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Doug Royer From: Andrea Campi In-Reply-To: <3DB6DC25.6040307@Royer.com> Message-Id: <43D0E73C-E6BE-11D6-B6A3-003065A8EEFC@inet.it> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Doug, sorry I can't find a proper proposal for this (though I mentioned it in I mentioned it in <20020906134355.GF32393@inet.it>), but since it's an obvious error, I propose to fix it right now. Rules 6 and he example have the syntax component.*: SELECT VALARM.* FROM VEVENT WHERE UID = "123" But the ABNF doesn't allow this. Also, cap-col doesn't allow for the component.property syntax, i.e. it is: cap-col = ; Any property name found in the component ; named in the comp-name used in the "FROM" clause. ; ; SELECT ORGANIZER FROM VEVENT ... ; ; OR ; ; A component name of an existing component contained ; inside of the comp-name used in the "FROM" clause. ; ; SELECT VALARM FROM VEVENT ... IMHO it should be something like: cap-col = ; Any property name found in the component ; named in the comp-name used in the "FROM" clause. ; ; SELECT ORGANIZER FROM VEVENT ... ; ; OR ; ; A component name of an existing component contained ; inside of the comp-name used in the "FROM" clause. ; ; SELECT VALARM FROM VEVENT ... ; ; OR ; ; Any property name found in any component contained ; inside of the comp-name used in the "FROM" clause; the ; component and property name are separated by a dot '.' ; ; ; SELECT * FROM VEVENT WHERE VALARM.TRIGGER < '20020201T000000Z' Note however that this would also allow component.property as a cap-val, i.e.: SELECT VALARM.TRIGGER FROM VEVENT WHERE UID = "123" However, AFAIK we never discussed this before, so we might want to fix this it later on. Bye, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 15:59:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03397 for ; Wed, 23 Oct 2002 15:59:51 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NJnCR06594 for ietf-calendar-bks; Wed, 23 Oct 2002 12:49:12 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NJnBW06588 for ; Wed, 23 Oct 2002 12:49:11 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9NJn41N032477; Wed, 23 Oct 2002 21:49:04 +0200 Date: Wed, 23 Oct 2002 21:49:09 +0200 Subject: Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{txt,html} Content-Type: multipart/alternative; boundary=Apple-Mail-4--886708727 Mime-Version: 1.0 (Apple Message framework v546) Cc: Doug Royer , ietf-calendar@imc.org To: pregen@egenconsulting.com From: Andrea Campi In-Reply-To: Message-Id: <7F45FD8E-E6C0-11D6-B6A3-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-4--886708727 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Pat, On Wednesday, October 23, 2002, at 08:41 PM, pregen@egenconsulting.com=20= wrote: > > Hi, i hope everyone is taking this opportunity to read Doug's changes.=20= > =A0Is anyone opposed to what is there so far? =A0If so please say so = on=20 > the list. =A0If I do not hear angry outbursts or major objections, = then=20 > we will have Doug submit the changes to date. I'm currently going through my notes, I hope to finish posting what I=20 think tonight but it might take longer. Could we please wait a little=20 more, just to be sure we at least fix those issues we already had=20 consensus on? Bye, Andrea= --Apple-Mail-4--886708727 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pat, On Wednesday, October 23, 2002, at 08:41 PM, pregen@egenconsulting.com wrote: Hi, i hope everyone is taking this opportunity to read Doug's changes. =A0Is anyone opposed to what is there so far? =A0If so please = say so on the list. =A0If I do not hear angry outbursts or major objections, then we will have Doug submit the changes to date. I'm currently going through my notes, I hope to finish posting what I think tonight but it might take longer. Could we please wait a little more, just to be sure we at least fix those issues we already had consensus on? Bye, Andrea= --Apple-Mail-4--886708727-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 16:04:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03528 for ; Wed, 23 Oct 2002 16:04:15 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NJtTs06766 for ietf-calendar-bks; Wed, 23 Oct 2002 12:55:29 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NJtSW06762 for ; Wed, 23 Oct 2002 12:55:28 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9NJtT1N000568; Wed, 23 Oct 2002 21:55:29 +0200 Date: Wed, 23 Oct 2002 21:55:35 +0200 Subject: =?ISO-8859-1?Q?1.3.=A0_Definitions_?= Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Doug Royer From: Andrea Campi Content-Transfer-Encoding: 7bit Message-Id: <64FC6B96-E6C1-11D6-B6A3-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Doug, in 1.3 we have: A marked for delete component is set to the "DELETE" state. To retrieve any deleted object, simply do a query asking for any objects that were stored in the "DELETED" state. By default objects marked for delete are not returned. The CUA must specifically ask for marked for delete objects. In <20020905135236.GC29009@inet.it> I said: > It might not be obvious but in addition to this, a query MUST NOT return objects in the DELETED > state and in other states, as there would be no way to distinguish between them. I wonder if this > warrants a brief note here. In <3D776F6C.770DD3B0@Royer.com> you agree, and there was no objection. What about: A marked for delete component is set to the "DELETE" state. To retrieve any deleted object, simply do a query asking for any objects that were stored in the "DELETED" state. By default objects marked for delete are not returned. The CUA must specifically ask for marked for delete objects. Note that you can't ask for components in the "DELETE" state and in other states, as there would be no way to distinguish between them in the reply. Bye, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 16:14:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03799 for ; Wed, 23 Oct 2002 16:14:31 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NK3Tl07070 for ietf-calendar-bks; Wed, 23 Oct 2002 13:03:29 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NK3SW07065 for ; Wed, 23 Oct 2002 13:03:28 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9NK3S1N001215; Wed, 23 Oct 2002 22:03:29 +0200 Date: Wed, 23 Oct 2002 22:03:33 +0200 Subject: 9.5 MODIFY Command Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Doug Royer From: Andrea Campi Content-Transfer-Encoding: 7bit Message-Id: <82462C34-E6C2-11D6-B6A3-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Doug, as I wrote in <20020905100246.GA29009@inet.it>, MODIFY doesn't have an ABNF for reply. I do realize it might be too late to fix this in this draft, and I'm not sure I'd be able to come up with an ok ABNF, so I just wanted to bring this up again so we don't forget. Bye, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 16:23:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04273 for ; Wed, 23 Oct 2002 16:23:37 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKCbZ07575 for ietf-calendar-bks; Wed, 23 Oct 2002 13:12:37 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKCaW07570 for ; Wed, 23 Oct 2002 13:12:36 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Updated CAL-QUERY MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 23 Oct 2002 16:12:17 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/23/2002 04:06:09 PM, Serialize complete at 10/23/2002 04:06:09 PM Content-Type: multipart/alternative; boundary="=_alternative 006F2DEF85256C5B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F2DEF85256C5B_= Content-Type: text/plain; charset="US-ASCII" Doug wrote: > I added cap-val and included the 'PARAM()' call, so we can > select ATTACH types and help with the ATTACH problems. Did you also add text to define how property parameters were to be treated as well?? Since there is text in 6.1.1 that says: 1. For the purpose of a query, all components should be handled as tables, and the properties of those components, should be handled as columns. 2. All VAGENDAs and CS's look like tables for the purpose of a QUERY. And all of their properties look like columns in those tables. but there is no mention of how property parameters are to be handled. Otherwise its unclear just how property parameters should be handled (ie: searching for any ATTENDEE property that contains a CN property parameter that contains, say, "Contractor" in it or that has an PARTSTAT=ACCEPTED and I only want some property parametes of it...). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F2DEF85256C5B_= Content-Type: text/html; charset="US-ASCII"
Doug wrote:
> I added cap-val and included the 'PARAM()' call, so we can
> select ATTACH types and help with the ATTACH problems.
Did you also add text to define how property parameters were to be treated as well??  Since there is text in 6.1.1 that says:

   1.  For the purpose of a query, all components should be handled as
      tables, and the properties of those components, should be handled
      as columns.
   2.  All VAGENDAs and CS's look like tables for the purpose of a
      QUERY.  And all of their properties look like columns in those
      tables.
but there is no mention of how property parameters are to be handled.  Otherwise its unclear just how property parameters should be handled (ie: searching for any ATTENDEE property that contains a CN property parameter that contains, say, "Contractor" in it or that has an PARTSTAT=ACCEPTED and I only want some property parametes of it...).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006F2DEF85256C5B_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 16:32:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04520 for ; Wed, 23 Oct 2002 16:32:18 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKOmY08143 for ietf-calendar-bks; Wed, 23 Oct 2002 13:24:48 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKOiW08131 for ; Wed, 23 Oct 2002 13:24:45 -0700 (PDT) To: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 23 Oct 2002 16:21:44 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/23/2002 04:18:19 PM, Serialize complete at 10/23/2002 04:18:19 PM Content-Type: multipart/alternative; boundary="=_alternative 00700B8285256C5B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00700B8285256C5B_= Content-Type: text/plain; charset="US-ASCII" Doug replied: > As to the text below, I think you are correct. The CS MUST send > the GET-CAPABILITY, and a CUA MAY return not-implemented. [Snip] > > However, I was under the impression that what we had agree on was more > > like (look for the ***): > > > > A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial > > connection. The "GET-CAPABILITY" command MUST BE implemented by all > > CSs. > > > > The CS ***MUST*** send a "GET-CAPABILITY" command to any CUA. The "GET- > > CAPABILITY" command ***MUST*** be implemented by a CUA. If the CUA does not > > support the "GET-CAPABILITY" commmand then the CUA must return a not > > implemented reply. I agree w/Andrea on this one. Given we are starting out fresh with CAP I think that the implementing GET-CAPABILITY is a MUST for both sides. Im less adament on the CS MUST send it but its a very very good idea to. Even if your CS doesnt support ATTACHments (or other heavier stuff), its still a very good idea to always do a GET-CAPABILITY before doing any real work. I cant think of any reason why a CUA would not be reasonably able to implement a GET-CAPABILITY handler so why shouldnt this be a MUST also?... After all any 'lightweight' CUA that doesnt do much can very easily code up a simple handler that sends back "I only support plain VEVENTs and nothing more" in only a few lines of code. Its probably the 1st routine to get coded as folks build their CUA so why not make it MUST?? 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 00700B8285256C5B_= Content-Type: text/html; charset="US-ASCII"
Doug replied:
> As to the text below, I think you are correct. The CS MUST send
> the GET-CAPABILITY, and a CUA MAY return not-implemented.
[Snip]
> > However, I was under the impression that what we had agree on was more
> > like (look for the ***):
> >
> >    A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial
> >    connection.  The "GET-CAPABILITY" command MUST BE implemented by all
> >    CSs.
> >
> >    The CS ***MUST*** send a "GET-CAPABILITY" command to any CUA.  The "GET-
> >    CAPABILITY" command ***MUST*** be implemented by a CUA.  If the CUA does not
> >    support the "GET-CAPABILITY" commmand then the CUA must return a not
> >    implemented reply.
I agree w/Andrea on this one.  

Given we are starting out fresh with CAP I think that the implementing GET-CAPABILITY is a MUST for both sides.  Im less adament on the CS MUST send it but its a very very good idea to.  Even if your CS doesnt support ATTACHments (or other heavier stuff), its still a very good idea to always do a GET-CAPABILITY before doing any real work.

I cant think of any reason why a CUA would not be reasonably able to implement a GET-CAPABILITY handler so why shouldnt this be a MUST also?...  After all any 'lightweight' CUA that doesnt do much can very easily code up a simple handler that sends back "I only support plain VEVENTs and nothing more" in only a few lines of code.  Its probably the 1st routine to get coded as folks build their CUA so why not make it MUST??

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 00700B8285256C5B_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 16:36:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04616 for ; Wed, 23 Oct 2002 16:36:00 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKOqI08150 for ietf-calendar-bks; Wed, 23 Oct 2002 13:24:52 -0700 (PDT) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKOmW08139 for ; Wed, 23 Oct 2002 13:24:48 -0700 (PDT) To: Andrea Campi Cc: Doug Royer , ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{txt,html} MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Wed, 23 Oct 2002 16:24:41 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 10/23/2002 04:24:53 PM, Serialize complete at 10/23/2002 04:24:53 PM Content-Type: multipart/alternative; boundary="=_alternative 0070201F85256C5B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0070201F85256C5B_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We should wait for changes to be made that match what the list wants.=20 That's why I posted my comments Here's what the IETF sent as the deadline. NOte that they ask for no last = minutes submissions. We fall into the 11/4 deadline date. > > Please do NOT wait until the last minute to submit. > >Be advised: NO placeholders. Updates to initial submissions received > the week of October 28th will NOT be accepted. > >November 4th: FINAL Internet-Draft Cutoff =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Andrea Campi Sent by: owner-ietf-calendar@mail.imc.org 10/23/2002 15:49 =20 To: pregen@egenconsulting.com cc: Doug Royer , ietf-calendar@imc.org Subject: Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{= txt,html} Hi Pat, On Wednesday, October 23, 2002, at 08:41 PM, pregen@egenconsulting.com=20 wrote: > > Hi, i hope everyone is taking this opportunity to read Doug's changes.=20 > =A0Is anyone opposed to what is there so far? =A0If so please say so on=20 > the list. =A0If I do not hear angry outbursts or major objections, then=20 > we will have Doug submit the changes to date. I'm currently going through my notes, I hope to finish posting what I=20 think tonight but it might take longer. Could we please wait a little=20 more, just to be sure we at least fix those issues we already had=20 consensus on? Bye, Andrea --=_alternative 0070201F85256C5B_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We should wait for changes to be mad= e that match what the list wants.  That's why I posted my comments

Here's what the IETF sent as the dea= dline.  NOte that they ask for no last minutes submissions.  We f= all into the 11/4 deadline date.

>
>  Please do NOT wait until the last minute to submit.
>
>Be advised: NO placeholders. Updates to initial submissions received
>             the week of October 28th wil= l NOT be accepted.
>
>November 4th: FINAL Internet-Draft Cutoff


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652


Andrea Campi <a.campi@inet.it&= gt;
Sent by: owner-ietf-calendar@mail.im= c.org

10/23/2002 15:49

       
        To: &nbs= p;      pregen@egenconsulting.com
        cc: &nbs= p;      Doug Royer <Doug@royer.com>, ietf-calendar@imc= .org
        Subject:=        Re: Diffs - http://INET-Consulting.com/cap-09-b= -2.{txt,html}



Hi Pat,

On Wednesday, October 23, 2002, at 08:41 PM, pregen@egenconsulting.com
wrote:

>
> Hi, i hope everyone is taking this opportunity to read Doug's changes.=
> =A0Is anyone opposed to what is there so far? =A0If so please say so o= n
> the list. =A0If I do not hear angry outbursts or major objections, the= n
> we will have Doug submit the changes to date.

I'm currently going through my notes, I hope to finish posting what I
think tonight but it might take longer. Could we please wait a little
more, just to be sure we at least fix those issues we already had
consensus on?

Bye,
                Andrea

--=_alternative 0070201F85256C5B_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 16:46:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04811 for ; Wed, 23 Oct 2002 16:46:21 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKXVv08613 for ietf-calendar-bks; Wed, 23 Oct 2002 13:33:31 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKXTW08608 for ; Wed, 23 Oct 2002 13:33:29 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NKXVqN007656 for ; Wed, 23 Oct 2002 13:33:31 -0700 Message-ID: <3DB70798.5040905@Royer.com> Date: Wed, 23 Oct 2002 14:33:28 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 1.3. Definitions References: <64FC6B96-E6C1-11D6-B6A3-003065A8EEFC@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080405060500010206030501" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080405060500010206030501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit If there are no objections, I'll add the 'Note': ... You can not query for components in the "DELETED" state and in other states in the same "VQUERY" component, as there would be no way to distinguish between them in the reply. Andrea Camp wrote: > Hi Doug, > > in 1.3 we have: > > A marked for delete component is set to the "DELETE" state. To retrieve > any deleted object, simply do a query asking for any objects that were > stored in the "DELETED" state. By default objects marked for delete are > not returned. The CUA must specifically ask for marked for delete objects. > > In <20020905135236.GC29009@inet.it> I said: > > > It might not be obvious but in addition to this, a query MUST NOT > return objects in the DELETED > > state and in other states, as there would be no way to distinguish > between them. I wonder if this > > warrants a brief note here. > > In <3D776F6C.770DD3B0@Royer.com> you agree, and there was no objection. > > What about: > > A marked for delete component is set to the "DELETE" state. To retrieve > any deleted object, simply do a query asking for any objects that were > stored in the "DELETED" state. By default objects marked for delete are > not returned. The CUA must specifically ask for marked for delete > objects. Note that you can't ask for components in the "DELETE" state > and in other states, as there would be no way to distinguish between > them in the reply. > > > Bye, > Andrea -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms080405060500010206030501 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIwMzMyOFowIwYJKoZIhvcNAQkEMRYEFJOWE4Ip AmvKyUcVFHNZURfmxfE2MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAWdMsXCM+9Adkl6kKV LfSxvb0rCc6N1d7Q8y9z69iSFSxcnYJ+GdDAcYinavThgpFXuWL3g9RT7fw2AdjzVLWHP78x xBFGCJkB2NncByrtgbOE61Z3nTD93IpRWDKhjQwGpAwIiO5onUebgc0RJU2yCNQFJAj04CYn GbavbFo+I7EQ0sRVYyZxzZgpIcWQguXGA/F0wK7/3FEja7/U+GVQTgB5G5KfcoOxxdogNmgg /W84yslPRy6Z5cclaE/j6Rv76lYUVJGJzW+dSiW7YnjJa2QR7mdxtduXD2UyM35azdP5NiRb SdVAyoVAyo8hgSc+xqk3R4KgGrZ/NZMJHIOFAAAAAAAA --------------ms080405060500010206030501-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 16:49:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04856 for ; Wed, 23 Oct 2002 16:49:14 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKhB808998 for ietf-calendar-bks; Wed, 23 Oct 2002 13:43:11 -0700 (PDT) Received: from hal-4.inet.it (hal-4.inet.it [213.92.5.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKh9W08994 for ; Wed, 23 Oct 2002 13:43:10 -0700 (PDT) Received: from [::ffff:80.206.59.50] by hal-4.inet.it via I-SMTP-4.2.3-422 id 007+leqSfkxnq; Wed, 23 Oct 2002 22:43:09 +0200 Date: Wed, 23 Oct 2002 22:43:07 +0200 Subject: =?ISO-8859-1?Q?8.6.=A0_VQUERY_Component_?= Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Doug Royer From: Andrea Campi Content-Transfer-Encoding: 7bit Message-Id: <0962A384-E6C8-11D6-BB10-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Doug, back in August Patrice Lapierre proposed (<1028739969.18782.107.camel@c-1241.in.steltor.com>) to add a TARGET property to the VQUERY component to determine where to look for a named stored VQUERY. You agreed, I agree, and nobody objected. Later on, in September, I posted a reminder with a proposed ABNF (in <20020904164954.GB26483@inet.it>) and again nobody objected. So I'd say, let's do it: queryc = "BEGIN" ":" "VQUERY" CRLF queryprop "END" ":" "VCAR" CRLF queryprop = 1*( ; the following are OPTIONAL but MUST NOT occur ; more than once ; queryid / target ; the following are OPTIONAL, and MAY occur ; more than once ; / name / x-prop / iana-prop ; the following MUST occur at least once. ; / query ) Also, in the description, we should add: The "TARGET" property specifies where to look for a stored "VQUERY" component, or where to store a "VQUERY" component. Bye, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 16:50:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04889 for ; Wed, 23 Oct 2002 16:50:17 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKhrh09016 for ietf-calendar-bks; Wed, 23 Oct 2002 13:43:53 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKhqW09012 for ; Wed, 23 Oct 2002 13:43:52 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NKhrqN007728 for ; Wed, 23 Oct 2002 13:43:54 -0700 Message-ID: <3DB70A07.90506@Royer.com> Date: Wed, 23 Oct 2002 14:43:51 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Updated CAL-QUERY References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030003080503020703070600" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030003080503020703070600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In -09-2: 6.1.1.3 PARAM() Used in a CAL-QUERY. Returns the value of the named parameter from the named property. If there are multiple properties in the object, then PARAM() returns a comma separated list of parameter values. If needed each value can be quoted or contain backslash escaped contents. When used in a "SELECT" clause, it returns the entire property and all of that properties parameters (the result is not limited to the supplied parameter). If the property does not contain the named parameter, then the property is not returned (It could however be returned as a result of another "SELECT" clause value.) If multiple properties of the supplied name have the named parameter, all properties with that named parameter are returned. When used in the "WHERE" clause, a match is true when the parameter value is "IN" or "LIKE" compare clause according to the supplied WHERE values. If multiple named properties contain the named parameter, then each parameter value is compared to the condition and if any match, then the results would be true for that condition the same as if only one had existed. I *think* that covers it - or did I miss your point? Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote: > > I added cap-val and included the 'PARAM()' call, so we can > > select ATTACH types and help with the ATTACH problems. > > Did you also add text to define how property parameters were to be > treated as well?? Since there is text in 6.1.1 that says: > > 1. For the purpose of a query, all components should be handled as > tables, and the properties of those components, should be handled > as columns. > > 2. All VAGENDAs and CS's look like tables for the purpose of a > QUERY. And all of their properties look like columns in those > tables. > > but there is no mention of how property parameters are to be handled. > Otherwise its unclear just how property parameters should be handled > (ie: searching for any ATTENDEE property that contains a CN property > parameter that contains, say, "Contractor" in it or that has an > PARTSTAT=ACCEPTED and I only want some property parametes of it...). > - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms030003080503020703070600 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIwNDM1MVowIwYJKoZIhvcNAQkEMRYEFDSiLi8v ++JzeS5N1MUR/tlnkn3BMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBoF/TCdPTFRrqh5nq8 9NSw3EihoV6B2P8z/rnNxlFt2KJldXJmWW4LRzN/wKmfqM9Wo9buHpdEplu2MDI2QEf725Tr 9i/wINaYErI06V81/l1Fy5bjoFlJ1gE0oQnieGjmN5JXTg8xzfbTAbZotuWghMLphJv1b7ky 4dMRKCN0NrW4/n91ZGWXcmb463l9p1I9gO+riLTPU278h5eoOz+Rk+PKAKmHQitL7BTzhjyM pI0VfhfzmTQ13uvFgKV6qP+7NpUcpdZVaf111k1ufLK1x/TH2J+H54EhTXvVUaiO6XaUw0Kn I31FBJAlyjowjQtq9+wq10NnJVF2vLdi2MAVAAAAAAAA --------------ms030003080503020703070600-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 16:59:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05317 for ; Wed, 23 Oct 2002 16:59:51 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKpSb09163 for ietf-calendar-bks; Wed, 23 Oct 2002 13:51:28 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKpQW09159 for ; Wed, 23 Oct 2002 13:51:27 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id EEDDF155B4; Wed, 23 Oct 2002 22:51:27 +0200 (CEST) Date: Wed, 23 Oct 2002 22:51:27 +0200 From: Andrea Campi To: Doug Royer , ietf-calendar@imc.org Subject: [a.campi@inet.it: Another dubious example] Message-ID: <20021023205127.GA58630@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is still not fixed... ----- Forwarded message from Andrea Campi ----- Date: Thu, 1 Aug 2002 18:30:22 +0200 From: Andrea Campi To: ietf-calendar@imc.org Subject: Another dubious example Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, in 9.1.1 there's an example: In this example the initiator asks for the listeners capabilities. I: Content-Type: text/calendar I: I: BEGIN:VCALENDAR I: VERSION:2.0 I: PRODID:The CUA's PRODID I: CMD;ID=xyz12346:GET-CAPABILITY I: END:VCALENDAR # After 3 seconds L: Content-Type: text/calendar L: L: BEGIN:VCALENDAR L: VERSION:2.0 L: CMD;ID=xyz12346:TIMEOUT L: END:VCALENDAR This should probably be: I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy ----- End forwarded message ----- -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:02:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05390 for ; Wed, 23 Oct 2002 17:02:39 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKvDw09325 for ietf-calendar-bks; Wed, 23 Oct 2002 13:57:13 -0700 (PDT) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKvCW09321 for ; Wed, 23 Oct 2002 13:57:12 -0700 (PDT) In-Reply-To: <3DB5BC84.8080105@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: COUNTER - and who sent it. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 23 Oct 2002 16:57:12 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/23/2002 04:50:45 PM, Serialize complete at 10/23/2002 04:50:45 PM Content-Type: multipart/alternative; boundary="=_alternative 00734A9185256C5B_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00734A9185256C5B_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/22/2002 05:00:52 PM: > (1) We had this debate in 2000 and this group agreed that SENT-BY > should not be used - I posted Franks summary a week or two ago. > It and what led up to ATT-COUNTER is in the archives. I didnt see any traffic since ~9/27 and Im still digging out from my 2 week haitus and resulting email flood. I didnt see ATT-COUNTER in my search since it was referred to then as ATTCOUNTER w/o a hyphen. My main question was where did the proposal come from since I didnt see traffic on it (at least not for the past 2 years ;^) ). Im finally getting back into work mode and the lights are coming back on... > (2) The 'SENT-BY' could be from the original REQUEST and that > would override the who sent this 'COUNTER' to me. Please dont tell me you think that I should round trip the SENT-BY on my next REQUEST or DECLINE-COUNTER message. That wasnt the expectation for the use of SENT-BY when we created it. Its main use/intent is for detecting when someone responds on another users behalf (ie: the AA). I dont think anyone expects it to be 'round tripped' (although its not strictly illegal). See Franks note from the 08/29/2000 02:54:13 PM AST under the heading "iTIP: Who sent that message?" as refresher... > (3) 'SENT-BY' is limited to a 'mailto' url, ATT-COUNTER is not. Didnt see that much details in the posting I replied to or in Franks note from 08/29/2000 11:33:12 AM AST that I just found. Thats fine by me. > (4) The COUNTER object could be a COUNTER to an updated REQUEST > and might contain: > > METHOD:COUNTER > ... > > ATTENDEE:...SENT-BY="MAILTO:a@a.com" > ;PARTSTAT=accepted:MAILTO:a1@a.com > ATTENDEE:...SENT-BY="MAILTO:b@b.com" > ;PARTSTAT=accepted:MAILTO:b1@b.com > > ... > > So who sent the COUNTER? > Who do you send any DECLINECOUNTER to? You are assuming that SENT-BYs are preserved and round tripped ad-nauseum. I dont belive this to be true. They are only really useful between the sending CUA (their proxy actually) and the Organizer. They are not really that useful to any other entity in the process. (Do you _really_ need to know or care if I or my AA accepted as long as my PARTSTAT=ACCEPTED??) > Where as ATT-COUNTER is defined as who you send the accept or decline > counter back to, which would be the e-mail address from an iMIP message > and could also be a CAP URL. Something unclear from your posting: what are the restrictions on the new property? Franks proposal was for a new property but it had no clear definition (nor have I found one so far). Steve had suggested: Proposal 2: Add a new parameter to the ATTENDEE property: ATTCOUNTER. It can only be specified (a) when the component method is COUNTER and (b) for the one Attendee who issued the COUNTER. which all of us at the time liked. It made it very clear when ATTCOUNTER (ack ATT-COUNTER) could be used. One thing that noone has codified yet is "Does the ATT-COUNTER property value have to match a currently existing ATTENDEE value?" That is, does the ATT-COUNTER have to come from an ATTENDEE that the Organizer thinks is involved or can it come from just anyone? Since I could be COUNTERing that I should NOT be at an event its possible that the ATT-COUNTER does not match any ATTENDEE property I send back in my COUNTER but it SHOULD (MUST?) match my ATTENDEE property that the Organzier has on their copy of the event. Also, I assume that we are allowing a SENT-BY property parameter to be on ATT-COUTNER since its possible my AA is doing the COUNTERing. Do you agree? > It was so you knew who to send a DECLINECOUNTER to. Ya know, a simple "Go check your infamous FT archives for 'ATTCOUNTER' would have probably sufficed...". :^) 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 00734A9185256C5B_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/22/2002 05:00:52 PM:
> (1) We had this debate in 2000 and this group agreed that SENT-BY
>      should not be used - I posted Franks summary a week or two ago.
>      It and what led up to ATT-COUNTER is in the archives.
I didnt see any traffic since ~9/27 and Im still digging out from my 2 week haitus and resulting email flood.  I didnt see ATT-COUNTER in my search since it was referred to then as ATTCOUNTER w/o a hyphen.

My main question was where did the proposal come from since I didnt see traffic on it (at least not for the past 2 years ;^) ).  Im finally getting back into work mode and the lights are coming back on...

> (2) The 'SENT-BY' could be from the original REQUEST and that
>      would override the who sent this 'COUNTER' to me.
<DIGRESSION>
Please dont tell me you think that I should round trip the SENT-BY on my next REQUEST or DECLINE-COUNTER message.  That wasnt the expectation for the use of SENT-BY when we created it.  Its main use/intent is for detecting when someone responds on another users behalf (ie: the AA).  I dont think anyone expects it to be 'round tripped' (although its not strictly illegal).  See Franks note from the 08/29/2000 02:54:13 PM AST under the heading "iTIP: Who sent that message?" as refresher...
</DIGRESSION>

> (3) 'SENT-BY' is limited to a 'mailto' url, ATT-COUNTER is not.
Didnt see that much details in the posting I replied to or in Franks note from 08/29/2000 11:33:12 AM AST that I just found.  Thats fine by me.

> (4) The COUNTER object could be a COUNTER to an updated REQUEST
>      and might contain:
>
>       METHOD:COUNTER
>       ...
>
>       ATTENDEE:...SENT-BY="MAILTO:a@a.com"
>                   ;PARTSTAT=accepted:MAILTO:a1@a.com
>       ATTENDEE:...SENT-BY="MAILTO:b@b.com"
>                   ;PARTSTAT=accepted:MAILTO:b1@b.com
>
>       ...
>
>     So who sent the COUNTER?
>     Who do you send any DECLINECOUNTER to?
You are assuming that SENT-BYs are preserved and round tripped ad-nauseum.  I dont belive this to be true.  They are only really useful between the sending CUA (their proxy actually) and the Organizer.  They are not really that useful to any other entity in the process.  (Do you _really_ need to know or care if I or my AA accepted as long as my PARTSTAT=ACCEPTED??)

> Where as ATT-COUNTER is defined as who you send the accept or decline
> counter back to, which would be the e-mail address from an iMIP message
> and could also be a CAP URL.
Something unclear from your posting: what are the restrictions on the new property?  Franks proposal was for a new property but it had no clear definition (nor have I found one so far).  Steve had suggested:

Proposal 2: Add a new parameter to the ATTENDEE
property:  ATTCOUNTER.  It can only be specified (a)
when the component method is COUNTER and (b) for the
one Attendee who issued the COUNTER.

which all of us at the time liked.  It made it very clear when ATTCOUNTER (ack ATT-COUNTER) could be used.  

One thing that noone has codified yet is "Does the ATT-COUNTER property value have to match a currently existing ATTENDEE value?"  That is, does the ATT-COUNTER have to come from an ATTENDEE that the Organizer thinks is involved or can it come from just anyone?  Since I could be COUNTERing that I should NOT be at an event its possible that the ATT-COUNTER does not match any ATTENDEE property I send back in my COUNTER but it SHOULD (MUST?) match my ATTENDEE property that the Organzier has on their copy of the event.

Also, I assume that we are allowing a SENT-BY property parameter to be on ATT-COUTNER since its possible my AA is doing the COUNTERing.  Do you agree?

> It was so you knew who to send a DECLINECOUNTER to.
Ya know, a simple "Go check your infamous FT archives for 'ATTCOUNTER' would have probably sufficed...". :^)

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 00734A9185256C5B_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:03:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05448 for ; Wed, 23 Oct 2002 17:03:24 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKqZK09193 for ietf-calendar-bks; Wed, 23 Oct 2002 13:52:35 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKqYW09189 for ; Wed, 23 Oct 2002 13:52:34 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NKqZqN007798 for ; Wed, 23 Oct 2002 13:52:36 -0700 Message-ID: <3DB70C11.6070206@Royer.com> Date: Wed, 23 Oct 2002 14:52:33 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{txt,html} References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080202040206060809030105" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080202040206060809030105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As the November 4th is a Monday, I propose that 'our' cut off date be the 1st of November. It does not mean that CAP can not change or be updated. The 1st will be for when 'the -09 version does not change'. As the error codes will be the last to be updated. We might be able to go to final call in -10. pregen@egenconsulting.com wrote: > > We should wait for changes to be made that match what the list wants. > That's why I posted my comments > > Here's what the IETF sent as the deadline. NOte that they ask for no > last minutes submissions. We fall into the 11/4 deadline date. > > > > > Please do NOT wait until the last minute to submit. > > > >Be advised: NO placeholders. Updates to initial submissions received > > the week of October 28th will NOT be accepted. > > > >November 4th: FINAL Internet-Draft Cutoff > --------------ms080202040206060809030105 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIwNTIzM1owIwYJKoZIhvcNAQkEMRYEFCYXm9nM VWWHANw2QphnZbC6bKodMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQDAez2nsdCEG/4lDRjs KZ7zRx9ZDligxefuWsyanebOjdHeNxwdONTSTrM/3jTY6azR82dKuryWpqFA4fiADt34EpJb ohpxKs8GoVSwiqiPtYbp0shgpsSPo4DZBJUqvcmom0vOIFRgNNGaP8qXZprcxCdPV/GFjlp9 keYEph9TYmsX4ehTeSzhzyW8S3DBulges6GVXAQt7O3mHNnyS4epEIdJ2qnTNN6TTjf5zvhZ F4LcGTR0BBbeOw3TlgUX9KzZmFlIVkdQ6wGYViqAGunMkVExuM5AZnABYC9NT6KUWNPjszn7 xUHUYOh7hTMnhcjAbAkwTdS9ZlugeOwu81IiAAAAAAAA --------------ms080202040206060809030105-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:03:25 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05450 for ; Wed, 23 Oct 2002 17:03:24 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NKuBV09294 for ietf-calendar-bks; Wed, 23 Oct 2002 13:56:11 -0700 (PDT) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NKuAW09290 for ; Wed, 23 Oct 2002 13:56:10 -0700 (PDT) Received: by acampi.inet.it (Postfix, from userid 210) id 39149155B4; Wed, 23 Oct 2002 22:56:12 +0200 (CEST) Date: Wed, 23 Oct 2002 22:56:12 +0200 From: Andrea Campi To: Doug Royer , ietf-calendar@imc.org Subject: [a.campi@inet.it: Question about iTIP + VCARs] Message-ID: <20021023205612.GB58630@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, this (copied from an old message) is still not fixed (you agreed it should be fixed). ----- Forwarded message from Andrea Campi ----- BEGIN:VCAR CARID:REQUESTONLY BEGIN:VRIGHT GRANT:NONOWNER PERMISSION:WRITE RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' END:VRIGHT END:VCAR [...] Should this be written as: BEGIN:VCAR CARID:REQUESTONLY BEGIN:VRIGHT GRANT:NONOWNER PERMISSION:WRITE RESTRICTION:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' RESTRICTION:SELECT * FROM VTODO WHERE METHOD = 'REQUEST' RESTRICTION:SELECT * FROM VJOURNAL WHERE METHOD = 'REQUEST' END:VRIGHT END:VCAR Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. http://www.inet.it Direzione Tecnica - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy ----- End forwarded message ----- -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:12:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05614 for ; Wed, 23 Oct 2002 17:12:52 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NL5jh09592 for ietf-calendar-bks; Wed, 23 Oct 2002 14:05:45 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NL5hW09588 for ; Wed, 23 Oct 2002 14:05:43 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NL5jqN007906 for ; Wed, 23 Oct 2002 14:05:45 -0700 Message-ID: <3DB70F26.4060209@Royer.com> Date: Wed, 23 Oct 2002 15:05:42 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 8.6. VQUERY Component References: <0962A384-E6C8-11D6-BB10-003065A8EEFC@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030903080407050904040902" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030903080407050904040902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks your right - I forgot that one. When creating ANY object, the TARGET in the VCALENDAR component is already supplied - so TARGET would ONLY be used when performing a search in one TARGET with the query being stored in another TARGET. Here is what I added/changed: queryc = "BEGIN" ":" "VQUERY" CRLF queryprop "END" ":" "VCAR" CRLF queryprop = 1*( ; 'queryid' is OPTIONAL but MUST NOT occur ; more than once. If the "TARGET" property ; is supplied then the "QUERYID" property ; MUST BE supplied. ; queryid / target ; the following are OPTIONAL, and MAY occur ; more than once ; / name / x-prop / iana-prop ; the following MUST occur at least once. ; / query ) AND I then added these two paragraphs: For a search using a named query, if the "TARGET" property is supplied in a "VQUERY" component, then the CS is to search for the query in the calid supplied by the "TARGET" property value. For a create the "TARGET" property MUST NOT be supplied as the destination container is already supplied in the "TARGET" property of the "VCALENDAR" component. Andrea Campi wrote: > Hi Doug, > > back in August Patrice Lapierre proposed > (<1028739969.18782.107.camel@c-1241.in.steltor.com>) to add a TARGET > property to the VQUERY component to determine where to look for a named > stored VQUERY. You agreed, I agree, and nobody objected. > Later on, in September, I posted a reminder with a proposed ABNF (in > <20020904164954.GB26483@inet.it>) and again nobody objected. > So I'd say, let's do it: > --------------ms030903080407050904040902 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIxMDU0MlowIwYJKoZIhvcNAQkEMRYEFMInJF9n OAdVEB0bm4sR/BZ0K3YrMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQDAgt7u00amv9RaSj08 7HhPYMKXFXKpBaNHlSRlj3hX2GLten08zc3HP9flhPtacIlQHgDzFj2Vrp5CcQzvmygVPxhH CPF03FbAWh67zI9+xY7UY2qs74ODg35hQ+JHMQILQ61xHrIS3MUwfyvG6GdRWKK5xJ3foThh 4RiV1yOA3vRX9iYnbEvgKnlo18TBjUY8r4hiqzrRxEcen2apkE4cEoPuu69c6OBfi1qRy+jj JUOqStZd9+wjjgJgEI3KR99j6UfAm9ZSvEBSqNLhRtxZWHshF9J7hpPid53xz7wDE3Nxxc9X p8r6OUuBZEcaaKdh+xPY+zzWobmKFdqkaE3UAAAAAAAA --------------ms030903080407050904040902-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:20:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05777 for ; Wed, 23 Oct 2002 17:20:09 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NLCgr09836 for ietf-calendar-bks; Wed, 23 Oct 2002 14:12:42 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NLCeW09830 for ; Wed, 23 Oct 2002 14:12:40 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NLCfqN007971 for ; Wed, 23 Oct 2002 14:12:42 -0700 Message-ID: <3DB710C6.7080608@Royer.com> Date: Wed, 23 Oct 2002 15:12:38 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 9.5 MODIFY Command References: <82462C34-E6C2-11D6-B6A3-003065A8EEFC@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080303020901020804050603" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080303020901020804050603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It does not need an ABNF, but I just added: Response: A "VCALENDAR" component is returned with one ore more "REQUEST-STATUS" property values. Andrea Campi wrote: > > Hi Doug, > > as I wrote in <20020905100246.GA29009@inet.it>, MODIFY doesn't have an > ABNF for reply. I do realize it might be too late to fix this in this > draft, and I'm not sure I'd be able to come up with an ok ABNF, so I > just wanted to bring this up again so we don't forget. > > Bye, > Andrea -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms080303020901020804050603 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIxMTIzOVowIwYJKoZIhvcNAQkEMRYEFIiDFrP5 YPVm0wwDgM/Tn/b4cI3wMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBwS1Lozg2hnyfUXrkV jkiKb8YAq4+bqInglK4jTgtFMTgO0eO5VRoYtb3KRw9tVrvlSWlp65AIIQNzBscm5DOtK3mK BxPyJG+P/DKqGi7Ug87WURcIDHkq0zQ8c8g0gyYwO+9MQGKtylD9AFEyqnIN9IJW8YCjMAz9 VsGY9Ro7s0QQ70uETp+IuUVMl9eRYXHRycI/ziC3qP4NJUBP8MHeXi6fGbQ5YZ7NEcOpewZe bDgsKmqPkP9K6kw8sXG5u3X9WcbPQn4Ch1Yh4EXsehOOEK2XOUZy7+9vbrJkxml8YJ43cVEa y7Lzb3vP/1MMNLMXLRuA4UFJuIivJVJtUSr4AAAAAAAA --------------ms080303020901020804050603-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:20:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05791 for ; Wed, 23 Oct 2002 17:20:26 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NLFO110010 for ietf-calendar-bks; Wed, 23 Oct 2002 14:15:24 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NLFNW10006 for ; Wed, 23 Oct 2002 14:15:23 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NLFPqN007993 for ; Wed, 23 Oct 2002 14:15:25 -0700 Message-ID: <3DB7116A.80207@Royer.com> Date: Wed, 23 Oct 2002 15:15:22 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [a.campi@inet.it: Another dubious example] References: <20021023205127.GA58630@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030300070006080502090900" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030300070006080502090900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > This is still not fixed... It is now :-) --------------ms030300070006080502090900 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIxMTUyMlowIwYJKoZIhvcNAQkEMRYEFL6Nqkv7 ZFUQfn7T0xx942pHQdMnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCSXQj7cYKI17efxnty ZPhOq44aQXkUOFFNSCK7MRJuM1I2xkS4XeT018hQdCJM/5xeflTzEOh9YRjjQTDCvbYNTOrK 1ZFbFoNzH748MQIY7Mmvmbpy7EM78eF6UVzbowvukP9PgrAMbm2x2IbwonyX9x+eqsziOBcr REZ0CoQ/16vNd+NLCwuAl/yU6m1QidPgj/MDwIPFZZN8R86EKPiEeLaUcJrJBred6R2pB8z5 0PDSI6up/t+ScLAJXplAoPpP6qNNxCG4Pg4kwDEJoyd1H0edbrmLd+2gh2Qyma2qFQJIOsDX /kvbGzurcSPCOzqFE92QpK7m+Ml2U1fYIDTXAAAAAAAA --------------ms030300070006080502090900-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:30:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06058 for ; Wed, 23 Oct 2002 17:30:42 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NLNko10257 for ietf-calendar-bks; Wed, 23 Oct 2002 14:23:46 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NLNjW10252 for ; Wed, 23 Oct 2002 14:23:45 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NLNkqN008054 for ; Wed, 23 Oct 2002 14:23:47 -0700 Message-ID: <3DB71360.5090805@Royer.com> Date: Wed, 23 Oct 2002 15:23:44 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [a.campi@inet.it: Question about iTIP + VCARs] References: <20021023205612.GB58630@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010209020503000008080305" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010209020503000008080305 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit There is no such example (no example has PERMISSION:WRITE in it) While looking for it, I did notice that some of the examples still had "READ" and not "SEARCH". I replaced all "READ"s with "SEARCH" as there is no "READ" command. The 'REQUESTONLY' example has PERMISSION:CREATE. And why is the RESTRICTION value in the REQUESTONLY CARID not valid? Andrea Campi wrote: > Hi, > > this (copied from an old message) is still not fixed (you agreed > it should be fixed). > > ----- Forwarded message from Andrea Campi ----- > > BEGIN:VCAR > CARID:REQUESTONLY > BEGIN:VRIGHT > GRANT:NONOWNER > PERMISSION:WRITE > RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' > END:VRIGHT > END:VCAR > > [...] > > Should this be written as: > > BEGIN:VCAR > CARID:REQUESTONLY > BEGIN:VRIGHT > GRANT:NONOWNER > PERMISSION:WRITE > RESTRICTION:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' > RESTRICTION:SELECT * FROM VTODO WHERE METHOD = 'REQUEST' > RESTRICTION:SELECT * FROM VJOURNAL WHERE METHOD = 'REQUEST' > END:VRIGHT > END:VCAR > > > Bye, > Andrea > > -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms010209020503000008080305 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIxMjM0NFowIwYJKoZIhvcNAQkEMRYEFC31sjJ0 pZGmSVc0HrbAKrIPyx9dMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBtAlIJY2sshiMu21My aHFp5AIlISy0IMIk2aUeS5W59Nv78DDKOYFLb8tAQJ6hyW1GwB7dGzNJV9HinRfcP12I1HyG 3eJgP8wy547Vae9q/IvtLTdBOuVrv5vhu8IYfaNm+ZAL7V6gTO1p2tANqkc6lb3/aHPV5lRS t59+xzTBLpjHmi/CDcavDSnzuvvQVA9204dZ4Kz5wCvYwrPj7lKI7dViAmvM6LiiuAeZ7tL8 dXF0oH/GRdg+/yy/SrRM2rhq65Iq4KitM5ghVaRtZSndWIxtY3Bw+uKz8jtaWuROZEASjoSn mpKXTaI1HqPFpDHJ2ocPk6uz1M660CeR4XunAAAAAAAA --------------ms010209020503000008080305-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:42:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06273 for ; Wed, 23 Oct 2002 17:42:53 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NLXMw10474 for ietf-calendar-bks; Wed, 23 Oct 2002 14:33:22 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NLXKW10469 for ; Wed, 23 Oct 2002 14:33:21 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NLXMqN008121 for ; Wed, 23 Oct 2002 14:33:23 -0700 Message-ID: <3DB715A0.5080300@Royer.com> Date: Wed, 23 Oct 2002 15:33:20 -0600 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060804070602040001030108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060804070602040001030108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 10/22/2002 05:00:52 PM: > > (1) We had this debate in 2000 and this group agreed that SENT-BY > > should not be used - I posted Franks summary a week or two ago. > > It and what led up to ATT-COUNTER is in the archives. > > I didnt see any traffic since ~9/27 and Im still digging out from my 2 > week haitus and resulting email flood. I didnt see ATT-COUNTER in my > search since it was referred to then as ATTCOUNTER w/o a hyphen. The debate was in 2000. > > (4) The COUNTER object could be a COUNTER to an updated REQUEST > > and might contain: > > > > METHOD:COUNTER > > ... > > > > ATTENDEE:...SENT-BY="MAILTO:a@a.com" > > ;PARTSTAT=accepted:MAILTO:a1@a.com > > ATTENDEE:...SENT-BY="MAILTO:b@b.com" > > ;PARTSTAT=accepted:MAILTO:b1@b.com > > > > ... > > > > So who sent the COUNTER? > > Who do you send any DECLINECOUNTER to? > > You are assuming that SENT-BYs are preserved and round tripped > ad-nauseum. I dont belive this to be true. They are only really useful > between the sending CUA (their proxy actually) and the Organizer. They > are not really that useful to any other entity in the process. (Do you > _really_ need to know or care if I or my AA accepted as long as my > PARTSTAT=ACCEPTED??) Do you think that it is invalid for the ORGANIZER to get a COUNTER and have to keep both the SENT-BY values for all the ATTENDEEs and to know who sent the COUNTER? If no - then you are agreeing that SENT-BY is not sufficient. If it is valid to keep them (and I think it is), then SENT-BY can not work to remember who sent the COUNTER when the ORGANIZER might have several SENT-BY values already in the object. > One thing that noone has codified yet is "Does the ATT-COUNTER property > value have to match a currently existing ATTENDEE value?" That is, does > the ATT-COUNTER have to come from an ATTENDEE that the Organizer thinks > is involved or can it come from just anyone? Since I could be > COUNTERing that I should NOT be at an event its possible that the > ATT-COUNTER does not match any ATTENDEE property I send back in my > COUNTER but it SHOULD (MUST?) match my ATTENDEE property that the > Organzier has on their copy of the event. There is a entire "ATT-COUNTER" section in -09 (7.2), it seems clear to me that it comes from the cal-address that sent the COUNTER. Did you miss that section? Or are you saying that is not what you get when you read that section? > Also, I assume that we are allowing a SENT-BY property parameter to be > on ATT-COUTNER since its possible my AA is doing the COUNTERing. Do you > agree? Yes. --------------ms060804070602040001030108 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIxMzMyMFowIwYJKoZIhvcNAQkEMRYEFKpfyWBS Q2zZlHhR2umz8tZftW6GMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBP1NUEWlzeWPvn12bD HxY5myv0pBifQc1lnPYF5Sh5W7K9eAzNDisrThDPsw03oerfxVHnowED9wmUJEabQCwga7bI +BK/MeNlxZ+sLTQZNWoZuvbHwxOiVbZO8VzFd4f/LANolkD0mVmN6GKkhXaIwrDFcsc2zhti nEJJmIqG6mYMoRCzWNyhF8XStSZEUw9jREgfZgjUtwPFU/FrhpcPrFIpDrl8LAotfsRXOwdZ kqoVgv5+Ykpikpvr2bBjNOFms3Kj8t7rlPn3P2rMbRqSkBXgEfhKly8b/9hPMvtfD3T5bLuN HJk11TylBNQhD3r024M8kL1zQkxmyK78oaPqAAAAAAAA --------------ms060804070602040001030108-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:43:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06326 for ; Wed, 23 Oct 2002 17:43:48 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NLd6Y10747 for ietf-calendar-bks; Wed, 23 Oct 2002 14:39:06 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NLd4W10741 for ; Wed, 23 Oct 2002 14:39:04 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9NLd61N008737; Wed, 23 Oct 2002 23:39:06 +0200 Date: Wed, 23 Oct 2002 23:36:15 +0200 Subject: CAL-QUERY again Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Doug Royer From: Andrea Campi Content-Transfer-Encoding: 7bit Message-Id: <753F139D-E6CF-11D6-BB10-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Doug, as mentioned before, I think we should change the definition for literal-data: literal-data = ; Any data that matches the value type of the ; column that is being compared. That is you can ; not compare PRIORITY to "some string" because ; PRIORITY has a value type of integer. If it is ; not preceded by the LIKE element, any '%' and '_' ; characters in the literal data are not treated as ; wildcard characters and do not have to be backslash ; escaped. ..... to something like: literal-data = ; Any data that matches the value type of the ; column that is being compared. That is you can ; not compare PRIORITY to "some string" because ; PRIORITY has a value type of integer. Enumerated ; types are considered the same as text strings. Bye, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:46:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06397 for ; Wed, 23 Oct 2002 17:46:49 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NLcvn10723 for ietf-calendar-bks; Wed, 23 Oct 2002 14:38:57 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NLcuW10715 for ; Wed, 23 Oct 2002 14:38:56 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9NLcq1N008709; Wed, 23 Oct 2002 23:38:53 +0200 Date: Wed, 23 Oct 2002 23:32:08 +0200 Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt Content-Type: multipart/alternative; boundary=Apple-Mail-4--880529698 Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Bruce_Kahn@notesdev.ibm.com From: Andrea Campi In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-4--880529698 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Wednesday, October 23, 2002, at 10:21 PM,=20 Bruce_Kahn@notesdev.ibm.com wrote: > > I agree w/Andrea on this one. =A0 > > [...] > > I cant think of any reason why a CUA would not be reasonably able to=20= > implement a GET-CAPABILITY handler so why shouldnt this be a MUST=20 > also?... =A0After all any 'lightweight' CUA that doesnt do much can = very=20 > easily code up a simple handler that sends back "I only support plain=20= > VEVENTs and nothing more" in only a few lines of code. =A0Its probably=20= > the 1st routine to get coded as folks build their CUA so why not make=20= > it MUST?? Now wait a minute ;-) In fact I like the wording in the latest document=20= (CUA MAY reply not implemented). I already gave an example for why a CUA would want to have NO handler=20 at all: a CGI interface to show a read only view of a specific calendar=20= (think user group meeting schedule) could be written in a few hundreds=20= lines of code, and would hopefully be quite fast. I agree a=20 GET-CAPABILITY handler wouldn't add much; but if it has no need to, why=20= force it to have this unneeded fat?? Bye, Andrea= --Apple-Mail-4--880529698 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, October 23, 2002, at 10:21 PM, Bruce_Kahn@notesdev.ibm.com wrote: I agree w/Andrea on this one. =A0 [...] I cant think of any reason why a CUA would not be reasonably able to implement a GET-CAPABILITY handler so why shouldnt this be a MUST also?... =A0After all any 'lightweight' CUA that doesnt do much can very easily code up a simple handler that sends back "I only support plain VEVENTs and nothing more" in only a few lines of code. =A0Its probably the 1st routine to get coded as folks build their CUA so why not make it MUST?? Now wait a minute ;-) In fact I like the wording in the latest document (CUA MAY reply not implemented). I already gave an example for why a CUA would want to have NO handler at all: a CGI interface to show a read only view of a specific calendar (think user group meeting schedule) could be written in a few hundreds lines of code, and would hopefully be quite fast. I agree a GET-CAPABILITY handler wouldn't add much; but if it has no need to, why force it to have this unneeded fat?? Bye, Andrea= --Apple-Mail-4--880529698-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 17:49:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06453 for ; Wed, 23 Oct 2002 17:49:05 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NLi2511421 for ietf-calendar-bks; Wed, 23 Oct 2002 14:44:02 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NLi1W11412 for ; Wed, 23 Oct 2002 14:44:01 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9NLi21N009191; Wed, 23 Oct 2002 23:44:02 +0200 Date: Wed, 23 Oct 2002 23:43:56 +0200 Subject: GET-CAPABILITY Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ietf-calendar@imc.org To: Doug Royer From: Andrea Campi Content-Transfer-Encoding: 7bit Message-Id: <882D629A-E6D0-11D6-9D76-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Doug, In <20020712090933.GF46205@inet.it> I proposed to change QUERY-LEVEL to have values CAL-QL-1 or CAL-QL-NONE (instead of CAL-QL-1 or NONE). You and John Stracke agreed and there was no objection. Also, John proposed to removed the following sentence: If set to NONE, then the 'car' capability MUST BE set to NONE. I agree and there was no objection. Rationale is that CS's that only allow components to be deposited may still want to enforce VCAR protection. Bye, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 18:01:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06823 for ; Wed, 23 Oct 2002 18:01:20 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NLsr912398 for ietf-calendar-bks; Wed, 23 Oct 2002 14:54:53 -0700 (PDT) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NLsqW12392 for ; Wed, 23 Oct 2002 14:54:52 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g9NLsqjJ002464 for ; Wed, 23 Oct 2002 23:54:53 +0200 Date: Wed, 23 Oct 2002 23:54:48 +0200 Subject: Re: 8.6. VQUERY Component Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Andrea Campi To: ietf-calendar@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <3DB70F26.4060209@Royer.com> Message-Id: <0CF95CC1-E6D2-11D6-9D76-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, October 23, 2002, at 11:05 PM, Doug Royer wrote: > > > Thanks your right - I forgot that one. > > When creating ANY object, the TARGET in the VCALENDAR component > is already supplied - so TARGET would ONLY be used when performing > a search in one TARGET with the query being stored in another TARGET. > You are right, and I like your changes. Thanks, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 18:07:15 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06948 for ; Wed, 23 Oct 2002 18:07:14 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NLt9F12442 for ietf-calendar-bks; Wed, 23 Oct 2002 14:55:09 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NLt8W12435 for ; Wed, 23 Oct 2002 14:55:08 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NLtAqN008338 for ; Wed, 23 Oct 2002 14:55:10 -0700 Message-ID: <3DB71ABB.6050203@Royer.com> Date: Wed, 23 Oct 2002 15:55:07 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY References: <882D629A-E6D0-11D6-9D76-003065A8EEFC@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070608020901020709080502" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070608020901020709080502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > Hi Doug, > > In <20020712090933.GF46205@inet.it> I proposed to change QUERY-LEVEL to > have values CAL-QL-1 or CAL-QL-NONE (instead of CAL-QL-1 or NONE). You > and John Stracke agreed and there was no objection. Your right - I just changed 'NONE' to 'CAL-QL-NONE'. > Also, John proposed to removed the following sentence: > > If set to NONE, then the 'car' capability MUST BE set to NONE. Yep - I forgot - fixed. > I agree and there was no objection. Rationale is that CS's that only > allow components to be deposited may still want to enforce VCAR protection. > > Bye, > Andrea -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070608020901020709080502 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIxNTUwN1owIwYJKoZIhvcNAQkEMRYEFC1PI642 MAkyoVtodr/TQI33sM0SMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCenXoiUhaEJ5RMQyBt M+0Pb/dcFknMBI2r1qnDjnblvBDYIj4/96Rr6HwESYBYh1hO8f6b9nPlZBhCoYnANiSk2SWj 3EnXgcPzrHV/J2odT5rfZHDpxMc5YnEZavNq2e3Jrm8q2X1ku9JtOTrJl4rkjq8+vUdX6eGs oQu0mrmfX7uIYyB5aw7WHm8xt0avsu5KbzDBy4MtTD42SznAvt6X7k/Gx5A3SyoVQbcL61C+ UwapVNaRQWr+ujtj2+mi6iU3yc8F4spwnne9h4tqpkxGy57l+eP4ZV93T3TwFdLfz3wQ/YOr thU9mWZeNS70SCOdeAvRFmmiDSCZEnR33B1jAAAAAAAA --------------ms070608020901020709080502-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 18:27:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07151 for ; Wed, 23 Oct 2002 18:27:05 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NMHmJ15114 for ietf-calendar-bks; Wed, 23 Oct 2002 15:17:48 -0700 (PDT) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NMHkW15108 for ; Wed, 23 Oct 2002 15:17:46 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g9NMHkjJ006235 for ; Thu, 24 Oct 2002 00:17:47 +0200 Date: Thu, 24 Oct 2002 00:17:43 +0200 Subject: Re: [a.campi@inet.it: Question about iTIP + VCARs] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Andrea Campi To: ietf-calendar@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <3DB71360.5090805@Royer.com> Message-Id: <400FC42A-E6D5-11D6-9D76-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, October 23, 2002, at 11:23 PM, Doug Royer wrote: > > There is no such example (no example has PERMISSION:WRITE in it) Right... I copied it from an old message, so that part might have changed... It's now: BEGIN:VCAR CARID:REQUESTONLY BEGIN:VRIGHT GRANT:NON CAL-OWNERS() PERMISSION:CREATE RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' END:VRIGHT END:VCAR > And why is the RESTRICTION value in the REQUESTONLY CARID not valid? Well, for one, VCALENDAR is not in comp-name in the ABNF for CAL-QUERY value type. Also, if looking for an iTIP component, it's arguably more correct to use: SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' Bye, Andrea > > > Andrea Campi wrote: >> Hi, >> this (copied from an old message) is still not fixed (you agreed >> it should be fixed). >> ----- Forwarded message from Andrea Campi ----- >> BEGIN:VCAR >> CARID:REQUESTONLY >> BEGIN:VRIGHT >> GRANT:NONOWNER >> PERMISSION:WRITE >> RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = >> 'REQUEST' >> END:VRIGHT >> END:VCAR >> [...] >> Should this be written as: >> BEGIN:VCAR >> CARID:REQUESTONLY >> BEGIN:VRIGHT >> GRANT:NONOWNER >> PERMISSION:WRITE >> RESTRICTION:SELECT * FROM VEVENT WHERE METHOD = >> 'REQUEST' >> RESTRICTION:SELECT * FROM VTODO WHERE METHOD = >> 'REQUEST' >> RESTRICTION:SELECT * FROM VJOURNAL WHERE METHOD = >> 'REQUEST' >> END:VRIGHT >> END:VCAR >> Bye, >> Andrea > > > -- > - > Doug Royer Work: (208)612-INET > Doug@Royer.com Fax: (866)594-8574 > http://INET-Consulting.com Cell: (208)520-4044 > http://Royer.com/People/Doug > From owner-ietf-calendar@mail.imc.org Wed Oct 23 18:34:55 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07216 for ; Wed, 23 Oct 2002 18:34:55 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NMLSg15530 for ietf-calendar-bks; Wed, 23 Oct 2002 15:21:28 -0700 (PDT) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NMLRW15525 for ; Wed, 23 Oct 2002 15:21:27 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g9NMLRjJ006867 for ; Thu, 24 Oct 2002 00:21:27 +0200 Date: Thu, 24 Oct 2002 00:21:23 +0200 Subject: Re: 9.5 MODIFY Command Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Andrea Campi To: ietf-calendar@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <3DB710C6.7080608@Royer.com> Message-Id: X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, October 23, 2002, at 11:12 PM, Doug Royer wrote: > > It does not need an ABNF, but I just added: Well, most other commands have a definition for *-reply, so for consistency at least, I would expect a modify-reply, too. > > Response: > > A "VCALENDAR" component is returned with one ore more > "REQUEST-STATUS" > property values. Sorry but the reply should contain a lot more than the REQUEST-STATUS, as the description says. It's still not very clear to me WHAT should be in the reply, so I guess this badly needs more details... Bye, Andrea > > > Andrea Campi wrote: >> Hi Doug, >> as I wrote in <20020905100246.GA29009@inet.it>, MODIFY doesn't have >> an ABNF for reply. I do realize it might be too late to fix this in >> this draft, and I'm not sure I'd be able to come up with an ok ABNF, >> so I just wanted to bring this up again so we don't forget. >> Bye, >> Andrea > > > -- > - > Doug Royer Work: (208)612-INET > Doug@Royer.com Fax: (866)594-8574 > http://INET-Consulting.com Cell: (208)520-4044 > http://Royer.com/People/Doug > From owner-ietf-calendar@mail.imc.org Wed Oct 23 18:55:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07487 for ; Wed, 23 Oct 2002 18:55:46 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NMmqt16447 for ietf-calendar-bks; Wed, 23 Oct 2002 15:48:52 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NMmpW16443 for ; Wed, 23 Oct 2002 15:48:51 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NMmrqN008715 for ; Wed, 23 Oct 2002 15:48:53 -0700 Message-ID: <3DB72752.7030303@Royer.com> Date: Wed, 23 Oct 2002 16:48:50 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: [a.campi@inet.it: Question about iTIP + VCARs] References: <400FC42A-E6D5-11D6-9D76-003065A8EEFC@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070009030303030009040207" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070009030303030009040207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > >> And why is the RESTRICTION value in the REQUESTONLY CARID not valid? > > > Well, for one, VCALENDAR is not in comp-name in the ABNF for CAL-QUERY > value type. Also, if looking for an iTIP component, it's arguably more > correct to use: > > SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' Or perhaps: SELECT VEVENT FROM VAGENDA WHERE METHOD = 'REQUEST' SELECT VTODO FROM VAGENDA WHERE METHOD = 'REQUEST' SELECT VJOURNAL FROM VAGENDA WHERE METHOD = 'REQUEST' As: SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' Would have given you the properties in VEVENTs and not the components. --------------ms070009030303030009040207 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIyNDg1MFowIwYJKoZIhvcNAQkEMRYEFMzZdRXh mVCRLQR4i9BGtnsEgPIWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAH3MqXZKUdmpo8Gikm 384fHu7mOdVKSAA+clkLRgR4vzuyOq6KSoCP+uHqYW1jw4ZuPukICwUkAEKH+ciHIujHWMpt s0piq6d/eJ5d/WjGJl0KDC5KpdsSJuzkZoC5Y6c768h0DDsRMZTQhkxtgcIYQWOsesgMNblN naSWclvh5faKoLBBiWN3/CmREATZLEbtk1Ar0f0Kqhi9Ru2h/UdB9oUoXhxq6CeB60l3xCAv lYN9GFvT+TXhHslqhon0jujmyHoU+tOipwsA8Z1SUc+d6WyEd550hYMDnA1r6CcQL40iGpLt 83UzEN+rNkoE1VAvfULzTJ80XgA8Rtc69YZZAAAAAAAA --------------ms070009030303030009040207-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 19:10:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07636 for ; Wed, 23 Oct 2002 19:09:59 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9NMtJH16677 for ietf-calendar-bks; Wed, 23 Oct 2002 15:55:19 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9NMtIW16673 for ; Wed, 23 Oct 2002 15:55:18 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9NMtKqN008772 for ; Wed, 23 Oct 2002 15:55:21 -0700 Message-ID: <3DB728D6.2040200@Royer.com> Date: Wed, 23 Oct 2002 16:55:18 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 9.5 MODIFY Command References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010504030908050106000700" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010504030908050106000700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >> >> A "VCALENDAR" component is returned with one ore more >> "REQUEST-STATUS" >> property values. > > > Sorry but the reply should contain a lot more than the REQUEST-STATUS, > as the description says. It's still not very clear to me WHAT should be > in the reply, so I guess this badly needs more details... What else would be included? The MODIFY succeeds or fails, but it does not return any data. --------------ms010504030908050106000700 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyMzIyNTUxOFowIwYJKoZIhvcNAQkEMRYEFLW51wUP nW3mKJhvcXAgrh/CQAAyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAIByYZiIx4l2g61mRs blzeRLAhJcUIxupjQSMahyZM9iEsyrlegyHAhyPdTiZFoiSa6WrEOlG6J4SC5Zuvllgg8c/M WdC4+mA2LP+/rvMB5nSRFQA2K4+hAqnWxdZof/ocLBgRARteW/j2BF+2xukOwSvL/fwn+Hdy VSEwSeqYkr/PcJVmdB8zWl++ptF91tpVDHzlci8xSsc4TuypyDQn25pl6adjE4e0Os9VH57P VZIVSsxDo2Oo6ZdXgz4aqQO99HJ+D5j5lJRP6ITGhIBnYhPaVQTvIVbx9Tv1DdhNd9+IW4Ap 7UbPkerVdjlOh5+TtusMFhXwIdtjsjcW7/vKAAAAAAAA --------------ms010504030908050106000700-- From owner-ietf-calendar@mail.imc.org Wed Oct 23 20:17:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08778 for ; Wed, 23 Oct 2002 20:17:57 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O01o717986 for ietf-calendar-bks; Wed, 23 Oct 2002 17:01:50 -0700 (PDT) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9O01nW17981 for ; Wed, 23 Oct 2002 17:01:49 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g9O01njJ020146 for ; Thu, 24 Oct 2002 02:01:50 +0200 Date: Thu, 24 Oct 2002 02:01:45 +0200 Subject: Re: [a.campi@inet.it: Question about iTIP + VCARs] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Andrea Campi To: ietf-calendar@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <3DB72752.7030303@Royer.com> Message-Id: X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thursday, October 24, 2002, at 12:48 AM, Doug Royer wrote: > Andrea Campi wrote: >> >>> And why is the RESTRICTION value in the REQUESTONLY CARID not valid? >> Well, for one, VCALENDAR is not in comp-name in the ABNF for >> CAL-QUERY value type. Also, if looking for an iTIP component, it's >> arguably more correct to use: >> SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' > > Or perhaps: > > > SELECT VEVENT FROM VAGENDA WHERE METHOD = 'REQUEST' > SELECT VTODO FROM VAGENDA WHERE METHOD = 'REQUEST' > SELECT VJOURNAL FROM VAGENDA WHERE METHOD = 'REQUEST' > > As: > > SELECT * FROM VEVENT WHERE METHOD = 'REQUEST' > > Would have given you the properties in VEVENTs and not the components. Aaargh!! Of course!! So, do you agree this needs to be fixed, or not? Bye, Andrea From owner-ietf-calendar@mail.imc.org Wed Oct 23 20:19:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08799 for ; Wed, 23 Oct 2002 20:19:26 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9O06KQ18045 for ietf-calendar-bks; Wed, 23 Oct 2002 17:06:20 -0700 (PDT) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9O06IW18041 for ; Wed, 23 Oct 2002 17:06:19 -0700 (PDT) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9O06L1N018966 for ; Thu, 24 Oct 2002 02:06:21 +0200 Date: Thu, 24 Oct 2002 02:06:16 +0200 Subject: Re: 9.5 MODIFY Command Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Andrea Campi To: ietf-calendar@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <3DB728D6.2040200@Royer.com> Message-Id: <6A12640F-E6E4-11D6-AE1C-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thursday, October 24, 2002, at 12:55 AM, Doug Royer wrote: > >>> >>> A "VCALENDAR" component is returned with one ore more >>> "REQUEST-STATUS" >>> property values. >> Sorry but the reply should contain a lot more than the >> REQUEST-STATUS, as the description says. It's still not very clear to >> me WHAT should be in the reply, so I guess this badly needs more >> details... > > What else would be included? The MODIFY succeeds or fails, but > it does not return any data. Let me quote what is in the draft: If multiple components are selected, then what uniquely identified the component MUST BE returned (UID, QUERYID, ...) if the component contains a unique identifier. If not, sufficient information to uniquely identify the modified components MUST BE returned in the reply. S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR S: TARGET:relcalid S: CMD;ID=delete#1:REPLY S: BEGIN:VREPLY S: BEGIN:VEVENT S: UID:123 S: REQUEST-STATUS:2.0 S: END:VEVENT S: END:VREPLY S: END:VCALENDAR I guess (given the presence of a query) the intention was to return enough data to allow the CUA to check that what got modified is indeed what the CUA intended to modify. Not that I think this is a smart way to approach the problem... If you are proposing to change this to only return the REQUEST-STATUS - I agree. Bye, Andrea From owner-ietf-calendar@mail.imc.org Fri Oct 25 15:39:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08174 for ; Fri, 25 Oct 2002 15:39:47 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PJUVw22170 for ietf-calendar-bks; Fri, 25 Oct 2002 12:30:31 -0700 (PDT) Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PJUUW22165 for ; Fri, 25 Oct 2002 12:30:30 -0700 (PDT) Received: from inet-mail2.oracle.com (localhost [127.0.0.1]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PJURj19453 for ; Fri, 25 Oct 2002 12:30:27 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PJUQf19443 for ; Fri, 25 Oct 2002 12:30:27 -0700 (PDT) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9PJUPt21735 for ; Fri, 25 Oct 2002 13:30:25 -0600 (MDT) Message-ID: <3DB99BD0.7070703@oracle.com> Date: Fri, 25 Oct 2002 15:30:24 -0400 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Sections 6, 7, and 8 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think some sections are not properly set up. We have these sections: 6. New Components, Properties, Parameters, and Values 7. New Properties 8. New Components Should not the last two be sub-sections of section 6? George From owner-ietf-calendar@mail.imc.org Fri Oct 25 15:39:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08185 for ; Fri, 25 Oct 2002 15:39:48 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PJRHx22001 for ietf-calendar-bks; Fri, 25 Oct 2002 12:27:17 -0700 (PDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PJRHW21996 for ; Fri, 25 Oct 2002 12:27:17 -0700 (PDT) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PJR3U05212 for ; Fri, 25 Oct 2002 12:27:04 -0700 (PDT) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PJR3I05193 for ; Fri, 25 Oct 2002 12:27:03 -0700 (PDT) Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9PJR2X07268 for ; Fri, 25 Oct 2002 13:27:02 -0600 (MDT) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9PJR1e07245 for ; Fri, 25 Oct 2002 13:27:01 -0600 (MDT) Message-ID: <3DB99B03.8060504@oracle.com> Date: Fri, 25 Oct 2002 15:26:59 -0400 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Removing Duplicated Info 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 Sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1, 8.1, and 8.2 contain summary defintions of properties, parameters, and value types that are formally defined elsewhere. Should we remove these summary defintions? We are simply duplicating information and we invite unecessary work in ensuring that the definitions are in sync. By removing them we will also make the draft a few pages shorter. George From owner-ietf-calendar@mail.imc.org Fri Oct 25 16:00:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08977 for ; Fri, 25 Oct 2002 16:00:01 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PJsEq22941 for ietf-calendar-bks; Fri, 25 Oct 2002 12:54:14 -0700 (PDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PJsDW22934 for ; Fri, 25 Oct 2002 12:54:13 -0700 (PDT) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PJsAU01197 for ; Fri, 25 Oct 2002 12:54:10 -0700 (PDT) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PJs9I01187 for ; Fri, 25 Oct 2002 12:54:09 -0700 (PDT) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9PJs8Z01666 for ; Fri, 25 Oct 2002 13:54:08 -0600 (MDT) Message-ID: <3DB9A160.4070703@oracle.com> Date: Fri, 25 Oct 2002 15:54:08 -0400 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: 3.1 System Model 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 > CAP is used by a "Calendar User Agent" (CUA) to send commands to and > receive responses from a "Calendar Server" (CS). > The CUA prepares a [MIME] encapsulated command, sends it to the CS, > and receives a [MIME] encapsulated response. This is not altogether correct. BEEP is peer-to-peer and the CS can send the GET-CAPABILITY command to the CUA. From owner-ietf-calendar@mail.imc.org Fri Oct 25 16:00:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09074 for ; Fri, 25 Oct 2002 16:00:41 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PJtGh22974 for ietf-calendar-bks; Fri, 25 Oct 2002 12:55:16 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PJtFW22970 for ; Fri, 25 Oct 2002 12:55:15 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9PJtGqN028116 for ; Fri, 25 Oct 2002 12:55:16 -0700 Message-ID: <3DB9A1A1.4000403@Royer.com> Date: Fri, 25 Oct 2002 13:55:13 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Removing Duplicated Info References: <3DB99B03.8060504@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040802000402040507050709" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040802000402040507050709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit George Babics wrote: > > > Sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1, 8.1, and 8.2 > contain summary defintions of properties, parameters, > and value types that are formally defined elsewhere. > Should we remove these summary defintions? They were added because many of the new terms were used before defined, making reading difficult. - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms040802000402040507050709 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyNTE5NTUxM1owIwYJKoZIhvcNAQkEMRYEFN6fypP1 m2iZmt4pfFXCWYN2KW0OMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAPCF1oR/pvCVHdGaIF CaHbVuNtKZWZyU0CdsUwYa9dArQV/J5YpVVEv6bQz/xfiMnJxc2rbIYsQEeJnkgR4DzMVK6W YdZ9zRSDdnOH1aseFo3wSfWz4h0fBgSmDLxRUn5y7AVxKb23249G2t+f7V7zySP6/85/YoBT WHoHyYB/mzSffQRlEuHaxqHJYSduzHoHBlmFTe3Tvu6dd2s731yT88SVHbNB8CUsGFNOwFGV xWG8kqqfQ7biJpAQfHvKoVPLY4zoMMijZkme2kCIDCMjSC2ce1seo7Ooa5pvDeb6ROgqU5f1 czed2AD9q8cRkdQEVUgnBfUam0LrikIE+kC+AAAAAAAA --------------ms040802000402040507050709-- From owner-ietf-calendar@mail.imc.org Fri Oct 25 16:16:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09917 for ; Fri, 25 Oct 2002 16:16:30 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PJuaO23001 for ietf-calendar-bks; Fri, 25 Oct 2002 12:56:36 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PJuYW22997 for ; Fri, 25 Oct 2002 12:56:34 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9PJuYqN028121 for ; Fri, 25 Oct 2002 12:56:35 -0700 Message-ID: <3DB9A1F0.4010908@Royer.com> Date: Fri, 25 Oct 2002 13:56:32 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Sections 6, 7, and 8 References: <3DB99BD0.7070703@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040907070108090100010405" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040907070108090100010405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit George Babics wrote: > > > I think some sections are not properly set up. > > We have these sections: > > 6. New Components, Properties, Parameters, and Values > > 7. New Properties > > 8. New Components > > Should not the last two be sub-sections of section 6? Maybe in -10, for now I just renamed (6.) to be 'New Components'. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms040907070108090100010405 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyNTE5NTYzMlowIwYJKoZIhvcNAQkEMRYEFPrEyJ1F P/i1ixrNHpe+HYnBFCB6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQDBiDOfLPYnjPekT05p 0nPCA3SDRe6/vkuZFeBkWzZJfXYS/4EAKOzcObJlR+DSvQaoRPT7HETbXWZ2OIwqKIbAJRDU 92U+f2Qo7+RQisZP5+bUcuYR2Lvjf6ubv/v4ZSU5QXhC2Rn9rlTh45D1fFec5JNiJOPTGnzF yFzSx1z3qYyBnF7FyT5xF0zO/1DJgN1f4ilNgtPho2Fa+mL7CBAPzPZcrVfmfGPai71v+KYU u3GiVHPKNoctYcH2t0eO3gM8kToD/zSTCZ3iXetGpZ/y8XuTaBQhvr47jVe7cXkPgFbEjJ7P 7Fa4j3FRyGc3yos/dH72UbFk0pM/JEQg3oItAAAAAAAA --------------ms040907070108090100010405-- From owner-ietf-calendar@mail.imc.org Fri Oct 25 16:49:59 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11279 for ; Fri, 25 Oct 2002 16:49:58 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PKeAT26528 for ietf-calendar-bks; Fri, 25 Oct 2002 13:40:10 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PKe8W26524 for ; Fri, 25 Oct 2002 13:40:08 -0700 (PDT) Received: from Royer.com (mail.docutechcorp.com [12.23.70.30]) by royer.com (8.12.2/8.12.2) with ESMTP id g9PKeAqN028463 for ; Fri, 25 Oct 2002 13:40:10 -0700 Message-ID: <3DB9AC27.8090409@Royer.com> Date: Fri, 25 Oct 2002 14:40:07 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 3.1 System Model References: <3DB9A160.4070703@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090705000002080303090308" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090705000002080303090308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit George Babics wrote: > > > > CAP is used by a "Calendar User Agent" (CUA) to send commands to and > > receive responses from a "Calendar Server" (CS). > > > The CUA prepares a [MIME] encapsulated command, sends it to the CS, > > and receives a [MIME] encapsulated response. > > This is not altogether correct. BEEP is peer-to-peer and > the CS can send the GET-CAPABILITY command to the CUA. All CAP commands are MIME objects, including GET-CAPABILITY as in: C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//someone's prodid C: CMD:GET-CAPABILITY C: END:VCALENDAR C: END -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms090705000002080303090308 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyNTIwNDAwN1owIwYJKoZIhvcNAQkEMRYEFJr2tQG2 rP6LxOgFQ3cw4oLfbm4dMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCzoiHX2SmavNGC3UVl ggLnB5CeZLsCwnpzGtKmzyw1PPkc3hZFOYAIVbUzFzKMXNlzJGm8DXhxJYKe6Ka0EyJeHQ2f Za9W6pABBsBpnMH8ygoW5ZDJsj8alrNshbY5JTxKnf9FCk87/kHfE0fLaTbJvq8zBjafzQkT EPcxOjBcq1ZtmNQNxTKMxD9EIEuUmkF8d8lgufYdFf8bo1ZKNl33AiGJMadESyxrCQgRpLoQ aYt2gSn1Cu8o7GOMBPTyiSseo0FcCYFzZYbJgxM2KRNUenaLpCmsvt4jhx5C45Id826iI0e5 QLv8qWtcdo0svqlmpvsl5mhop8KD9LY4InALAAAAAAAA --------------ms090705000002080303090308-- From owner-ietf-calendar@mail.imc.org Fri Oct 25 17:09:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12005 for ; Fri, 25 Oct 2002 17:09:53 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PL5Ok28096 for ietf-calendar-bks; Fri, 25 Oct 2002 14:05:24 -0700 (PDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PL5NW28092 for ; Fri, 25 Oct 2002 14:05:23 -0700 (PDT) Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PL5LO28105 for ; Fri, 25 Oct 2002 14:05:21 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PL5Kk28099 for ; Fri, 25 Oct 2002 14:05:20 -0700 (PDT) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9PL5Jt08289 for ; Fri, 25 Oct 2002 15:05:19 -0600 (MDT) Message-ID: <3DB9B20F.8000005@oracle.com> Date: Fri, 25 Oct 2002 17:05:19 -0400 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Sections 6, 7, and 8 References: <3DB99BD0.7070703@oracle.com> <3DB9A1F0.4010908@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: > > > George Babics wrote: > >> >> >> I think some sections are not properly set up. >> >> We have these sections: >> >> 6. New Components, Properties, Parameters, and Values >> >> 7. New Properties >> >> 8. New Components >> >> Should not the last two be sub-sections of section 6? > > > Maybe in -10, for now I just renamed (6.) to be 'New Components'. > > However, section 6 also contains the definitions of the new value types. George From owner-ietf-calendar@mail.imc.org Fri Oct 25 17:10:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12072 for ; Fri, 25 Oct 2002 17:10:36 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PL41w28031 for ietf-calendar-bks; Fri, 25 Oct 2002 14:04:01 -0700 (PDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PL40W28027 for ; Fri, 25 Oct 2002 14:04:00 -0700 (PDT) Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PL3wO27233 for ; Fri, 25 Oct 2002 14:03:58 -0700 (PDT) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PL3vk27223 for ; Fri, 25 Oct 2002 14:03:57 -0700 (PDT) Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9PL3vX07412 for ; Fri, 25 Oct 2002 15:03:57 -0600 (MDT) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9PL3ue07373 for ; Fri, 25 Oct 2002 15:03:56 -0600 (MDT) Message-ID: <3DB9B1BB.50305@oracle.com> Date: Fri, 25 Oct 2002 17:03:55 -0400 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Removing Duplicated Info References: <3DB99B03.8060504@oracle.com> <3DB9A1A1.4000403@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: > > > George Babics wrote: > >> >> >> Sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1, 8.1, and 8.2 >> contain summary definitions of properties, parameters, >> and value types that are formally defined elsewhere. >> Should we remove these summary definitions? > > > They were added because many of the new terms were used > before defined, making reading difficult. We can always put the formal definitions first and remove the duplicate information. George > > - > Doug Royer Work: (208)612-INET > Doug@Royer.com Fax: (866)594-8574 > http://INET-Consulting.com Cell: (208)520-4044 > http://Royer.com/People/Doug From owner-ietf-calendar@mail.imc.org Fri Oct 25 17:27:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12715 for ; Fri, 25 Oct 2002 17:27:46 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PLEqe28673 for ietf-calendar-bks; Fri, 25 Oct 2002 14:14:52 -0700 (PDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PLEpW28668 for ; Fri, 25 Oct 2002 14:14:51 -0700 (PDT) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PLEmU13799 for ; Fri, 25 Oct 2002 14:14:48 -0700 (PDT) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9PLEmI13774 for ; Fri, 25 Oct 2002 14:14:48 -0700 (PDT) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9PLEXI20678 for ; Fri, 25 Oct 2002 15:14:47 -0600 (MDT) Message-ID: <3DB9B438.8020500@oracle.com> Date: Fri, 25 Oct 2002 17:14:32 -0400 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 3.1 System Model References: <3DB9A160.4070703@oracle.com> <3DB9AC27.8090409@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: > > > George Babics wrote: > >> >> >> > CAP is used by a "Calendar User Agent" (CUA) to send commands to and >> > receive responses from a "Calendar Server" (CS). >> >> > The CUA prepares a [MIME] encapsulated command, sends it to the CS, >> > and receives a [MIME] encapsulated response. >> >> This is not altogether correct. BEEP is peer-to-peer and >> the CS can send the GET-CAPABILITY command to the CUA. > > > All CAP commands are MIME objects, including GET-CAPABILITY > as in: > > > > C: Content-Type: text/calendar > C: > C: BEGIN:VCALENDAR > C: VERSION:2.0 > C: PRODID:-//someone's prodid > C: CMD:GET-CAPABILITY > C: END:VCALENDAR > C: END CAP can also be used by the CS to send commands and receive responses, as in the case of GET-CAPABILITY. The paragraphs indicated can imply that CUA only sends and the CS only receives. George > > > From owner-ietf-calendar@mail.imc.org Fri Oct 25 17:57:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13372 for ; Fri, 25 Oct 2002 17:57:29 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PLlQF01517 for ietf-calendar-bks; Fri, 25 Oct 2002 14:47:26 -0700 (PDT) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PLlPW01513 for ; Fri, 25 Oct 2002 14:47:25 -0700 (PDT) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9PLlQ77029139 for ; Fri, 25 Oct 2002 14:47:27 -0700 Message-ID: <3DB9BBEC.7010300@Royer.com> Date: Fri, 25 Oct 2002 15:47:24 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Removing Duplicated Info References: <3DB99B03.8060504@oracle.com> <3DB9A1A1.4000403@Royer.com> <3DB9B1BB.50305@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030205020101050409060603" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030205020101050409060603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >>> >>> Sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1, 8.1, and 8.2 >>> contain summary definitions of properties, parameters, >>> and value types that are formally defined elsewhere. >>> Should we remove these summary definitions? >> >> >> >> They were added because many of the new terms were used >> before defined, making reading difficult. > > > We can always put the formal definitions first and remove > the duplicate information. The problem is that it is a circular usage. If we only use them if they use terms that have already been defined, then the order of the sections in CAP appear to be random. --------------ms030205020101050409060603 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyNTIxNDcyNFowIwYJKoZIhvcNAQkEMRYEFJxO0MX8 ySX6xfrJ5bTh7Abi7ax6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAz8zHuqFevciKckZIg Jj4UVv80p0HlOUjnMgg0nzz+LNunOmffc9hFPHr6wFKYvR98sslsmb1DatAvwXrjiz+CUPpS oc7NkZA0kx1k9I6gTS4kmgvG6tq9yvEJ9oJ5NverViVPxA5t5rwMF0ecBylQgXf821iI47RA M3ONFfu6MzkYmSY4AcJQnu/gx70knIjoAzfacTDYUR3/Z8LlFJ8Aryh7n9+PZRJ3bMEy5Zz4 64Uw6sztUHmRRaGPwESK0Zx/6VH6cn96Hm9HoQhUK3vn+SUVu9AoDlJxZoxrm9RPhFyRLbsc Xmp1+EYLRRMoKLtRid514Qb9KRImCjf3UhBrAAAAAAAA --------------ms030205020101050409060603-- From owner-ietf-calendar@mail.imc.org Fri Oct 25 18:24:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14012 for ; Fri, 25 Oct 2002 18:24:00 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PMFwo02519 for ietf-calendar-bks; Fri, 25 Oct 2002 15:15:58 -0700 (PDT) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PMFuW02515 for ; Fri, 25 Oct 2002 15:15:56 -0700 (PDT) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9PMFw77029365 for ; Fri, 25 Oct 2002 15:15:59 -0700 Message-ID: <3DB9C29C.1070609@Royer.com> Date: Fri, 25 Oct 2002 16:15:56 -0600 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 3.1 System Model References: <3DB9A160.4070703@oracle.com> <3DB9AC27.8090409@Royer.com> <3DB9B438.8020500@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030906070008090404060707" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030906070008090404060707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sorry :-) Now I understand your point, how about adding: In addition the "GET-CAPABIBILITY" command can be sent from the CS to the CUA. George Babics wrote: > > Doug Royer wrote: > >> >> >> George Babics wrote: >> >>> >>> >>> > CAP is used by a "Calendar User Agent" (CUA) to send commands to and >>> > receive responses from a "Calendar Server" (CS). >>> >>> > The CUA prepares a [MIME] encapsulated command, sends it to the CS, >>> > and receives a [MIME] encapsulated response. >>> >>> This is not altogether correct. BEEP is peer-to-peer and >>> the CS can send the GET-CAPABILITY command to the CUA. >> >> >> >> All CAP commands are MIME objects, including GET-CAPABILITY >> as in: >> >> >> >> C: Content-Type: text/calendar >> C: >> C: BEGIN:VCALENDAR >> C: VERSION:2.0 >> C: PRODID:-//someone's prodid >> C: CMD:GET-CAPABILITY >> C: END:VCALENDAR >> C: END > > > CAP can also be used by the CS to send commands > and receive responses, as in the case of GET-CAPABILITY. > The paragraphs indicated can imply that CUA only sends > and the CS only receives. > > George > >> >> >> > -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms030906070008090404060707 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyNTIyMTU1NlowIwYJKoZIhvcNAQkEMRYEFO/MUS6S lS07VjpL7FOG7HXXDpSWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBJvmTdcMRrj5mLfvi7 QtDMh9vQybH+fDk70xmJsZVyzVhKhpUiZckAdQ5DMNVIKs3cgLQdwYpyJ6m4qmpaR6jzJbu2 snkaqz+7F2ekH3uURlZubFDtmdjPMM9fa8sdqNheN5M7SAaKPQO6KHif7/H9ue5gQXOWYPWu +4NZKcwxuGYaz+s4dAHjiond4hK21dfDfJ/rx4nlODm2PC60EpGsRw8DPf0lpD5rmjDMuOa2 uJC+4tVGwJO7peNHi0h0pEg2gxnDmVRoPGw++uAWiMBhUFRYfhmxlQkTd8wh8V7hhaSAa1t4 CGd+GcPNPCsd3EfcMxEO92VaXwsES2r0+CIOAAAAAAAA --------------ms030906070008090404060707-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 11:31:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17477 for ; Mon, 28 Oct 2002 11:31:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SGCg306873 for ietf-calendar-bks; Mon, 28 Oct 2002 08:12:42 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SGCdW06864 for ; Mon, 28 Oct 2002 08:12:39 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SGCe77014323 for ; Mon, 28 Oct 2002 08:12:40 -0800 Message-ID: <3DBD61F5.5060807@Royer.com> Date: Mon, 28 Oct 2002 09:12:37 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: [Fwd: I-D ACTION:draft-many-ical-ski-06.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030204070103000603030402" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030204070103000603030402 Content-Type: multipart/mixed; boundary="------------010406040403010404080001" This is a multi-part message in MIME format. --------------010406040403010404080001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI - this was on the IETF list, but I did not see it on the CALSCH list... -------- Original Message -------- Subject: I-D ACTION:draft-many-ical-ski-06.txt Date: Mon, 28 Oct 2002 06:27:05 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SKiCal - an extension of iCalendar Author(s) : G. FitzPatrick, P. Lannero, N. Hjelm Filename : draft-many-ical-ski-06.txt Pages : 81 Date : 2002-10-25 This Memo defines the SKiCal format. SKiCal is a machine-readable format for the interchange of enhanced yellow-page directory listings. SkiCal expands the traditional property-set of name, address, telephone number and business category, adding structured information about people, places, things, activities and the conditions and terms for interaction with resources.SkiCal provides a structure for information about dates and times, directions, rules and recommendations for participation, pricing and reservation schemes, access information for those with special needs, ownership and responsibilities and promotional material. The referents of these listings, which are both events and persistent resources are referred to in this draft as SkiSources. SkiCal is based on and extends the iCalendar format as defined by RFC-2445, Internet Calendaring and Scheduling Core Object Specification [3] (iCalendar). SkiCal objects are comprised of either VEVENT components with the addition of new properties and property parameters, or the SkiCal specific VOPTIME calendar component described in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-many-ical-ski-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-many-ical-ski-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-many-ical-ski-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------010406040403010404080001 Content-Type: Message/External-body; name="draft-many-ical-ski-06.txt" Content-Disposition: inline; filename="draft-many-ical-ski-06.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-10-25112621.I-D@ietf.org> --------------010406040403010404080001-- --------------ms030204070103000603030402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODE2MTIzN1owIwYJKoZIhvcNAQkEMRYEFI1eYW7k 6fMS2n8WyB6toMwNqGTxMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQDAnmtzmIf6XiiAQSX9 utJPTwt/s1gPu6+46I1OylBNSgCMgMWPubKm5OzViisRlxBYMzkSkccktU5O2nfHRqer07Yi sbinZqRdlS8305PeeS/gmfucBo4MOKZWLBgO7vLZJVhITva2K5gQTFVryyCmsCm1gRpEbrKk 2R297R3f2D5CCSnnvkdOpEJrpxkYijb5HYcWFlSJKY7Dy4PDJMLhg9WafCL4LsWmDhPNicT1 VEPXOkzDCY7Gq5dcrSyM9lCT44nir6XhTORGMBpf/zfQ5wasXEECWPBWtNb2gqyW3OpECYJC DzXeL7bhJXibTKigKTgWnbSfwZtKWk0PqJfTAAAAAAAA --------------ms030204070103000603030402-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 12:48:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20705 for ; Mon, 28 Oct 2002 12:48:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SHd2715563 for ietf-calendar-bks; Mon, 28 Oct 2002 09:39:02 -0800 (PST) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SHcuW15551 for ; Mon, 28 Oct 2002 09:38:57 -0800 (PST) Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9SHcrO19112 for ; Mon, 28 Oct 2002 09:38:53 -0800 (PST) Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9SHcqk19096 for ; Mon, 28 Oct 2002 09:38:52 -0800 (PST) Received: from rgmgw1.us.oracle.com (localhost [127.0.0.1]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9SHcpX18150 for ; Mon, 28 Oct 2002 10:38:51 -0700 (MST) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9SHcoe18121 for ; Mon, 28 Oct 2002 10:38:50 -0700 (MST) Message-ID: <3DBD7628.7020606@oracle.com> Date: Mon, 28 Oct 2002 12:38:48 -0500 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Sections 7 And 8: Comments And Fixes 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 ALLOW-CONFLICT Property > Description: This property is used to indicate whether components may > conflict. That is, if their expanded instances may share the same > time or overlap the same time periods. If it has a value of TRUE, > then conflicts are allowed. If FALSE, the no two components may ^ then DEFAULT-CHARSET > Description: In a "VAGENDA" component, this property is used to > indicate the charset of calendar. If not specified, the default the ^ is > If a charset name contains a comma (,), then that comma must be > backslashed escaped in the value. Is the fact that a comma needs to be escaped already part of the definition of the "text" value type in iCalendar? > 7.12 EXPAND property > Property Name: EXPAND > Purpose: This property is to notify the CS if it should or should not > expand any component with recurrence rules into multiple instances in > a query reply. should we perhaps say "in a reply to a query"? EXPAND Should we use the value type of boolean in the ABNF? > 8.6 VQUERY Component > The "QUERYID" property specifies the local identifier for a stored > "VQUERY" component. The "NAME" property specifies a localizeable > display name of a stored "VQUERY" component. Normally "NAME" and > "QUERYID" properties are used when looking for a correct stored ^^^^^^^^^^^^^^ correctly stored? > "VQUERY" component, or when storing a "VQUERY" component. Sections 8.4, 8.5, and 8.6 are missing an example? From owner-ietf-calendar@mail.imc.org Mon Oct 28 12:54:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21035 for ; Mon, 28 Oct 2002 12:54:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SHnWi16237 for ietf-calendar-bks; Mon, 28 Oct 2002 09:49:32 -0800 (PST) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SHnVW16228 for ; Mon, 28 Oct 2002 09:49:31 -0800 (PST) Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9SHnSO00694 for ; Mon, 28 Oct 2002 09:49:28 -0800 (PST) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9SHnRk00680 for ; Mon, 28 Oct 2002 09:49:27 -0800 (PST) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9SHnQI16926 for ; Mon, 28 Oct 2002 10:49:26 -0700 (MST) Message-ID: <3DBD78A5.8050404@oracle.com> Date: Mon, 28 Oct 2002 12:49:25 -0500 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Removing Duplicated Info References: <3DB99B03.8060504@oracle.com> <3DB9A1A1.4000403@Royer.com> <3DB9B1BB.50305@oracle.com> <3DB9BBEC.7010300@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: > > >>>> >>>> Sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1, 8.1, and 8.2 >>>> contain summary definitions of properties, parameters, >>>> and value types that are formally defined elsewhere. >>>> Should we remove these summary definitions? >>> >>> >>> >>> >>> They were added because many of the new terms were used >>> before defined, making reading difficult. >> >> >> >> We can always put the formal definitions first and remove >> the duplicate information. > > > > The problem is that it is a circular usage. If we only use > them if they use terms that have already been defined, then > the order of the sections in CAP appear to be random. > We can always put the all formal definitions in the first sections and remove sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1. Thus section 2 will be new value types, section 3 will be components, etc. We will shorten CAP and remove duplicated information. The definitions in sections 8.1, and 8.2 appear after the formal definitions. We should remove them. The only information we need to keep is whether the properties are read only. George From owner-ietf-calendar@mail.imc.org Mon Oct 28 13:05:20 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21490 for ; Mon, 28 Oct 2002 13:05:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SHrtL16698 for ietf-calendar-bks; Mon, 28 Oct 2002 09:53:55 -0800 (PST) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SHrnW16683 for ; Mon, 28 Oct 2002 09:53:49 -0800 (PST) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9SHrkU01465 for ; Mon, 28 Oct 2002 09:53:46 -0800 (PST) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9SHrjI01452 for ; Mon, 28 Oct 2002 09:53:45 -0800 (PST) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9SHriI21270 for ; Mon, 28 Oct 2002 10:53:44 -0700 (MST) Message-ID: <3DBD79A7.6070606@oracle.com> Date: Mon, 28 Oct 2002 12:53:43 -0500 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 3.1 System Model References: <3DB9A160.4070703@oracle.com> <3DB9AC27.8090409@Royer.com> <3DB9B438.8020500@oracle.com> <3DB9C29C.1070609@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 How about something like: CAP is used by a "Calendar User Agent" (CUA) to send commands to and receive responses from a "Calendar Server" (CS). In addition the "GET-CAPABIBILITY" command can be sent from the CS to the CUA. The sender prepares a [MIME] encapsulated command, sends it to the receiver, and receives a [MIME] encapsulated response. (I changed CUA to sender and CS to receiver in the original paragraph.) Doug Royer wrote: > > Sorry :-) > > Now I understand your point, how about adding: > > > In addition the "GET-CAPABIBILITY" command can be sent > from the CS to the CUA. > > George Babics wrote: > >> >> Doug Royer wrote: >> >>> >>> >>> George Babics wrote: >>> >>>> >>>> >>>> > CAP is used by a "Calendar User Agent" (CUA) to send commands to and >>>> > receive responses from a "Calendar Server" (CS). >>>> >>>> > The CUA prepares a [MIME] encapsulated command, sends it to the CS, >>>> > and receives a [MIME] encapsulated response. >>>> >>>> This is not altogether correct. BEEP is peer-to-peer and >>>> the CS can send the GET-CAPABILITY command to the CUA. >>> >>> >>> >>> >>> All CAP commands are MIME objects, including GET-CAPABILITY >>> as in: >>> >>> >>> >>> C: Content-Type: text/calendar >>> C: >>> C: BEGIN:VCALENDAR >>> C: VERSION:2.0 >>> C: PRODID:-//someone's prodid >>> C: CMD:GET-CAPABILITY >>> C: END:VCALENDAR >>> C: END >> >> >> >> CAP can also be used by the CS to send commands >> and receive responses, as in the case of GET-CAPABILITY. >> The paragraphs indicated can imply that CUA only sends >> and the CS only receives. >> >> George >> >>> >>> >>> >> > > From owner-ietf-calendar@mail.imc.org Mon Oct 28 13:15:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21859 for ; Mon, 28 Oct 2002 13:15:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SI7m418901 for ietf-calendar-bks; Mon, 28 Oct 2002 10:07:48 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SI7lW18893 for ; Mon, 28 Oct 2002 10:07:47 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SI7l77015660 for ; Mon, 28 Oct 2002 10:07:47 -0800 Message-ID: <3DBD7CF0.4020907@Royer.com> Date: Mon, 28 Oct 2002 11:07:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Sections 7 And 8: Comments And Fixes References: <3DBD7628.7020606@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070908060602060109030102" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070908060602060109030102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit George Babics wrote: > Is the fact that a comma needs to be escaped already part of > the definition of the "text" value type in iCalendar? Yes - However multi-value and multi-instance had a lot of debate a year or so ago, so I wanted to make it clear. I can remove it. Thanks - I will fix the typos tonight. And not all sections need examples - Pat? Bob? I thought we wanted to remove as many examples as possible? - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070908060602060109030102 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODE4MDc0NFowIwYJKoZIhvcNAQkEMRYEFDn76sq4 IL0p/yaMhzbSDKxz0di2MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAlST+zEZZw1J7gf+Ch E8MZB8AXqAcz7+mmctWtSb0tBOjbXx9l/zFc7N7+M4T7eFtqorSuQhMgWaKFkhY65YOBQ2Tk S/dKObz5qjBPeNGuEcokJBJ9KTVNy3W05DK4CHvxYrBK74mEmxLYgw4quzO3k09Fd/fnrQfx R3/Tu4LE+uxw38yB+UK2EiYijm0LxPCsmxDD0FeMedbgVYsY1m7SE3q5NAV3fPSVEhpNGXTQ 2JqcGuJdfk5dgxSWBq5GcfJFnoIZhiN9qtUdCHaxyrE3GE+fZkLOSZI2r0gW7WQN8FdZpMO7 rQG+Xocvrfwm3+7kg06IcuDhR+5Olar08bumAAAAAAAA --------------ms070908060602060109030102-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 13:29:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23467 for ; Mon, 28 Oct 2002 13:29:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SIM3820166 for ietf-calendar-bks; Mon, 28 Oct 2002 10:22:03 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SIM2W20161 for ; Mon, 28 Oct 2002 10:22:02 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SIM377015782 for ; Mon, 28 Oct 2002 10:22:03 -0800 Message-ID: <3DBD8048.7010505@Royer.com> Date: Mon, 28 Oct 2002 11:22:00 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Removing Duplicated Info References: <3DB99B03.8060504@oracle.com> <3DB9A1A1.4000403@Royer.com> <3DB9B1BB.50305@oracle.com> <3DB9BBEC.7010300@Royer.com> <3DBD78A5.8050404@oracle.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080504070105020101090807" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms080504070105020101090807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >> >> The problem is that it is a circular usage. If we only use >> them if they use terms that have already been defined, then >> the order of the sections in CAP appear to be random. >> > > We can always put the all formal definitions in the first > sections and remove sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1. > Thus section 2 will be new value types, section 3 will be > components, etc. We will shorten CAP and remove duplicated > information. How about we work on that in -10 - what I hope is the final rev? For now we can agree to remove any duplicate information when possible. However the circular usage problem still will exist. I think we are going to need a summary of new objects so that a new reader will not go 'what is that?' when reading one of the formal definitions when it uses an object that has not yet been described. > The definitions in sections 8.1, and 8.2 appear after > the formal definitions. We should remove them. The only > information we need to keep is whether the properties > are read only. 8.1 and 8.2 are the formal definitions for VAGANDA and VCALSTORE. Are you looking at -09-b-2 ? And I am editing -b-3, it has the sections for components, properties, and parameters separated - once I understood your email. And I am now adding the error messages and cross referencing with 244[567]. It looks as if we are close, as a HUGE percentage of the messages being sent are typo's, formatting, and not technical problems. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms080504070105020101090807 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODE4MjIwMFowIwYJKoZIhvcNAQkEMRYEFF+gtdm+ AtyaGzu5uLbeS5ec4YvQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBj8gCpk3rCMAFt4zzH hTRiSWDVGPZ9TVGbdVwfK3Fb85bjG7IyUVIg8/qjtT8iq/bCCxerZhjNZOSj4t5e0e4lUaY4 /jxH2B6zfStUe3lZbqLLDRnxVw0cq/0dmE5JwY47wD7znL0OPRmMMDtJ+W7mqM6bnbDPleok E4C1vAmkAxBGBfWtsc854wO5Bq8DALSTZaVox9x7+mP6FRV4BMHk+1QkHjVnzsjw+rTRaDmA +E+5MeVFnEhJYFxi+WT02Yfa4I2gpJLaKe3LuKVOk6alKiSMFJOzJIe64ktbuum8ZwOk3XAp C8pP1Pz6slxfvEvGtzG23hQgwJ9ofmhz3gBnAAAAAAAA --------------ms080504070105020101090807-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 13:50:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24298 for ; Mon, 28 Oct 2002 13:50:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SIhPp21402 for ietf-calendar-bks; Mon, 28 Oct 2002 10:43:25 -0800 (PST) Received: from server1.egenconsulting.com ([208.31.106.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SIhNW21397 for ; Mon, 28 Oct 2002 10:43:23 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: [Fwd: I-D ACTION:draft-many-ical-ski-06.txt] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pregen@egenconsulting.com Date: Mon, 28 Oct 2002 13:43:16 -0500 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.9a |January 7, 2002) at 10/28/2002 01:43:26 PM, Serialize complete at 10/28/2002 01:43:26 PM Content-Type: multipart/alternative; boundary="=_alternative 0066D6DD85256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0066D6DD85256C60_= Content-Type: text/plain; charset="us-ascii" Doug, that draft does not have to be on the list - it's not owned by our working group. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 --=_alternative 0066D6DD85256C60_= Content-Type: text/html; charset="us-ascii"
Doug, that draft does not have to be on the list - it's not owned by our working group.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652 --=_alternative 0066D6DD85256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 14:04:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24929 for ; Mon, 28 Oct 2002 14:04:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SIuA022125 for ietf-calendar-bks; Mon, 28 Oct 2002 10:56:10 -0800 (PST) Received: from liffey.metamatrix.se (liffey.metamatrix.se [213.88.195.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SIu7W22119 for ; Mon, 28 Oct 2002 10:56:08 -0800 (PST) Received: from dublin.kontoret (dublin.kontoret [192.168.168.5]) by liffey.metamatrix.se (Postfix) with ESMTP id 8E65D33AA5 for ; Mon, 28 Oct 2002 19:56:07 +0100 (CET) Subject: Re: [Fwd: I-D ACTION:draft-many-ical-ski-06.txt] From: =?ISO-8859-1?Q?P=E4r_Lanner=F6?= To: ietf-calendar@imc.org In-Reply-To: <3DBD61F5.5060807@Royer.com> References: <3DBD61F5.5060807@Royer.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Metamatrix AB Message-Id: <1035831393.465.254.camel@dublin.kontoret> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.2 (Preview Release) Date: 28 Oct 2002 19:56:34 +0100 Content-Transfer-Encoding: 8bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Mon, 2002-10-28 at 17:12, Doug Royer wrote: > FYI - this was on the IETF list, but I did not see it > on the CALSCH list... Sorry, I guess I should have posted to the list as well as to the I-D editor. We just noticed we forgot to submit the latest SKiCal draft, which is a pity because lots of people are showing interest in our work today, and they should be able to find the spec, even though it is not quite finished. /Pär > > -------- Original Message -------- > Subject: I-D ACTION:draft-many-ical-ski-06.txt > Date: Mon, 28 Oct 2002 06:27:05 -0500 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SKiCal - an extension of iCalendar > Author(s) : G. FitzPatrick, P. Lannero, N. Hjelm > Filename : draft-many-ical-ski-06.txt > Pages : 81 > Date : 2002-10-25 > > This Memo defines the SKiCal format. > SKiCal is a machine-readable format for the interchange of enhanced > yellow-page directory listings. SkiCal expands the traditional > property-set of name, address, telephone number and business > category, adding structured information about people, places, > things, activities and the conditions and terms for interaction with > resources.SkiCal provides a structure for information about dates > and times, directions, rules and recommendations for participation, > pricing and reservation schemes, access information for those with > special needs, ownership and responsibilities and promotional > material. The referents of these listings, which are both events and > persistent resources are referred to in this draft as SkiSources. > SkiCal is based on and extends the iCalendar format as defined by > RFC-2445, Internet Calendaring and Scheduling Core Object > Specification [3] (iCalendar). SkiCal objects are comprised of > either VEVENT components with the addition of new properties and > property parameters, or the SkiCal specific VOPTIME calendar > component described in this memo. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-many-ical-ski-06.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-many-ical-ski-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-many-ical-ski-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > -- > - > Doug Royer Work: (208)612-INET > Doug@Royer.com Fax: (866)594-8574 > http://INET-Consulting.com Cell: (208)520-4044 > http://Royer.com/People/Doug > > ______________________________________________________________________ > > Content-Type: text/plain > Content-ID: <2002-10-25112621.I-D@ietf.org> > From owner-ietf-calendar@mail.imc.org Mon Oct 28 14:59:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27109 for ; Mon, 28 Oct 2002 14:59:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SJjeO25152 for ietf-calendar-bks; Mon, 28 Oct 2002 11:45:40 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SJjdW25143 for ; Mon, 28 Oct 2002 11:45:39 -0800 (PST) In-Reply-To: To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 14:45:38 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 02:39:35 PM, Serialize complete at 10/28/2002 02:39:35 PM Content-Type: multipart/alternative; boundary="=_alternative 006CAA3D85256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CAA3D85256C60_= Content-Type: text/plain; charset="US-ASCII" Andrea Campi wrote on 10/23/2002 05:32:08 PM: > I already gave an example for why a CUA would want to have NO handler > at all: a CGI interface to show a read only view of a specific calendar > (think user group meeting schedule) could be written in a few hundreds > lines of code, and would hopefully be quite fast. I agree a > GET-CAPABILITY handler wouldn't add much; but if it has no need to, why > force it to have this unneeded fat?? I guess it depends on who the main target(s) for CAP are if this is a strong enough example to say that the CUA SHOULD should support a GET-CAPABILITY handler or not. I for one think that even if you are a servlet/portlet writer that its still useful for the CS to know what your script driven CUA can do. I also think that the more predominant use for CAP is the C/S environment where a CUA application is used (ala POP3/IMAP). As such MUST is best suited over SHOULD or MAY (MAY is _not_ a good choice!!) I would prefer to use some hindsight from our iCalendar / iTIP / iMIP work and put a firm stake in the CAP spec that says BOTH sides MUST support GET-CAPABILITY so that either side can reasonably expect to have info about the others capabilities. 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 006CAA3D85256C60_= Content-Type: text/html; charset="US-ASCII"
Andrea Campi <a.campi@inet.it> wrote on 10/23/2002 05:32:08 PM:
> I already gave an example for why a CUA would want to have NO handler
> at all: a CGI interface to show a read only view of a specific calendar
> (think user group meeting schedule) could be written in a few hundreds
> lines of code, and would hopefully be quite fast. I agree a
> GET-CAPABILITY handler wouldn't add much; but if it has no need to, why
> force it to have this unneeded fat??
I guess it depends on who the main target(s) for CAP are if this is a strong enough example to say that the CUA SHOULD should support a GET-CAPABILITY handler or not.  

I for one think that even if you are a servlet/portlet writer that its still useful for the CS to know what your script driven CUA can do.  I also think that the more predominant use for CAP is the C/S environment where a CUA application is used (ala POP3/IMAP).  As such MUST is best suited over SHOULD or MAY (MAY is _not_ a good choice!!)

I would prefer to use some hindsight from our iCalendar / iTIP / iMIP work and put a firm stake in the CAP spec that says BOTH sides MUST support GET-CAPABILITY so that either side can reasonably expect to have info about the others capabilities.

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 006CAA3D85256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 15:11:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27694 for ; Mon, 28 Oct 2002 15:11:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SK1tq26928 for ietf-calendar-bks; Mon, 28 Oct 2002 12:01:55 -0800 (PST) Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SK1nW26920 for ; Mon, 28 Oct 2002 12:01:49 -0800 (PST) Received: from inet-mail2.oracle.com (localhost [127.0.0.1]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9SK1kj04926 for ; Mon, 28 Oct 2002 12:01:46 -0800 (PST) Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by inet-mail2.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9SK1jf04895 for ; Mon, 28 Oct 2002 12:01:45 -0800 (PST) Received: from oracle.com (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9SK1iY26014 for ; Mon, 28 Oct 2002 13:01:44 -0700 (MST) Message-ID: <3DBD97A6.1090104@oracle.com> Date: Mon, 28 Oct 2002 15:01:42 -0500 From: George Babics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Removing Duplicated Info References: <3DB99B03.8060504@oracle.com> <3DB9A1A1.4000403@Royer.com> <3DB9B1BB.50305@oracle.com> <3DB9BBEC.7010300@Royer.com> <3DBD78A5.8050404@oracle.com> <3DBD8048.7010505@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: > >>> >>> The problem is that it is a circular usage. If we only use >>> them if they use terms that have already been defined, then >>> the order of the sections in CAP appear to be random. >>> >> >> We can always put the all formal definitions in the first >> sections and remove sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1. >> Thus section 2 will be new value types, section 3 will be >> components, etc. We will shorten CAP and remove duplicated >> information. > > > > How about we work on that in -10 - what I hope is the final rev? That is fine. > > For now we can agree to remove any duplicate information > when possible. However the circular usage problem still will exist. > I think we are going to need a summary of new objects so > that a new reader will not go 'what is that?' when reading > one of the formal definitions when it uses an object > that has not yet been described. > >> The definitions in sections 8.1, and 8.2 appear after >> the formal definitions. We should remove them. The only >> information we need to keep is whether the properties >> are read only. > > > 8.1 and 8.2 are the formal definitions for VAGANDA > and VCALSTORE. However, they also contain definitions of the properties that they can contain. The properties are formally defined earlier. > > Are you looking at -09-b-2 ? > > And I am editing -b-3, it has the sections for components, properties, > and parameters separated - once I understood your email. And I am now > adding the error messages and cross referencing with 244[567]. > > It looks as if we are close, as a HUGE percentage of the messages > being sent are typo's, formatting, and not technical problems. > From owner-ietf-calendar@mail.imc.org Mon Oct 28 15:23:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28268 for ; Mon, 28 Oct 2002 15:23:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SK99p27291 for ietf-calendar-bks; Mon, 28 Oct 2002 12:09:09 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SK98W27287 for ; Mon, 28 Oct 2002 12:09:08 -0800 (PST) In-Reply-To: <3DB70A07.90506@Royer.com> To: ietf-calendar@imc.org Subject: Re: Updated CAL-QUERY MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 15:09:08 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 03:03:04 PM, Serialize complete at 10/28/2002 03:03:04 PM Content-Type: multipart/alternative; boundary="=_alternative 006ED11185256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006ED11185256C60_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/23/2002 04:43:51 PM: > In -09-2: > > 6.1.1.3 PARAM() [Snip] > I *think* that covers it - or did I miss your point? Missed it. Let me try to be clearer (kinda hard to get really focused after a big product end push followed by vacation, sorry.) In -09b (ftp://royer.com/pub/CALSCH/cap.txt), at the top of Section 6.1.1 is: 1. For the purpose of a query, all components should be handled as tables, and the properties of those components, should be handled as columns. 2. All VAGENDAs and CS's look like tables for the purpose of a QUERY. And all of their properties look like columns in those tables. so there is explicit text on how components and properties are to be viewed/treated. There is no explciit text _here_ on how to deal with propery parameters, the next "step down" in scale. I think there should be so that its consistant and unified. Having text in 6.1.1.3 where PARAM() is defined is not consistant and I would not have thought to look there since 6.1.1 already lays out the guidelines for how some entities are to be handled. Put into semi-graphical form, by the text above I would create a table for a single VEVENT that was layed out like: SUMMARY DESCRIPTION ATTENDEE ATTENDEE ATTENDEE ... A quick CAP issue discussion Try to iron out a solution to the... mailto:Bruce_Kahn@iris.com mailto:jdoe@fizbin.com mailto:Doug@Royer.com ... (by "Rule" #1) So just where do property parameters get stored in this model of the data? I cannot see how I can search for the CN="John Doe, Contractor" property parameter on any ATTENDEE since its not clear how its handled in the model as described. Hmm, the more I look @ it in this format the more I wonder why #1 and #2 do not say "should be handled as rows where the 1st column of the table is the property name and the 2nd column is the property value(s).".. Also, the text in 6.1.1.3 does not describe how property parameters are to be handled like in 6.1.1, it describes the actual value restrictions, etc. Is that clearer? 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 006ED11185256C60_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/23/2002 04:43:51 PM:
> In -09-2:
>
> 6.1.1.3 PARAM()
[Snip]
> I *think* that covers it - or did I miss your point?
Missed it.  Let me try to be clearer (kinda hard to get really focused after a big product end push followed by vacation, sorry.)

In -09b (ftp://royer.com/pub/CALSCH/cap.txt), at the top of Section 6.1.1 is:

    1.  For the purpose of a query, all components should be handled as
      tables, and the properties of those components, should be handled
      as columns.

   2.  All VAGENDAs and CS's look like tables for the purpose of a
      QUERY.  And all of their properties look like columns in those
      tables.
so there is explicit text on how components and properties are to be viewed/treated.  There is no explciit text _here_ on how to deal with propery parameters, the next "step down" in scale.  I think there should be so that its consistant and unified.  Having text in 6.1.1.3 where PARAM() is defined is not consistant and I would not have thought to look there since 6.1.1 already lays out the guidelines for how some entities are to be handled.  

Put into semi-graphical form, by the text above I would create a table for a single VEVENT that was layed out like:
SUMMARY DESCRIPTION ATTENDEE ATTENDEE ATTENDEE ...
A quick CAP issue discussion Try to iron out a solution to the... mailto:Bruce_Kahn@iris.com mailto:jdoe@fizbin.com mailto:Doug@Royer.com ...


(by "Rule" #1)  So just where do property parameters get stored in this model of the data?   I cannot see how I can search for the CN="John Doe, Contractor" property parameter on any ATTENDEE since its not clear how its handled in the model as described.

Hmm, the more I look @ it in this format the more I wonder why #1 and #2 do not say "should be handled as rows where the 1st column of the table is the property name and the 2nd column is the property value(s)."..

Also, the text in 6.1.1.3 does not describe how property parameters are to be handled like in 6.1.1, it describes the actual value restrictions, etc.

Is that clearer?

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 006ED11185256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 15:50:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29326 for ; Mon, 28 Oct 2002 15:50:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SKae928720 for ietf-calendar-bks; Mon, 28 Oct 2002 12:36:40 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SKadW28715 for ; Mon, 28 Oct 2002 12:36:39 -0800 (PST) In-Reply-To: <3DB715A0.5080300@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: COUNTER - and who sent it. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 15:36:39 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 03:30:35 PM, Serialize complete at 10/28/2002 03:30:35 PM Content-Type: multipart/alternative; boundary="=_alternative 007155F585256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007155F585256C60_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/23/2002 05:33:20 PM: > > I didnt see any traffic since ~9/27 and Im still digging out from my 2 > > week haitus and resulting email flood. I didnt see ATT-COUNTER in my > > search since it was referred to then as ATTCOUNTER w/o a hyphen. > > The debate was in 2000. Yep and at that time we all used ATTCOUNTER (sans hyphen) so when I searched for your ATT-COUNTER (with hyphen) I didnt see it so I failed to find the discussion the first time around. Thats why I failed to find it when I looked so hence my original query when it was covered... (We agree that we need it, I just failed to see any recent discussion of it or the summary you posted a couple weeks ago so I chimed in.) > > You are assuming that SENT-BYs are preserved and round tripped > > ad-nauseum. I dont belive this to be true. They are only really useful > > between the sending CUA (their proxy actually) and the Organizer. They > > are not really that useful to any other entity in the process. (Do you > > _really_ need to know or care if I or my AA accepted as long as my > > PARTSTAT=ACCEPTED??) > > Do you think that it is invalid for the ORGANIZER to get a COUNTER > and have to keep both the SENT-BY values for all the ATTENDEEs > and to know who sent the COUNTER? If no - then you are agreeing > that SENT-BY is not sufficient. Ya missed my point. We never intended/expected that SENT-BY would be round tripped or forwarded on to others in the workflow process. (Go search the related archive thread to see the same discussion then...). My point is simply this: Is there any real value in Andrea seeing that my AA sent some message to You on my behalf (assuming you are the Organizer)? I say no. What info can he safely derive from it that is of any real use to _him_. I fully grok why the Organizer would want that info but Im saying its of minimal use to other ATTENDEEs at best and was not intended to be preserved ad naseum in all workflow messages. You used SENT-BY on an ATTENDEE that had the same value as that ATTENDEE property. Thats not the use for SENT-BY. SENT-BY is the CU whose acting on behalf of that ATTENDEE. You are NOT acting as your proxy, you are you. Also, I strongly disagree w/the COUNTERing CU parroting a PARTSTAT property parameter on behalf of a different CU. Just because you can COUNTER does not mean you have the power to take actions on part of any other CU. Otherwise I could use a COUNTER to a meeting and say that you PARTSTAT=ACCEPTED when in fact you've never even seen the request (or you've already DECLINED). Good/safe thing to do??... The same concern goes for other property parameters too... > If it is valid to keep them (and I think it is), then SENT-BY > can not work to remember who sent the COUNTER when the ORGANIZER > might have several SENT-BY values already in the object. To restate/rephrase/clarify again: The Organizer can/should keep that info around for its own use but they should NOT be sending it along in workflow messages that get sent to other folks. > > One thing that noone has codified yet is "Does the ATT-COUNTER property > > value have to match a currently existing ATTENDEE value?" That is, does > > the ATT-COUNTER have to come from an ATTENDEE that the Organizer thinks > > is involved or can it come from just anyone? Since I could be > > COUNTERing that I should NOT be at an event its possible that the > > ATT-COUNTER does not match any ATTENDEE property I send back in my > > COUNTER but it SHOULD (MUST?) match my ATTENDEE property that the > > Organzier has on their copy of the event. > > There is a entire "ATT-COUNTER" section in -09 (7.2), it seems clear > to me that it comes from the cal-address that sent the COUNTER. > Did you miss that section? Or are you saying that is not what > you get when you read that section? Argh! Ive been using the apparently abandoned FTP url you posted a while back. (Even the recent thread on diffs uses ftp.royer.com instead of inet-consulting.com in the Subject! Ugh!!). Actually though when I look at http://inet-consulting.com/cap-09-b.txt, ATT-COUNTER is NOT section 7.2. Section 7.2 is listed as: 7.2 CALID Property . . . . . . . . . . . . . . . . . . . . . 54 I can find no mention of ATT-COUNTER in the text at all. Is there more skewage??... Rescan the original thread, I was one of the ones that proposed ATTCOUNTER and pushed for it over SENT-BY so Im NOT against this proposal in concept. I just wanted clarification on where this new property came from (hyphenation threw me off)... 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 007155F585256C60_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/23/2002 05:33:20 PM:
> > I didnt see any traffic since ~9/27 and Im still digging out from my 2
> > week haitus and resulting email flood.  I didnt see ATT-COUNTER in my
> > search since it was referred to then as ATTCOUNTER w/o a hyphen.
>
> The debate was in 2000.
Yep and at that time we all used ATTCOUNTER (sans hyphen) so when I searched for your ATT-COUNTER (with hyphen) I didnt see it so I failed to find the discussion the first time around.  Thats why I failed to find it when I looked so hence my original query when it was covered...  (We agree that we need it, I just failed to see any recent discussion of it or the summary you posted a couple weeks ago so I chimed in.)

> > You are assuming that SENT-BYs are preserved and round tripped
> > ad-nauseum.  I dont belive this to be true.  They are only really useful
> > between the sending CUA (their proxy actually) and the Organizer.  They
> > are not really that useful to any other entity in the process.  (Do you
> > _really_ need to know or care if I or my AA accepted as long as my
> > PARTSTAT=ACCEPTED??)
>
> Do you think that it is invalid for the ORGANIZER to get a COUNTER
> and have to keep both the SENT-BY values for all the ATTENDEEs
> and to know who sent the COUNTER? If no - then you are agreeing
> that SENT-BY is not sufficient.
Ya missed my point.  We never intended/expected that SENT-BY would be round tripped or forwarded on to others in the workflow process.  (Go search the related archive thread to see the same discussion then...).  

My point is simply this: Is there any real value in Andrea seeing that my AA sent some message to You on my behalf (assuming you are the Organizer)?  I say no.  What info can he safely derive from it that is of any real use to _him_.  I fully grok why the Organizer would want that info but Im saying its of minimal use to other ATTENDEEs at best and was not intended to be preserved ad naseum in all workflow messages.

<DIGRESSION>
You used SENT-BY on an ATTENDEE that had the same value as that ATTENDEE property.  Thats not the use for SENT-BY.  SENT-BY is the CU whose acting on behalf of that ATTENDEE.  You are NOT acting as your proxy, you are you.

Also, I strongly disagree w/the COUNTERing CU parroting a PARTSTAT property parameter on behalf  of a different CU.  Just because you can COUNTER does not mean you have the power to take actions on part of any other CU.  Otherwise I could use a COUNTER to a meeting and say that you PARTSTAT=ACCEPTED when in fact you've never even seen the request (or you've already DECLINED).  Good/safe thing to do??...  The same concern goes for other property parameters too...
</DIGRESSION>

> If it is valid to keep them (and I think it is), then SENT-BY
> can not work to remember who sent the COUNTER when the ORGANIZER
> might have several SENT-BY values already in the object.
To restate/rephrase/clarify again: The Organizer can/should keep that info around for its own use but they should NOT be sending it along in workflow messages that get sent to other folks.

> > One thing that noone has codified yet is "Does the ATT-COUNTER property
> > value have to match a currently existing ATTENDEE value?"  That is, does
> > the ATT-COUNTER have to come from an ATTENDEE that the Organizer thinks
> > is involved or can it come from just anyone?  Since I could be
> > COUNTERing that I should NOT be at an event its possible that the
> > ATT-COUNTER does not match any ATTENDEE property I send back in my
> > COUNTER but it SHOULD (MUST?) match my ATTENDEE property that the
> > Organzier has on their copy of the event.
>
> There is a entire "ATT-COUNTER" section in -09 (7.2), it seems clear
> to me that it comes from the cal-address that sent the COUNTER.
> Did you miss that section? Or are you saying that is not what
> you get when you read that section?
Argh! Ive been using the apparently abandoned FTP url you posted a while back.  (Even the recent thread on diffs uses ftp.royer.com instead of  inet-consulting.com in the Subject!  Ugh!!).  Actually though when I look at http://inet-consulting.com/cap-09-b.txt, ATT-COUNTER is NOT section 7.2.  Section 7.2 is listed as:

7.2      CALID Property . . . . . . . . . . . . . . . . . . . . .  54

I can find no mention of ATT-COUNTER in the text at all.  Is there more skewage??...
Rescan the original thread, I was one of the ones that proposed ATTCOUNTER and pushed for it over SENT-BY so Im NOT against this proposal in concept.  I just wanted clarification on where this new property came from (hyphenation threw me off)...

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 007155F585256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 15:56:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29651 for ; Mon, 28 Oct 2002 15:56:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SKmqX29325 for ietf-calendar-bks; Mon, 28 Oct 2002 12:48:52 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SKmpW29320 for ; Mon, 28 Oct 2002 12:48:52 -0800 (PST) To: Doug Royer Cc: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - reply MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 15:48:50 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 03:42:47 PM, Serialize complete at 10/28/2002 03:42:47 PM Content-Type: multipart/alternative; boundary="=_alternative 007273AD85256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007273AD85256C60_= Content-Type: text/plain; charset="US-ASCII" Doug proposed on 22-Oct-2002: > If the CUA does not support > sending a full reply and sends not-implemented error, then > the CS MUST assume the CUA supports the default values as > defined below. Are you adding explicit text to the draft to say that "A CUA MUST support the defaults if they return a not-implemented error" or some such requirement?? Otherwise you get the CS thinking all defaults are possible and the CUA thinking it doesnt have to do anything... 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 007273AD85256C60_= Content-Type: text/html; charset="US-ASCII"
Doug proposed on 22-Oct-2002:
>                               If the CUA does not support
>      sending a full reply and sends not-implemented error, then
>      the CS MUST assume the CUA supports the default values as
>      defined below.

Are you adding explicit text to the draft to say that "A CUA MUST support the defaults if they return a not-implemented error" or some such requirement??  Otherwise you get the CS thinking all defaults are possible and the CUA thinking it doesnt have to do anything...

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 007273AD85256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 16:19:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00327 for ; Mon, 28 Oct 2002 16:19:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SL9jH00790 for ietf-calendar-bks; Mon, 28 Oct 2002 13:09:45 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SL9gW00786 for ; Mon, 28 Oct 2002 13:09:44 -0800 (PST) To: ietf-calendar@imc.org Subject: GET-CAPABILITY - No more QUERY-LEVEL? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 16:09:39 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 04:03:40 PM, Serialize complete at 10/28/2002 04:03:40 PM Content-Type: multipart/alternative; boundary="=_alternative 00745B9F85256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00745B9F85256C60_= Content-Type: text/plain; charset="US-ASCII" In catching up the proposed CAP changes (and draft skewage) I see that the latest proposal posted has no QUERY-LEVEL as part of GET-CAPABILITY but the draft at http://inet-consulting.com/cap-09-b.txt does. Was there recent talk of droping this from the draft that I missed or was this an oversight? If QUERY-LEVEL: NONE is no more then what is the functional replacement for it? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00745B9F85256C60_= Content-Type: text/html; charset="US-ASCII"
In catching up the proposed CAP changes (and draft skewage) I see that the latest proposal posted has no QUERY-LEVEL as part of GET-CAPABILITY but the draft at http://inet-consulting.com/cap-09-b.txt does.  Was there recent talk of droping this from the draft that I missed or was this an oversight?

If QUERY-LEVEL: NONE is no more then what is the functional replacement for it?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--=_alternative 00745B9F85256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 16:24:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00443 for ; Mon, 28 Oct 2002 16:24:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SLHXD01008 for ietf-calendar-bks; Mon, 28 Oct 2002 13:17:33 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SLHWW01004 for ; Mon, 28 Oct 2002 13:17:32 -0800 (PST) To: Doug Royer Cc: ietf-calendar@imc.org Subject: COMPONENTS [Was Re: GET-CAPABILITY - reply] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 16:16:39 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 04:11:28 PM, Serialize complete at 10/28/2002 04:11:28 PM Content-Type: multipart/alternative; boundary="=_alternative 0074FF9685256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0074FF9685256C60_= Content-Type: text/plain; charset="US-ASCII" WRT COMPONENTs in GET-CAPABILITY, Doug proposed: COMPONENTS 1 A comma separated list of the names of components that are supported. This includes any components inside of other components (VALARM for example). MUST include at least VCALSTORE, VCALENDAR, VREPLY, and VAGENDA and at least one of VEVENT, VTODO, VTIMEZONE, or VJOURNAL. The defalt is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, VEVENT,VALARM,VTIMEZONE" The last line is not gramatically correct. It should start with something like "This list MUST include..." Also, is there any reason why the 'base' components of VTODO and VJOURNAL are not also in the default list? 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 0074FF9685256C60_= Content-Type: text/html; charset="US-ASCII"
WRT COMPONENTs in GET-CAPABILITY, Doug proposed:

    COMPONENTS       1      A comma separated list of the names of
                           components that are supported. This
                           includes any components inside of
                           other components (VALARM for example).
                           MUST include at least VCALSTORE, VCALENDAR,
                           VREPLY, and VAGENDA and at least one of VEVENT,
                           VTODO, VTIMEZONE, or VJOURNAL. The defalt
                           is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,
                           VEVENT,VALARM,VTIMEZONE"

The last line is not gramatically correct.  It should start with something like "This list MUST include..."

Also, is there any reason why the 'base' components of VTODO and VJOURNAL are not also in the default list?

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 0074FF9685256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 16:24:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00488 for ; Mon, 28 Oct 2002 16:24:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SLBoN00879 for ietf-calendar-bks; Mon, 28 Oct 2002 13:11:50 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SLBnW00875 for ; Mon, 28 Oct 2002 13:11:50 -0800 (PST) To: Doug Royer Cc: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - reply MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 16:11:48 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 04:05:45 PM, Serialize complete at 10/28/2002 04:05:45 PM Content-Type: multipart/alternative; boundary="=_alternative 00748DEE85256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00748DEE85256C60_= Content-Type: text/plain; charset="US-ASCII" Doug wrote: CAR-LEVEL 1 Indicates level of CAR support. CAR-NONE, CAR-MIN or CAR-FULL-1. If CAR-FULL-1 is supplied then CAR-MIN MUST BE assumed. CAR = NONE MUST BE used when query-level of NONE is supplied. That last line is a bit non-sensical or unclear to me. "CAR = NONE"?? The last "NONE" reference should be "CAR-NONE" 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 00748DEE85256C60_= Content-Type: text/html; charset="US-ASCII"
Doug wrote:
    CAR-LEVEL         1     Indicates level of CAR support. CAR-NONE,
                           CAR-MIN or CAR-FULL-1. If CAR-FULL-1 is
                           supplied then CAR-MIN MUST BE assumed.
                           CAR = NONE MUST BE used when query-level
                           of NONE is supplied.

That last line is a bit non-sensical or unclear to me.  "CAR = NONE"??  The last "NONE" reference should be "CAR-NONE" 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 00748DEE85256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 16:35:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00942 for ; Mon, 28 Oct 2002 16:35:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SLQGW01181 for ietf-calendar-bks; Mon, 28 Oct 2002 13:26:16 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SLQFW01177 for ; Mon, 28 Oct 2002 13:26:15 -0800 (PST) To: ietf-calendar@imc.org Subject: Bad ABNF in 9.3 GET-CAPABILITY MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 16:26:14 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 04:20:11 PM, Serialize complete at 10/28/2002 04:20:11 PM Content-Type: multipart/alternative; boundary="=_alternative 0075E02985256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0075E02985256C60_= Content-Type: text/plain; charset="US-ASCII" In catching up on stuff I looked at the latest draft at http://inet-consulting.com/cap-09-b.txt and noticed an ABNF bug. Under Section 9.3 GET-CAPABILITY Command is the ABNF: get-capability-cmd = capibiltyparam ":" "GET-CAPABILITY" genuidparam = *( ; the following are optional, ; but MUST NOT occur more than once id-param / localize-param / latency-param ; the following MUST occur exactly once and only ; when the latency-param has been supplied and ; MUST NOT be supplied if the latency-param is ; not supplied. / action-param ; the following is optional, ; and MAY occur more than once / (";" xparam) ) Unfortunately the genuidparam in the text is a duplicate of the text from Section 9.2 above it. There does not seem to be any ABNF for capibiltyparam. 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 0075E02985256C60_= Content-Type: text/html; charset="US-ASCII"
In catching up on stuff I looked at the latest draft at http://inet-consulting.com/cap-09-b.txt and noticed an ABNF bug.  Under Section 9.3 GET-CAPABILITY Command is the ABNF:

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

       genuidparam     = *(

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

                         id-param
                       / localize-param
                       / latency-param

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

                       / action-param

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

                       / (";" xparam)

                       )
Unfortunately the genuidparam in the text is a duplicate of the text from Section 9.2 above it.  There does not seem to be any ABNF for capibiltyparam.

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 0075E02985256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 16:55:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01491 for ; Mon, 28 Oct 2002 16:55:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SLlkS01694 for ietf-calendar-bks; Mon, 28 Oct 2002 13:47:46 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SLljW01690 for ; Mon, 28 Oct 2002 13:47:45 -0800 (PST) To: Doug Royer Cc: Andrea Campi , ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - reply MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 16:47:43 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 04:41:41 PM, Serialize complete at 10/28/2002 04:41:41 PM Content-Type: multipart/alternative; boundary="=_alternative 0077D78085256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0077D78085256C60_= Content-Type: text/plain; charset="US-ASCII" Doug replied with: > If TRUE then it expands multiple instances separately when they are > stored (RRULEs converted to RDATEs) and when sent. If FALSE then it > expands instances dynamically during sending. Default is FALSE. One quick question: What does it matter if the expansion/conversion is when stored or when retrieved if its always done from the receivers point of view?? The FALSE description talks about "expands instances dynamically during sending" and TRUE says they are expanded "when they are stored". However, from a retrieval point of view the they are expanded either way. I suspect that the intent is not to specify a way for the CS to say "I save them expanded and return them expanded too" or "I dont save them expanded but I do return them expanded"; its to provide a means for one side to detect that some form of logical conversion has taken place. That is, RRULE expansion/conversion into explicit RDATEs. Is this correct? 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 0077D78085256C60_= Content-Type: text/html; charset="US-ASCII"
Doug replied with:
>        If TRUE then it expands multiple instances separately when they are
>        stored (RRULEs converted to RDATEs) and when sent. If FALSE then it
>        expands instances dynamically during sending. Default is FALSE.
One quick question: What does it matter if the expansion/conversion is when stored or when retrieved if its always done from the receivers point of view??

The FALSE description talks about "expands instances dynamically during sending" and TRUE says they are expanded "when they are stored".  However, from a retrieval point of view the they are expanded either way.  I suspect that the intent is not to specify a way for the CS to say "I save them expanded and return them expanded too" or "I dont save them expanded but I do return them expanded"; its to provide a means for one side to detect that some form of logical conversion has taken place.  That is, RRULE expansion/conversion into explicit RDATEs.  Is this correct?

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 0077D78085256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 17:13:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02073 for ; Mon, 28 Oct 2002 17:13:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SM5SK02075 for ietf-calendar-bks; Mon, 28 Oct 2002 14:05:28 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SM5RW02069 for ; Mon, 28 Oct 2002 14:05:27 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Mon, 28 Oct 2002 17:05:24 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/28/2002 04:59:23 PM, Serialize complete at 10/28/2002 04:59:23 PM Content-Type: multipart/alternative; boundary="=_alternative 0079763E85256C60_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0079763E85256C60_= Content-Type: text/plain; charset="US-ASCII" Doug proposed: > Property Parameters: Non-standard property parameters can be > specified on this property. > [Snip] > Formal Definition: The property is defined by the following notation: > > attcounter = "ATT-COUNTER" *(";" xparam) ":" cal-address CRLF You are missing some property parameters. I think that the ABNF should be changed to be more like: attcounter = "ATT-COUNTER" attcounterparam ":" cal-address CRLF attcounterparam = *( ; the following are optional, ; but MUST NOT occur more than once ( ";" sentbyparam ) / ( ";" cnparam ) / ( ";" languageparam ) ; the following is optional, ; and MAY occur more than once (";" xparam) ) so that it will permit SENT-BY, CN and LANGUAGE to be specified as well. Im not sure any other parameters are necessary beyond these but perhaps this will jog some others memories. Also, the Property Parameters text should be more like: Property Parameters: Non-standard, language, sent by or common name property parameters can be specified on this property. Do we need a Conformance section (ala ATTENDEE) that says something like: Conformance: This property MUST be specified in an iCalendar object that specifies counter proposal to a group scheduled calendar entity. This property MUST NOT be specified in an iCalendar object when publishing the calendar information (e.g., NOT in an iCalendar object that specifies the publication of a calendar user's busy time, event, to-do or journal). This property is not specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities which are not being counter proposed. Better wordsmithing is probably in order but the intent is clear and its use properly restricted. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... --=_alternative 0079763E85256C60_= Content-Type: text/html; charset="US-ASCII"
Doug proposed:
>     Property Parameters: Non-standard property parameters can be
>     specified on this property.
>
[Snip]
>     Formal Definition: The property is defined by the following notation:
>
>           attcounter   = "ATT-COUNTER" *(";" xparam) ":" cal-address CRLF
You are missing some property parameters.  I think that the ABNF should be changed to be more like:

          attcounter   = "ATT-COUNTER" attcounterparam ":" cal-address CRLF
          attcounterparam = *(

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

                ( ";" sentbyparam ) /
               ( ";" cnparam ) /
               ( ";" languageparam )

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

               (";" xparam)
               )

so that it will permit SENT-BY, CN and LANGUAGE to be specified as well.  Im not sure any other parameters are necessary beyond these but perhaps this will jog some others memories.

Also, the Property Parameters text should be more like:

   Property Parameters: Non-standard, language, sent by or common name
  property parameters can be specified on this property.

Do we need a Conformance section (ala ATTENDEE) that says something like:

   Conformance: This property MUST be specified in an iCalendar object
  that specifies counter proposal to a group scheduled calendar entity.
   This property MUST NOT be specified in an iCalendar object when
   publishing the calendar information (e.g., NOT in an iCalendar
   object that specifies the publication of a calendar user's busy time,
   event, to-do or journal).  This property is not specified in an
   iCalendar object that specifies only a time zone definition or
   that defines calendar entities that are not group scheduled entities
   which are not being counter proposed.

Better wordsmithing is probably in order but the intent is clear and its use properly restricted.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
--=_alternative 0079763E85256C60_=-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 17:30:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02434 for ; Mon, 28 Oct 2002 17:30:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SMMuv03858 for ietf-calendar-bks; Mon, 28 Oct 2002 14:22:56 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SMMtW03854 for ; Mon, 28 Oct 2002 14:22:55 -0800 (PST) Received: from Royer.com (mail.inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SMMvIR018085 for ; Mon, 28 Oct 2002 14:22:57 -0800 Message-ID: <3DBDB8BE.5070008@Royer.com> Date: Mon, 28 Oct 2002 15:22:54 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020307020304020708090702" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020307020304020708090702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Do you think that it is invalid for the ORGANIZER to get a COUNTER > > and have to keep both the SENT-BY values for all the ATTENDEEs > > and to know who sent the COUNTER? If no - then you are agreeing > > that SENT-BY is not sufficient. Maybe I did miss your point - but you did not answer my question. Is it valid for the ORGANIZER to keep the SENT-BY values? I say yes. --------------ms020307020304020708090702 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODIyMjI1NFowIwYJKoZIhvcNAQkEMRYEFNyN3Jgd vFjifRFYMtB3poip9IrMMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAOjdvFJQ+j+5pe1N1u EWzVaZn2nVxDK0gLByfjFM5rqhAtSyv4J4XJ9+ESHu7njkcabiFgnDLIVkumNG5RYErmpzvo B1jIy7gaXpr5X2Ne0KFrtJ2zPBtZyZeW799XpIMpOyoBRhtAgphjyX2DDANzdR3eP5XzuG9R TafIdOKOCzB3kL6ZClcmP5YsB5QQlzBJHvCGdCDBadn/enaGOPItp96br9R0b2IEEoPyG626 QRNg2gs2QlMu8zab7Fc9BGL7JBv6RiAUhc+7Hi0tIAAN097vL54r5GnpvpJFbpNxHUuKTmQS QuZzqDjbn9FEkOOFxmpgqdFnxoDheFAM0BySAAAAAAAA --------------ms020307020304020708090702-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 17:34:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02480 for ; Mon, 28 Oct 2002 17:34:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SMQKJ04274 for ietf-calendar-bks; Mon, 28 Oct 2002 14:26:20 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SMQJW04268 for ; Mon, 28 Oct 2002 14:26:19 -0800 (PST) Received: from Royer.com (mail.inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SMQLIR018118 for ; Mon, 28 Oct 2002 14:26:21 -0800 Message-ID: <3DBDB98A.8060006@Royer.com> Date: Mon, 28 Oct 2002 15:26:18 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - reply References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050205020706070009080707" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050205020706070009080707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Fixed. Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote: > CAR-LEVEL 1 Indicates level of CAR support. CAR-NONE, > CAR-MIN or CAR-FULL-1. If CAR-FULL-1 is > supplied then CAR-MIN MUST BE assumed. > CAR = NONE MUST BE used when query-level > of NONE is supplied. > > That last line is a bit non-sensical or unclear to me. "CAR = NONE"?? > The last "NONE" reference should be "CAR-NONE" I think... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms050205020706070009080707 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODIyMjYxOFowIwYJKoZIhvcNAQkEMRYEFNwn6m7c Ipqs08PBlE1JkrP3Z5n8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAU7wn2gShuw6S+oQFn LXdRCznnIDd5bbgzmV7/ngAwyhLxjXzzXi1qwYZylDhRch5KyoPqnpOVOcQgyhn5044Q9Lh/ toSV6flJ3WPD8jBR8kyp2yvEqm86EQfI0podU9uCMzaaRCnS2nELojp3DshJl8UOyZyM0Ima XCCJ1/mPv4GcPB99C1BwMgZKIbbserAC9FoAOn1on9P0h1tqx7Kkou8lDwysmeE+y4+5SrKy w/BJYh51+R+VScjr68EfkDgp9hLNgU5vedNxpnUIvQe1BoVA9TVEUrRoKD76t0HHTPyetI3i /84htZrxXhHzQr3I1EwMoM3iVGk30cEwP/jxAAAAAAAA --------------ms050205020706070009080707-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 17:35:12 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02494 for ; Mon, 28 Oct 2002 17:35:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SMTQ804512 for ietf-calendar-bks; Mon, 28 Oct 2002 14:29:26 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SMTOW04508 for ; Mon, 28 Oct 2002 14:29:24 -0800 (PST) Received: from Royer.com (mail.inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SMTOIR018127; Mon, 28 Oct 2002 14:29:25 -0800 Message-ID: <3DBDBA42.2040708@Royer.com> Date: Mon, 28 Oct 2002 15:29:22 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: COMPONENTS [Was Re: GET-CAPABILITY - reply] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000205030609020601090809" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000205030609020601090809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > WRT COMPONENTs in GET-CAPABILITY, Doug proposed: > > COMPONENTS 1 A comma separated list of the names of > components that are supported. This > includes any components inside of > other components (VALARM for example). > MUST include at least VCALSTORE, VCALENDAR, > VREPLY, and VAGENDA and at least one of VEVENT, > VTODO, VTIMEZONE, or VJOURNAL. The defalt > is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, > VEVENT,VALARM,VTIMEZONE" > > The last line is not gramatically correct. It should start with > something like "This list MUST include..." No, there is no such MUST. It is correct. The default value for COMPONENTS is (as listed...). > Also, is there any reason why the 'base' components of VTODO and > VJOURNAL are not also in the default list? Nope. --------------ms000205030609020601090809 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODIyMjkyMlowIwYJKoZIhvcNAQkEMRYEFH2qi4P3 UdygY6Df/YJbOfmO6FUuMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAp5YPTos5JnnijVYRf N0fenMn9n8PMpuJaO85aV4Unc+gvqAYP39afoIR+LdYtB1aKqGCfyy8FJZK6FcNtnPvXtZdn zbieygHfkSPCXzN1zQyh0NhbhQg4XX5Fl26FB1V51HZgwIDLw1XdhmeDzVDZgfj8RUVK6rz8 yEjm1YJa6iV4JsBQu+V8DO9s1PfKu7LRv3M+a7UGLy2hRJs5Nnf53dzPVKcZrtZKC7oeIU28 qvyzpkvNWVmJBmgQbJk2qXTcRZind/Qb7bTFGRLgqbN1D52jLcIXYZ36pTk0rGZQ+p6yqs60 Sw+UIBinG/QNne97CKwBhG6vbf34SGwZOu65AAAAAAAA --------------ms000205030609020601090809-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 17:40:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02546 for ; Mon, 28 Oct 2002 17:40:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SMWr904991 for ietf-calendar-bks; Mon, 28 Oct 2002 14:32:53 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SMWpW04985 for ; Mon, 28 Oct 2002 14:32:51 -0800 (PST) Received: from Royer.com (mail.inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SMWrIR018162 for ; Mon, 28 Oct 2002 14:32:53 -0800 Message-ID: <3DBDBB12.4070609@Royer.com> Date: Mon, 28 Oct 2002 15:32:50 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - No more QUERY-LEVEL? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090408080006080906050806" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090408080006080906050806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This text *IS* in the latest draft (and all versions that I can find have at least one of the versions of): QUERY-LEVEL 1 Indicates level of SQL support. The default is CAL-QL-1 and CAL-QL-NONE can be supplied. (CAL-QL-NONE is for CS's that allow ITIP methods only to be deposited and nothing else). The default value is CAL-QL-1. Bruce_Kahn@notesdev.ibm.com wrote: > > In catching up the proposed CAP changes (and draft skewage) I see that > the latest proposal posted has no QUERY-LEVEL as part of GET-CAPABILITY > but the draft at http://inet-consulting.com/cap-09-b.txt does. Was > there recent talk of droping this from the draft that I missed or was > this an oversight? > > If QUERY-LEVEL: NONE is no more then what is the functional replacement > for it? > > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms090408080006080906050806 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODIyMzI1MFowIwYJKoZIhvcNAQkEMRYEFEJYs3NO JwTKbtxOZOiEB4NJm6TFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCDnLOB5SPtITugGfzd qn8OItrLvX+/LGggBaWG5ZCzUvdpTDmbrenKxz/ZYA8rRmtaH3FDAXryuE+h2SztPdrM+qRt 8z2Z/2RnFlGdGkvx8X9gSq5PTO5Zn6phFa8/a2vMqk9kGWQ7Fjcy3acUsQedS1fXgCnf5i2O ssru+gd4UGTm3R5PIVR6eU5Q7REY64OOLoGC2AG9XORIeDWCXvtF6BIBYHZ6tiHdeLgT4ePv IHGNQa1SBqz9x/+Xxmq8nCHt5Ne7YFmuuRf2nbGk3jjpduGAKDZYqYuevagWPvZ6ZViq6drm vVI8rlhXFVchSbO4k2AEkjdP75AVk1rkl9z3AAAAAAAA --------------ms090408080006080906050806-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 17:44:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02611 for ; Mon, 28 Oct 2002 17:44:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SMZYg05425 for ietf-calendar-bks; Mon, 28 Oct 2002 14:35:34 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SMZXW05418 for ; Mon, 28 Oct 2002 14:35:33 -0800 (PST) Received: from Royer.com (mail.inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SMZVIR018189 for ; Mon, 28 Oct 2002 14:35:32 -0800 Message-ID: <3DBDBBB1.4080304@Royer.com> Date: Mon, 28 Oct 2002 15:35:29 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - reply References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070509030701020803020904" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070509030701020803020904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Are you reading from? http://inet-consulting.com/cap-09-b-2.txt The text you provided is not in -b-2. (And I am on the ietf-calendar@imc.org mailing list, please do not send a separate copy to me - thanks!) Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote: > CAR-LEVEL 1 Indicates level of CAR support. CAR-NONE, > CAR-MIN or CAR-FULL-1. If CAR-FULL-1 is > supplied then CAR-MIN MUST BE assumed. > CAR = NONE MUST BE used when query-level > of NONE is supplied. > > That last line is a bit non-sensical or unclear to me. "CAR = NONE"?? > The last "NONE" reference should be "CAR-NONE" 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... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070509030701020803020904 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODIyMzUyOVowIwYJKoZIhvcNAQkEMRYEFJ7nFr6K Xh78oBH39nUP4vdkNG6IMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAIILZCOTiHs4iNskA/ Xd5Id9REpXp4bax+xaHw+B4M7C6jIWs9PNLIBklLWOTOk2N12G0rKJ9nE011Yjm38SptV1eE M666SORXXFxPA/YLjkPoYejS3KkB0bJBQrnMVFku1Wmqz4tVhv9+7p8C5wQkaD298Cvi/ALd Ptq5eir/8fnscM+3qzn9LzOMExZRyeiQvp6N/b5+tCzdT4NTU8wQ4r4p1Q+gXszqvTyKHtp3 3AgYRrnDEQrDuVPV/IfXLgmqqsu97rlRsSMtVaefqOChFF4z3sXf6f5eWuhRvixqn6Fy6epm JjAKMjwUrp5t92RB09TWvH96oMtakpKq4SawAAAAAAAA --------------ms070509030701020803020904-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 17:46:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02641 for ; Mon, 28 Oct 2002 17:46:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SMcsY05897 for ietf-calendar-bks; Mon, 28 Oct 2002 14:38:54 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SMcrW05891 for ; Mon, 28 Oct 2002 14:38:53 -0800 (PST) Received: from Royer.com (mail.inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SMctIR018198 for ; Mon, 28 Oct 2002 14:38:55 -0800 Message-ID: <3DBDBC7C.10609@Royer.com> Date: Mon, 28 Oct 2002 15:38:52 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000908020708040305020100" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000908020708040305020100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug proposed: > > Property Parameters: Non-standard property parameters can be > > specified on this property. > > > [Snip] > > Formal Definition: The property is defined by the following notation: > > > > attcounter = "ATT-COUNTER" *(";" xparam) ":" cal-address CRLF No - the ATT-COUNTER property does not take SENT-BY, CN, or the LANG parameters. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms000908020708040305020100 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODIyMzg1MlowIwYJKoZIhvcNAQkEMRYEFOyIKYCn ozr5mmg4ivEFVuTBcN+oMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBWyS/MNO2fd1SjHUVd yPhsP5jRZRUOEWD0NjfDNIu1CXq9vZIQ+za1Hu5pGqb+LBk6ifxky4Iy3W1OayoxnTITdKfP bi1ebF+AC5cjvl5oftSHRpzYETBV44UHfwSmAjZNoAhwnWf0tMNUJcAIqfOn+nyrxp/wR9eS gzikcSqtWdK869aWD9Xr5FgfylkdB575ORGBNSomcffqKGAGDNvCwGkiUzqQSmRFZD/+6T2d xozM+RoGKwFqJyb4Vm/AblusdWknkHRwuxC90e+1NxHzy55uFF7YX6J009fNk71U6IFFIRZE XJxXGwHkRD7vCA+FovDhnWDG+yNzs/jofPV5AAAAAAAA --------------ms000908020708040305020100-- From owner-ietf-calendar@mail.imc.org Mon Oct 28 17:59:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03020 for ; Mon, 28 Oct 2002 17:59:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9SMqUa07517 for ietf-calendar-bks; Mon, 28 Oct 2002 14:52:30 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9SMqTW07511 for ; Mon, 28 Oct 2002 14:52:29 -0800 (PST) Received: from Royer.com (mail.inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9SMqRIR018358 for ; Mon, 28 Oct 2002 14:52:27 -0800 Message-ID: <3DBDBFA8.4040207@Royer.com> Date: Mon, 28 Oct 2002 15:52:24 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070400040702040204030703" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070400040702040204030703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > Also, the Property Parameters text should be more like: > > Property Parameters: Non-standard, language, sent by or common name > property parameters can be specified on this property. > Do we need a Conformance section (ala ATTENDEE) that says something like: > > Conformance: This property MUST be specified in an iCalendar object > that specifies counter proposal to a group scheduled calendar entity. > This property MUST NOT be specified in an iCalendar object when > publishing the calendar information (e.g., NOT in an iCalendar > object that specifies the publication of a calendar user's busy time, > event, to-do or journal). This property is not specified in an > iCalendar object that specifies only a time zone definition or > that defines calendar entities that are not group scheduled entities > which are not being counter proposed. > > Better wordsmithing is probably in order but the intent is clear and its > use properly restricted. At is MUST BE added to all METHOD:COUNTER objects by the CUA, how about: Conformance: This property MUST be specified in an iCalendar object that specifies counter proposal to a group scheduled calendar entity. When storing a "METHOD" property with the "COUNTER" method, there needs to be a way to remember who sent the COUNTER. The ATT-COUNTER property MUST BE added to all "COUNTER" [iTIP] components by the CUA before storing in a CS. The rest of the objects you list could never have a COUNTER method, so the rest of the text is unnecessary. You can't say METHOD:PUBLISH and METHOD:COUNTER in the same object - for example. And you do not COUNTER a time-zone. - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070400040702040204030703 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyODIyNTIyNVowIwYJKoZIhvcNAQkEMRYEFDy3F9Mp DRCLnXWOODlriYg1IKVBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCYvaY6xgx6oc7gaicC AWHMUL4mLZlyVMnaZ8TdLR4cD6lUNr+fscm1RzxpMZ24bdO8JiYO/LyvSOhoD8kGR/uUe57w ieAzAWMD1z/z7msAVSpN00RuWp2NjoRadFRvjgMsUPGDTzVuxlEiBEC+pxzMuw1z2QTq4afx D9kphycRghHozv7QHlyy1i6Q0Ys6F/k19mtXLwNKQ/LYBZlSvswEf2rhQJLblb5iJj/T27Er NoTAAE23ZqyNgLZNr5g4m6ZnfuO53tRUzgqHxelHGG0FULmWriolMMNsShbdavML+pBo+SiP PgxBvTV+IgfjNlBrG5lIfrDflx9SKzLFSkUMAAAAAAAA --------------ms070400040702040204030703-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 04:12:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25687 for ; Tue, 29 Oct 2002 04:12:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9T92bw26558 for ietf-calendar-bks; Tue, 29 Oct 2002 01:02:37 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9T92ZW26530 for ; Tue, 29 Oct 2002 01:02:36 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 40F8F1555F; Tue, 29 Oct 2002 10:02:34 +0100 (CET) Date: Tue, 29 Oct 2002 10:02:34 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt Message-ID: <20021029090234.GA34722@inet.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 28, 2002 at 02:45:38PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > I for one think that even if you are a servlet/portlet writer that its > still useful for the CS to know what your script driven CUA can do. I As long as the default is clearly defined, I think the CS knows what the CUA can do even if the CUA doesn't implement GET-CAPABILITY - it means the CUA has no problem with the defaults. > I would prefer to use some hindsight from our iCalendar / iTIP / iMIP work > and put a firm stake in the CAP spec that says BOTH sides MUST support > GET-CAPABILITY so that either side can reasonably expect to have info > about the others capabilities. Anyway, I can see your point of view, and it's not that big an issue for me, so I'll go with the majority. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Tue Oct 29 11:17:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11337 for ; Tue, 29 Oct 2002 11:17:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TGA2904171 for ietf-calendar-bks; Tue, 29 Oct 2002 08:10:02 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TGA0W04166 for ; Tue, 29 Oct 2002 08:10:00 -0800 (PST) In-Reply-To: <43D0E73C-E6BE-11D6-B6A3-003065A8EEFC@inet.it> To: Andrea Campi Cc: Doug Royer , ietf-calendar@imc.org Subject: Re: 6.1.1 CAL-QUERY Value Type MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 11:09:59 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 11:03:49 AM, Serialize complete at 10/29/2002 11:03:49 AM Content-Type: multipart/alternative; boundary="=_alternative 0058EBA485256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058EBA485256C61_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 10/23/2002 03:33:10 PM: > sorry I can't find a proper proposal for this (though I mentioned it in > I mentioned it in <20020906134355.GF32393@inet.it>), but since it's an > obvious error, I propose to fix it right now. > > > Rules 6 and he example have the syntax component.*: > > SELECT VALARM.* FROM VEVENT WHERE UID = "123" > > But the ABNF doesn't allow this. Correct. Given that the example used is a fairly common one Id say the ABNF needs some changing. > IMHO it should be something like: > > cap-col = ; Any property name found in the component > ; named in the comp-name used in the "FROM" clause. > ; > ; SELECT ORGANIZER FROM VEVENT ... > ; > ; OR > ; > ; A component name of an existing component contained > ; inside of the comp-name used in the "FROM" clause. > ; > ; SELECT VALARM FROM VEVENT ... > ; > ; OR > ; > ; Any property name found in any component contained > ; inside of the comp-name used in the "FROM" clause; the > ; component and property name are separated by a dot '.' > ; > ; SELECT * FROM VEVENT WHERE VALARM.TRIGGER < '20020201T000000Z' In looking at the changetext you proposed I notice that there is still no 'terminal' values for the cap-col ABNF entry, only text. I do not think this is legal. I expect that the ABNF needs to be formatted like: cap-col = ; Any property name found in the component ; named in the comp-name used in the "FROM" clause. ; ; SELECT ORGANIZER FROM VEVENT ... ( cap-col-prop / ; OR ; ; A component name of an existing component contained ; inside of the comp-name used in the "FROM" clause. ; ; SELECT VALARM FROM VEVENT ... cap-col-prop2 cap-col-prop = eventprop ;Legal properties for a "VEVENT". cap-col-prop2 = ( eventprop / alarmc ) ;Legal properties and contained ; objects for a "VEVENT" . cap-col-prop /= todoprop ;Legal properties for a "VTODO". cap-col-prop2 /= ( todoprop / alarmc ) ;Legal properties and contained ; objects for a "VTODO" . ... Where we use the "/=" ABNF notation to restrict what properties are usable when. In the case above Ive restricted the cap-col values for a VEVENT to be just those eventprop values defined in RFC 2445. Yes, doing this will cause ABNF to get more complex but it will allow us to avoid any crocks like the one you described (plus I dont think we can have a dangling ABNF like we do now). My ABNF crafting on the fly is not so great but I think the intent is at least clear enough. We can get a ANBF guru to tune it as appropriate if we decide to make it work right. > However, AFAIK we never discussed this before, so we might want to fix > this it later on. Actually I raised this at the IETF in February/March in hallway talks w/Steve & the Steltor contingant. Guess it didnt get reflected in any changes since then. I think that we need to be able to do as you noted in the initial version of the protocol since its a very common thing to want to do. 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 0058EBA485256C61_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 10/23/2002 03:33:10 PM:
> sorry I can't find a proper proposal for this (though I mentioned it in
> I mentioned it in <20020906134355.GF32393@inet.it>), but since it's an
> obvious error, I propose to fix it right now.
>
>
> Rules 6 and he example have the syntax component.*:
>
>   SELECT VALARM.* FROM VEVENT WHERE UID = "123"
>
> But the ABNF doesn't allow this.
Correct.  Given that the example used is a fairly common one Id say the ABNF needs some changing.

> IMHO it should be something like:
>
>            cap-col    = ; Any property name found in the component
>                         ; named in the comp-name used in the "FROM" clause.
>                         ;
>                         ;   SELECT ORGANIZER FROM VEVENT ...
>                         ;
>                         ; OR
>                         ;
>                         ; A component name of an existing component contained
>                         ; inside of the comp-name used in the "FROM" clause.
>                         ;
>                         ;   SELECT VALARM FROM VEVENT ...
>                         ;
>                         ; OR
>                         ;
>                         ; Any property name found in any component contained
>                         ; inside of the comp-name used in the "FROM" clause; the
>                         ; component and property name are separated by a dot '.'
>                         ;
>                         ;  SELECT * FROM VEVENT WHERE VALARM.TRIGGER < '20020201T000000Z'
In looking at the changetext you proposed I notice that there is still no 'terminal' values for the cap-col ABNF entry, only text.  I do not think this is legal.  I expect that the ABNF needs to be formatted like:

           cap-col    = ; Any property name found in the component
                       ; named in the comp-name used in the "FROM" clause.
                       ;
                       ;   SELECT ORGANIZER FROM VEVENT ...
                        ( cap-col-prop /

                        ; OR
                       ;
                       ; A component name of an existing component contained
                       ; inside of the comp-name used in the "FROM" clause.
                       ;
                       ;   SELECT VALARM FROM VEVENT ...
                        cap-col-prop2

           cap-col-prop   = eventprop       ;Legal properties for a "VEVENT".

           cap-col-prop2  = ( eventprop / alarmc )  ;Legal properties and contained
                                                   ; objects for a "VEVENT" .

           cap-col-prop  /= todoprop        ;Legal properties for a "VTODO".

           cap-col-prop2 /= ( todoprop / alarmc )  ;Legal properties and contained
                                                   ; objects for a "VTODO" .
...

Where we use the "/=" ABNF notation to restrict what properties are usable when.  In the case above Ive restricted the cap-col values for a VEVENT to be just those eventprop values defined in RFC 2445.  Yes, doing this will cause ABNF to get more complex but it will allow us to avoid any crocks like the one you described (plus I dont think we can have a dangling ABNF like we do now).

My ABNF crafting on the fly is not so great but I think the intent is at least clear enough.  We can get a ANBF guru to tune it as appropriate if we decide to make it work right.

> However, AFAIK we never discussed this before, so we might want to fix
> this it later on.
Actually I raised this at the IETF in February/March in hallway talks w/Steve & the Steltor contingant.  Guess it didnt get reflected in any changes since then.   I think that we need to be able to do as you noted in the initial version of the protocol since its a very common thing to want to do.

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 0058EBA485256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 11:34:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12151 for ; Tue, 29 Oct 2002 11:34:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TGJon04827 for ietf-calendar-bks; Tue, 29 Oct 2002 08:19:50 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TGJnW04822 for ; Tue, 29 Oct 2002 08:19:49 -0800 (PST) To: ietf-calendar@imc.org Subject: Editorial suggestion for 2.1 New Value Types MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 11:19:48 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 11:13:38 AM, Serialize complete at 10/29/2002 11:13:38 AM Content-Type: multipart/alternative; boundary="=_alternative 0059D1F885256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059D1F885256C61_= Content-Type: text/plain; charset="US-ASCII" In catching up on the recent postings I looked at Section 2.1 and found the first bits a bit hard to eyeball and read. In particular: UPN The UPN value type is text value type restricted to only UPN values. (Section 6.1.2) UPN-FILTER Like the UPN value type, but also includes filter rules that allow wildcards. (Section 6.1.3) CALQUERY The "CAL-QUERY" (Section 6.1.1) value type is a query syntax that is used by the CUA to specify the rules that apply to a CAP command. In the case of "SEARCH", the query language is used to fetch objects from the CS. When used with "DELETE", the selected objects are deleted from the CS. "CAL-QUERY" can also be used with "MOVE" and "MODIFY". The sentences seemed to blur. When I saw Section 2.1.1 New Parameters I was able to scan it easier. Id like to suggest changing the format of the above to be: UPN The UPN value type is text value type restricted to only UPN values. (Section 6.1.2) UPN-FILTER Like the UPN value type, but also includes filter rules that allow wildcards. (Section 6.1.3) CALQUERY The "CAL-QUERY" (Section 6.1.1) value type is a query syntax that is used by the CUA to specify the rules that apply to a CAP command. In the case of "SEARCH", the query language is used to fetch objects from the CS. When used with "DELETE", the selected objects are deleted from the CS. "CAL-QUERY" can also be used with "MOVE" and "MODIFY". If you want to be totally consistant you can also put hyphens at the end of the 'header' lines like in 2.1.1. 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 0059D1F885256C61_= Content-Type: text/html; charset="US-ASCII"
In catching up on the recent postings I looked at Section 2.1 and found the first bits a bit hard to eyeball and read.  In particular:

   UPN The UPN value type is text value type restricted to only UPN
     values.  (Section 6.1.2)

  UPN-FILTER Like the UPN value type, but also includes filter rules
     that allow wildcards.  (Section 6.1.3)

  CALQUERY The "CAL-QUERY" (Section 6.1.1) value type is a query syntax
     that is used by the CUA to specify the rules that apply to a CAP
     command.  In the case of "SEARCH", the query language is used to
     fetch objects from the CS.  When used with "DELETE", the selected
     objects are deleted from the CS.  "CAL-QUERY" can also be used
     with "MOVE" and "MODIFY".
The sentences seemed to blur.  When I saw Section 2.1.1 New Parameters I was able to scan it easier. Id like to suggest changing the format of the above to be:

   UPN
      The UPN value type is text value type restricted to only UPN
     values.  (Section 6.1.2)

  UPN-FILTER
      Like the UPN value type, but also includes filter rules
     that allow wildcards.  (Section 6.1.3)

  CALQUERY
      The "CAL-QUERY" (Section 6.1.1) value type is a query syntax
     that is used by the CUA to specify the rules that apply to a CAP
     command.  In the case of "SEARCH", the query language is used to
     fetch objects from the CS.  When used with "DELETE", the selected
     objects are deleted from the CS.  "CAL-QUERY" can also be used
     with "MOVE" and "MODIFY".

If you want to be totally consistant you can also put hyphens at the end of the 'header' lines like in 2.1.1.

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 0059D1F885256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 11:49:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12950 for ; Tue, 29 Oct 2002 11:49:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TGXgH06469 for ietf-calendar-bks; Tue, 29 Oct 2002 08:33:42 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TGXfW06462 for ; Tue, 29 Oct 2002 08:33:41 -0800 (PST) In-Reply-To: <3DB9B1BB.50305@oracle.com> To: George Babics Cc: ietf-calendar@imc.org Subject: Re: Removing Duplicated Info MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 11:33:40 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 11:27:29 AM, Serialize complete at 10/29/2002 11:27:29 AM Content-Type: multipart/alternative; boundary="=_alternative 005B16B385256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B16B385256C61_= Content-Type: text/plain; charset="US-ASCII" George wrote on 10/25/2002 05:03:55 PM: > >> Sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1, 8.1, and 8.2 > >> contain summary definitions of properties, parameters, > >> and value types that are formally defined elsewhere. > >> Should we remove these summary definitions? [Snip] > We can always put the formal definitions first and remove > the duplicate information. I grok both sides of the discussion here but Im curious to know why we have a 'summary' section and then intervening sections and then formal definitions towards the end. Why isnt the draft structured so that its a bit more like 2445? In that I mean that we first defined our data types and then our properties and then we defined the usage/combination of them. We didnt give a summary of them, the model of how to use the summarized stuff and then fhe formal definition of the new stuff. It does seem a bit backwards from an organizational POV... Reorganizing like 2445 would make reading the draft a bit easier and it would remove the need to have Section 2.1x marked as 'summary' and then more info later on in Sections 6.x, 7.x and 8.x... For the next big rev I think Georges suggestion of 6.x, 7.x and 8.x being relabeled as 6.1, 6.2 and 6.2 since they are all additions to iCalendar and logically belong in the same section. But Im not suggesting we do it for Atlanta. 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 005B16B385256C61_= Content-Type: text/html; charset="US-ASCII"
George wrote on 10/25/2002 05:03:55 PM:
> >> Sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1, 8.1, and 8.2
> >> contain summary definitions of properties, parameters,
> >> and value types that are formally defined elsewhere.
> >> Should we remove these summary definitions?
[Snip]
>    We can always put the formal definitions first and remove
> the duplicate information.
I grok both sides of the discussion here but Im curious to know why we have a 'summary' section and then intervening sections and then formal definitions towards the end.  Why isnt the draft structured so that its a bit more like 2445?  In that I mean that we first defined our data types and then our properties and then we defined the usage/combination of them.  We didnt give a summary of them, the model of how to use the summarized stuff and then fhe formal definition of the new stuff.  It does seem a bit backwards from an organizational POV...

Reorganizing like 2445 would make reading the draft a bit easier and it would remove the need to have Section 2.1x marked as 'summary' and then more info later on in Sections 6.x, 7.x and 8.x...

For the next big rev I think Georges suggestion of 6.x, 7.x and 8.x being relabeled as 6.1, 6.2 and 6.2 since they are all additions to iCalendar and logically belong in the same section.  But Im not suggesting we do it for Atlanta.

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 005B16B385256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 11:55:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13333 for ; Tue, 29 Oct 2002 11:55:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TGjRF07825 for ietf-calendar-bks; Tue, 29 Oct 2002 08:45:27 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TGjJW07821 for ; Tue, 29 Oct 2002 08:45:19 -0800 (PST) In-Reply-To: <3DB9AC27.8090409@Royer.com> To: ietf-calendar@imc.org Subject: Re: 3.1 System Model MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 11:45:17 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 11:39:08 AM, Serialize complete at 10/29/2002 11:39:08 AM Content-Type: multipart/alternative; boundary="=_alternative 005C272085256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C272085256C61_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/25/2002 04:40:07 PM: > C: Content-Type: text/calendar > C: > C: BEGIN:VCALENDAR > C: VERSION:2.0 > C: PRODID:-//someone's prodid > C: CMD:GET-CAPABILITY > C: END:VCALENDAR > C: END Putting on my Method Revier hat I just wanted to point out that the above is illegal per RFC 2445 ABNF. The relevant ABNF is: icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF icalbody "END" ":" "VCALENDAR" CRLF) icalbody = calprops component calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once prodid /version / ; 'calscale' and 'method' are optional, ; but MUST NOT occur more than once calscale / method / x-prop ) component = 1*(eventc / todoc / journalc / freebusyc / / timezonec / iana-comp / x-comp) Those who nitpick will have noted the source of the issue: the "1*" on component. Per 2445 ABNF, there must be some container w/in the VCALENDAR object. I thought that this was valid before, perhaps if a VAGENDA container was used but I dont keep my old paper drafts that far back. In any case, I wanted to point this out... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005C272085256C61_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/25/2002 04:40:07 PM:
>        C: Content-Type: text/calendar
>        C:
>        C: BEGIN:VCALENDAR
>        C: VERSION:2.0
>        C: PRODID:-//someone's prodid
>        C: CMD:GET-CAPABILITY
>        C: END:VCALENDAR
>        C: END
Putting on my Method Revier hat I just wanted to point out that the above is illegal per RFC 2445 ABNF.  The relevant ABNF is:

     icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
                 icalbody
                 "END" ":" "VCALENDAR" CRLF)
     icalbody   = calprops component

    calprops   = 2*(

               ; 'prodid' and 'version' are both REQUIRED,
               ; but MUST NOT occur more than once

               prodid /version /

               ; 'calscale' and 'method' are optional,
               ; but MUST NOT occur more than once

               calscale        /
               method          /

               x-prop
               )

    component  = 1*(eventc / todoc / journalc / freebusyc /
               / timezonec / iana-comp / x-comp)

Those who nitpick will have noted the source of the issue: the "1*" on component.  

Per 2445 ABNF, there must be some container w/in the VCALENDAR object.  I thought that this was valid before, perhaps if a VAGENDA container was used but I dont keep my old paper drafts that far back.  In any case, I wanted to point this out...

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

--=_alternative 005C272085256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 12:10:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14274 for ; Tue, 29 Oct 2002 12:10:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TH3hY08325 for ietf-calendar-bks; Tue, 29 Oct 2002 09:03:43 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TH3gW08320 for ; Tue, 29 Oct 2002 09:03:43 -0800 (PST) In-Reply-To: <3DBD7CF0.4020907@Royer.com> To: ietf-calendar@imc.org Subject: Re: Sections 7 And 8: Comments And Fixes MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 12:03:38 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 11:57:31 AM, Serialize complete at 10/29/2002 11:57:31 AM Content-Type: multipart/alternative; boundary="=_alternative 005DD55085256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DD55085256C61_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/28/2002 01:07:44 PM: > And not all sections need examples - Pat? Bob? I thought > we wanted to remove as many examples as possible? That would mean removing all examples if you take it to the extreme. However, as one who detests those that live by example alone I do think that having some examples is good. For example, the big batch that Frank put in 2445 for the recurrence rule are good and helped cover lots of bases (although not all). 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 005DD55085256C61_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/28/2002 01:07:44 PM:
> And not all sections need examples - Pat? Bob? I thought
> we wanted to remove as many examples as possible?
That would mean removing all examples if you take it to the extreme.  However, as one who detests those that live by example alone I do think that having some examples is good.  For example, the big batch that Frank put in 2445 for the recurrence rule are good and helped cover lots of bases (although not all).

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 005DD55085256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 12:16:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14570 for ; Tue, 29 Oct 2002 12:16:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TH8bA08459 for ietf-calendar-bks; Tue, 29 Oct 2002 09:08:37 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TH8aW08455 for ; Tue, 29 Oct 2002 09:08:36 -0800 (PST) To: ietf-calendar@imc.org Subject: 3.2 Calendar Store Object Model MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 12:08:34 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 12:02:25 PM, Serialize complete at 10/29/2002 12:02:25 PM Content-Type: multipart/alternative; boundary="=_alternative 005E48E485256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E48E485256C61_= Content-Type: text/plain; charset="US-ASCII" Just a quick editorial note. In the Calendar Store hierarchy diagram there is (in part): +-- VAGENDAs | | | +--properties | +--VEVENTs | | | | | +--VALARMs | +--VTODOs | | | | | +--VALARMs | +--VJOURNALs | +--VCARs | +--VTIMEZONEs | +--VQUERYs | +--VFREEBUSY | | | | ... . . +-- VAGENDAs . . . . . . The 2nd VAGENDAs is superfluous and should be removed. 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 005E48E485256C61_= Content-Type: text/html; charset="US-ASCII"
Just a quick editorial note. In the Calendar Store hierarchy diagram there is (in part):

       +-- VAGENDAs
      |     |
      |     +--properties
      |     +--VEVENTs
      |     |    |
      |     |    +--VALARMs
      |     +--VTODOs
      |     |    |
      |     |    +--VALARMs
      |     +--VJOURNALs
      |     +--VCARs
      |     +--VTIMEZONEs
      |     +--VQUERYs
      |     +--VFREEBUSY
      |     |
      |     |   ...
      .
      .
      +-- VAGENDAs
      .     .
      .     .
      .     .
The 2nd VAGENDAs is superfluous and should be removed.

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 005E48E485256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 12:23:51 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14947 for ; Tue, 29 Oct 2002 12:23:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9THCvS08995 for ietf-calendar-bks; Tue, 29 Oct 2002 09:12:57 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9THCuW08990 for ; Tue, 29 Oct 2002 09:12:57 -0800 (PST) To: ietf-calendar@imc.org Subject: 9.3 GET-CAPABILITY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 12:12:48 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 12:06:45 PM, Serialize complete at 10/29/2002 12:06:45 PM Content-Type: multipart/alternative; boundary="=_alternative 005EAC2985256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005EAC2985256C61_= Content-Type: text/plain; charset="US-ASCII" In reading the 09-b draft (that better be the latest, Im tired of chasing new links) I see in Section 9.3 GET-CAPABILITY Command that there is an ABNF for the command side of the command but no ABNF for the response side. Shouldnt we have one?? We have 'em for other CAP commands like GENERATE-UID: gen-reply = "BEGIN" ":" "VCALENDAR" CRLF calprops 1*(gen-vreply) "END" ":" "VCALENDAR" CRLF gen-vreply = "BEGIN" ":" "VREPLY" CRLF *(uid) request-status "END" ":" "VREPLY" CRLF 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 005EAC2985256C61_= Content-Type: text/html; charset="US-ASCII"
In reading the 09-b draft (that better be the latest, Im tired of chasing new links) I see in Section 9.3 GET-CAPABILITY Command that there is an ABNF for the command side of the command but no ABNF for the response side.  Shouldnt we have one??  We have 'em for other CAP commands like GENERATE-UID:

           gen-reply  = "BEGIN" ":" "VCALENDAR" CRLF
                        calprops
                        1*(gen-vreply)
                       "END" ":" "VCALENDAR" CRLF
          gen-vreply  = "BEGIN" ":" "VREPLY" CRLF
                        *(uid)
                        request-status
                       "END" ":" "VREPLY" CRLF
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 005EAC2985256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 13:23:25 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17722 for ; Tue, 29 Oct 2002 13:23:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TIGco13832 for ietf-calendar-bks; Tue, 29 Oct 2002 10:16:38 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TIGZW13821 for ; Tue, 29 Oct 2002 10:16:35 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TIGPIR026634; Tue, 29 Oct 2002 10:16:27 -0800 Message-ID: <3DBED076.9040201@Royer.com> Date: Tue, 29 Oct 2002 11:16:22 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 9.3 GET-CAPABILITY Command References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000400010708000007000201" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000400010708000007000201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In reading the 09-b draft (that better be the latest, Im tired of > chasing new links) It's not, that's the point of this list :-) -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms000400010708000007000201 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTE4MTYyMlowIwYJKoZIhvcNAQkEMRYEFC2HqJ87 5WxdWyuNCDzxSgqzVs05MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAUg7Wc7txp7Kaflnam AZn7pxm9pVQaLEAfG/kWjBp/ZFUN9wBv6rMOjBYLhCQPQEjaH95BSdelcOZmbkKyLBgEk+JQ rO6mP7LDN6Rq1n3OCY+7rsMhGJGlnCFPh/CDjgFNHDRhTSIr5Bzpzy30H+/hNJfjszdXPcB4 F5AN7nhALjkMmjSBogu7o+vnS3T3BYCrluyGIWdhrAilOtAPI+Oidegx9+TPYqxnW+DDrZ2s YJ7h6UgLw9b7gB47LQW//0hWEBFzXJQbae4Gn8zSkJXHL+ArSNz2NZ5YPAF/VP7CdFXvY6Ov 0TMIS7FlG9HtEDS1oAEFe6lAJvsHhn/MNK+KAAAAAAAA --------------ms000400010708000007000201-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 13:24:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17784 for ; Tue, 29 Oct 2002 13:24:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TIIOR14108 for ietf-calendar-bks; Tue, 29 Oct 2002 10:18:24 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TIILW14100 for ; Tue, 29 Oct 2002 10:18:21 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TIIIIR026643 for ; Tue, 29 Oct 2002 10:18:20 -0800 Message-ID: <3DBED0E0.9060003@Royer.com> Date: Tue, 29 Oct 2002 11:18:08 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 3.1 System Model References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020407040504060308040301" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms020407040504060308040301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Are you saing my email had an error - or the draft? Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 10/25/2002 04:40:07 PM: > > C: Content-Type: text/calendar > > C: > > C: BEGIN:VCALENDAR > > C: VERSION:2.0 > > C: PRODID:-//someone's prodid > > C: CMD:GET-CAPABILITY > > C: END:VCALENDAR > > C: END > > Putting on my Method Revier hat I just wanted to point out that the > above is illegal per RFC 2445 ABNF. The relevant ABNF is: > > icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF > icalbody > "END" ":" "VCALENDAR" CRLF) > > icalbody = calprops component > > calprops = 2*( > > ; 'prodid' and 'version' are both REQUIRED, > ; but MUST NOT occur more than once > > prodid /version / > > ; 'calscale' and 'method' are optional, > ; but MUST NOT occur more than once > > calscale / > method / > > x-prop > ) > > component = 1*(eventc / todoc / journalc / freebusyc / > / timezonec / iana-comp / x-comp) > > Those who nitpick will have noted the source of the issue: the "1*" on > component. > > Per 2445 ABNF, there must be some container w/in the VCALENDAR object. > I thought that this was valid before, perhaps if a VAGENDA container > was used but I dont keep my old paper drafts that far back. In any > case, I wanted to point this out... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms020407040504060308040301 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTE4MTgwOFowIwYJKoZIhvcNAQkEMRYEFDNcozC2 Pe7eFB6b7tKA2wO4m9/GMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCmbXkIyETy+YTSFAc2 CgN970sLGaeNw5Nxbfdz/EB1qnol2Z1DjdYOf5XLm+aJU98G3fh6v8Z1CNOgxmblcpNa0Ajd YXbgTjU+YJjFY1eX/WIXSVpJVjJOaRrmbDJPjL1q1Hl+E/5koiAhCogMiVWzR+prLqD356K7 3KiBir3Rs4kO+YdFhsLBPQaNerhRENiMEnmqACkLhkp4g2ca2uNtcgdsbxex0xpSlu2jIQrH scXyI3h6AIemu6nYTfiGSo0rgI9jJsM8f1rgX/NJdMxG8X0kCb2A3mIgdfBjbUC3SGzdHUUF G3xO8OpiLoGMrZTsT/bo5dKfcw+n63bQ6bnbAAAAAAAA --------------ms020407040504060308040301-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 13:28:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17943 for ; Tue, 29 Oct 2002 13:28:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TIKmj14557 for ietf-calendar-bks; Tue, 29 Oct 2002 10:20:48 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TIKjW14544 for ; Tue, 29 Oct 2002 10:20:46 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TIKVIR026669 for ; Tue, 29 Oct 2002 10:20:32 -0800 Message-ID: <3DBED16B.8000908@Royer.com> Date: Tue, 29 Oct 2002 11:20:27 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 3.2 Calendar Store Object Model References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030209030002030002050307" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030209030002030002050307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Just a quick editorial note. In the Calendar Store hierarchy diagram > there is (in part): > > +-- VAGENDAs > ... > . > . > +-- VAGENDAs > . . > . . > . . > > The 2nd VAGENDAs is superfluous and should be removed. Why? It looks to me if it is saying there can be more than one. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms030209030002030002050307 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTE4MjAyN1owIwYJKoZIhvcNAQkEMRYEFDlMR5Gg q2UG+CMGL39g5XW9bB1tMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCNEI6UE+VKppSHfL6e 9Uu88waVpmzTyeQt/d+8Cimm4IWMw/65CMWpyWqgeYTF+g+nu48bvS1qf30LJJTLchcDZuhS rn3IBPIut40xi03V6Ng2Yf6stZCtt5M8sCwY17WtSkZkmEHyxRGgKb+iP7pO5wK/OkqES63w 2ZrcdCgAL/oPZw6sjEBs+gSAofAo4SIT9t60+gL/mkpM/mirM0BnHt7ze/U/TYizqa5HYnLG Ks3ERV6MAQ2WJ2EAPw53BTkMtsBofPsMNLje6ds64BBYpRzNcSeFhcEmcn1Ubdr6CiNeprHo KcMOSpq0ndljgnABi38psmJyOfNvPpm8orKYAAAAAAAA --------------ms030209030002030002050307-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 13:32:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18186 for ; Tue, 29 Oct 2002 13:32:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TIRoW15172 for ietf-calendar-bks; Tue, 29 Oct 2002 10:27:50 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TIRnW15168 for ; Tue, 29 Oct 2002 10:27:49 -0800 (PST) In-Reply-To: <3DBDBC7C.10609@Royer.com> To: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 13:27:27 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 01:21:37 PM, Serialize complete at 10/29/2002 01:21:37 PM Content-Type: multipart/alternative; boundary="=_alternative 006588E485256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006588E485256C61_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/28/2002 05:38:52 PM: > No - the ATT-COUNTER property does not take SENT-BY, CN, or the LANG > parameters. It needs to. Otherwise my AA cannot counter for me (or you have no way to tell that my AA did it for me in your UI will you?). The CN and LANG property parameters are also useful for the same reason they are useful on the ATTENDEE property. 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 006588E485256C61_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/28/2002 05:38:52 PM:
> No - the ATT-COUNTER property does not take SENT-BY, CN, or the LANG
> parameters.
It needs to.  Otherwise my AA cannot counter for me (or you have no way to tell that my AA did it for me in your UI will you?).  The CN and LANG property parameters are also useful for the same reason they are useful on the ATTENDEE property.

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 006588E485256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 14:02:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19796 for ; Tue, 29 Oct 2002 14:02:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TIujv16104 for ietf-calendar-bks; Tue, 29 Oct 2002 10:56:45 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TIuOW16081 for ; Tue, 29 Oct 2002 10:56:34 -0800 (PST) In-Reply-To: <3DBDBFA8.4040207@Royer.com> To: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 13:55:20 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 01:50:33 PM, Serialize complete at 10/29/2002 01:50:33 PM Content-Type: multipart/alternative; boundary="=_alternative 0068167085256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0068167085256C61_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 10/28/2002 05:52:24 PM: > At is MUST BE added to all METHOD:COUNTER objects by the CUA, how about: > > Conformance: This property MUST be specified in an iCalendar object > that specifies counter proposal to a group scheduled calendar entity. > When storing a "METHOD" property with the "COUNTER" method Make this ^^^^^^ 'value' instead of 'method' since its a value that can be on a METHOD property. > , there > needs to be a way to remember who sent the COUNTER. The ATT-COUNTER > property MUST BE added to all "COUNTER" [iTIP] components by > the CUA before storing in a CS. Nice wordsmithing... > The rest of the objects you list could never have a COUNTER method, so > the rest of the text is unnecessary. You can't say METHOD:PUBLISH > and METHOD:COUNTER in the same object - for example. And you > do not COUNTER a time-zone. The intent of my verbose text was to make it clear what components can contain an ATTCOUNTER and which cannot. Its semi-explicit when we use text like: Conformance: This property MUST BE specified in any component with the "METHOD" value of "COUNTER". because only VCALENDARs, at this point, can contain a METHOD property. The rest of the containers (ie: VEVENT, VTIMEZONE, VALARM, etc) are contained w/a VCALENDAR in the data stream. I just like being as clear as possible so noone tries to misplace the new property. We should make note that the new ATTCOUNTER property (I dislike the hyphen) means a change to the ABNF in 2445 to become: calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once prodid /version / ; 'calscale' and 'method' are optional, ; but MUST NOT occur more than once calscale / method / ; 'attcounter' is ONLY permitted if 'method' ; exists and has the value "COUNTER" ; and MUST NOT occur more than once attcounter / x-prop ) 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 0068167085256C61_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 10/28/2002 05:52:24 PM:
> At is MUST BE added to all METHOD:COUNTER objects by the CUA, how about:
>
>    Conformance: This property MUST be specified in an iCalendar object
>    that specifies counter proposal to a group scheduled calendar entity.
>    When storing a "METHOD" property with the "COUNTER" method

                                                                                                                                    Make this ^^^^^^ 'value' instead of 'method' since its a value that can be on a METHOD property.

>                                                               , there
>    needs to be a way to remember who sent the COUNTER. The ATT-COUNTER
>    property MUST BE added to all "COUNTER" [iTIP] components by
>    the CUA before storing in a CS.
Nice wordsmithing...

> The rest of the objects you list could never have a COUNTER method, so
> the rest of the text is unnecessary. You can't say METHOD:PUBLISH
> and METHOD:COUNTER in the same object - for example. And you
> do not COUNTER a time-zone.
The intent of my verbose text was to make it clear what components can contain an ATTCOUNTER and which cannot.  Its semi-explicit when we use text like:

    Conformance: This property MUST BE specified in any component
   with the "METHOD" value of "COUNTER".

because only VCALENDARs, at this point, can contain a METHOD property.  The rest of the containers (ie: VEVENT, VTIMEZONE, VALARM, etc) are contained w/a VCALENDAR in the data stream.  I just like being as clear as possible so noone tries to misplace the new property.  

We should make note that the new ATTCOUNTER property (I dislike the hyphen) means a change to the ABNF in 2445 to become:

     calprops   = 2*(

               ; 'prodid' and 'version' are both REQUIRED,
               ; but MUST NOT occur more than once

               prodid /version /

               ; 'calscale' and 'method' are optional,
               ; but MUST NOT occur more than once

               calscale        /
               method          /

               ; 'attcounter' is ONLY permitted if 'method'
                ; exists and has the value "COUNTER"
               ; and MUST NOT occur more than once

               attcounter      /
                x-prop
               )

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 0068167085256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 14:13:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20212 for ; Tue, 29 Oct 2002 14:13:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TJ65t16990 for ietf-calendar-bks; Tue, 29 Oct 2002 11:06:05 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TJ64W16982 for ; Tue, 29 Oct 2002 11:06:04 -0800 (PST) In-Reply-To: <3DBDBA42.2040708@Royer.com> To: ietf-calendar@imc.org Subject: Re: COMPONENTS [Was Re: GET-CAPABILITY - reply] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 14:05:43 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 01:59:53 PM, Serialize complete at 10/29/2002 01:59:53 PM Content-Type: multipart/alternative; boundary="=_alternative 0069099D85256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069099D85256C61_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/28/2002 05:29:22 PM: > > COMPONENTS 1 A comma separated list of the names of > > components that are supported. This > > includes any components inside of > > other components (VALARM for example). > > MUST include at least VCALSTORE, VCALENDAR, > > VREPLY, and VAGENDA and at least one of VEVENT, > > VTODO, VTIMEZONE, or VJOURNAL. The defalt > > is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, > > VEVENT,VALARM,VTIMEZONE" > > > > The last line is not gramatically correct. It should start with > > something like "This list MUST include..." > > No, there is no such MUST. It is correct. > The default value for COMPONENTS is (as listed...). Your sentence is technically accurate. Its not gramatically correct. You dont start a sentence with "MUST include...", you have no subject. > > Also, is there any reason why the 'base' components of VTODO and > > VJOURNAL are not also in the default list? > > Nope. Are you going to add them then?? 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 0069099D85256C61_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/28/2002 05:29:22 PM:
> >     COMPONENTS       1      A comma separated list of the names of
> >                            components that are supported. This
> >                            includes any components inside of
> >                            other components (VALARM for example).
> >                            MUST include at least VCALSTORE, VCALENDAR,
> >                            VREPLY, and VAGENDA and at least one of VEVENT,
> >                            VTODO, VTIMEZONE, or VJOURNAL. The defalt
> >                            is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,
> >                            VEVENT,VALARM,VTIMEZONE"
> >
> > The last line is not gramatically correct.  It should start with
> > something like "This list MUST include..."
>
> No, there is no such MUST. It is correct.
> The default value for COMPONENTS is (as listed...).
Your sentence is technically accurate.  Its not gramatically correct.  You dont start a sentence with "MUST include...", you have no subject.

> > Also, is there any reason why the 'base' components of VTODO and
> > VJOURNAL are not also in the default list?
>
> Nope.
Are you going to add them then??

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 0069099D85256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 14:16:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20390 for ; Tue, 29 Oct 2002 14:16:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TJBcJ17931 for ietf-calendar-bks; Tue, 29 Oct 2002 11:11:38 -0800 (PST) Received: from capricorn.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TJBaW17921 for ; Tue, 29 Oct 2002 11:11:36 -0800 (PST) In-Reply-To: <3DBDB8BE.5070008@Royer.com> To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 14:11:15 -0500 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09262002NP|September 26, 2002) at 10/29/2002 02:05:25 PM, Serialize complete at 10/29/2002 02:05:25 PM Content-Type: multipart/alternative; boundary="=_alternative 00698B6A85256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00698B6A85256C61_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 10/28/2002 05:22:54 PM: > Maybe I did miss your point > - but you did not answer my question. Is it valid > for the ORGANIZER to keep the SENT-BY values? > > I say yes. Im _FOR_ ATTCOUNTER so we dont have to keep going back & forth over that. I was for it in 2000 (go check) and Im for it now. My point about your example was that you used: ATTENDEE:...SENT-BY="MAILTO:a@a.com" ;PARTSTAT=accepted:MAILTO:a1@a.com as motivation. My response is simply this: you dont use a SENT-BY for yourself since you are not acting on your behalf. You are you and not someone acting as your proxy (ie: your AA). As such the example above is not correct (although its legal by just ABNF parsing). 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 00698B6A85256C61_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 10/28/2002 05:22:54 PM:
> Maybe I did miss your point
>   - but you did not answer my question. Is it valid
> for the ORGANIZER to keep the SENT-BY values?
>
> I say yes.
Im _FOR_ ATTCOUNTER so we dont have to keep going back & forth over that.  I was for it in 2000 (go check) and Im for it now.

My point about your example was that you used:

                                  ATTENDEE:...SENT-BY="MAILTO:a@a.com"
                 ;PARTSTAT=accepted:MAILTO:a1@a.com
as motivation.  My response is simply this: you dont use a SENT-BY for yourself since you are not acting on your behalf.  You are you and not someone acting as your proxy (ie: your AA).  As such the example above is not correct (although its legal by just ABNF parsing).

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 00698B6A85256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 14:23:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20706 for ; Tue, 29 Oct 2002 14:23:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TJIOi18530 for ietf-calendar-bks; Tue, 29 Oct 2002 11:18:24 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TJINW18525 for ; Tue, 29 Oct 2002 11:18:23 -0800 (PST) In-Reply-To: <3DBDB8BE.5070008@Royer.com> To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 14:16:05 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/29/2002 02:18:26 PM, Serialize complete at 10/29/2002 02:18:26 PM Content-Type: multipart/alternative; boundary="=_alternative 0069FCA185256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0069FCA185256C61_= Content-Type: text/plain; charset="US-ASCII" Doug also wrote on 10/28/2002 05:22:54 PM: > Maybe I did miss your point > - but you did not answer my question. Is it valid > for the ORGANIZER to keep the SENT-BY values? > > I say yes. I say yes too. The other point I was trying to make before was that its NOT expected that the Organzier would pass the SENT-BY values on in messages to OTHER ATTENDEEs. Its only of real use between the ATTENDEE and the ORGANIZER; not to the rest of the ATTENDEEs at large. Expecting them to be preserved and sent out to other ATTENDEEs is not what was originally envisioned and it only makes the receivers job at interpreting and rendering harder. To be 100% clear: YES the Organizer is anticipated/expected to perserve the SENT-BY info in some form but they are NOT expected to resend it subsequent messages to others. Thats my story and Im sticking to it... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0069FCA185256C61_= Content-Type: text/html; charset="US-ASCII"
Doug also wrote on 10/28/2002 05:22:54 PM:
> Maybe I did miss your point
>   - but you did not answer my question. Is it valid
> for the ORGANIZER to keep the SENT-BY values?
>
> I say yes.
I say yes too.

The other point I was trying to make before was that its NOT expected that the Organzier would pass the SENT-BY values on in messages to OTHER ATTENDEEs.  Its only of real use between the ATTENDEE and the ORGANIZER; not to the rest of the ATTENDEEs at large.  Expecting them to be preserved and sent out to other ATTENDEEs is not what was originally envisioned and it only makes the receivers job at interpreting and rendering harder.

To be 100% clear: YES the Organizer is anticipated/expected to perserve the SENT-BY info in some form but they are NOT expected to resend it subsequent messages to others.  Thats my story and Im sticking to it...

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

--=_alternative 0069FCA185256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 14:29:25 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20910 for ; Tue, 29 Oct 2002 14:29:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TJLxD18638 for ietf-calendar-bks; Tue, 29 Oct 2002 11:21:59 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TJLwW18634 for ; Tue, 29 Oct 2002 11:21:58 -0800 (PST) In-Reply-To: <3DBDBB12.4070609@Royer.com> To: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - No more QUERY-LEVEL? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 14:21:37 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/29/2002 02:22:01 PM, Serialize complete at 10/29/2002 02:22:01 PM Content-Type: multipart/alternative; boundary="=_alternative 006A7E6585256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006A7E6585256C61_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 10/28/2002 05:32:50 PM: > This text *IS* in the latest draft (and all versions that I can find > have at least one of the versions of): > > > QUERY-LEVEL 1 Indicates level of SQL support. The default > is CAL-QL-1 and CAL-QL-NONE can be supplied. > (CAL-QL-NONE is for CS's that allow ITIP > methods only to be deposited and nothing else). > The default value is CAL-QL-1. > Too many copies floating around. In the 09-2 draft it got moved from being next to CAR-LEVEL to being a page further on so it seemed to disappear (compared to the 09-b and 09 drafts I had). Mea culpa in not doing a deeper scan. Sorry. BTW: I think you had a Freudian slip when you say "level of _SQL_ support". You should say "level of _CAP-QL_ support" since we are not strict SQL. Second editorial comment: Why put parenthesis around the 3rd sentence? It does not need them. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006A7E6585256C61_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 10/28/2002 05:32:50 PM:
> This text *IS* in the latest draft (and all versions that I can find
> have at least one of the versions of):
>
>
>     QUERY-LEVEL       1     Indicates level of SQL support. The default
>                             is CAL-QL-1 and CAL-QL-NONE can be supplied.
>                             (CAL-QL-NONE is for CS's that allow ITIP
>                             methods only to be deposited and nothing else).
>                             The default value is CAL-QL-1.
>

Too many copies floating around.  In the 09-2 draft it got moved from being next to CAR-LEVEL to being a page further on so it seemed to disappear (compared to the 09-b and 09 drafts I had).  Mea culpa in not doing a deeper scan.  Sorry.

BTW: I think you had a Freudian slip when you say "level of _SQL_ support".  You should say "level of _CAP-QL_ support" since we are not strict SQL.

Second editorial comment: Why put parenthesis around the 3rd sentence?  It does not need them.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006A7E6585256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 14:49:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21654 for ; Tue, 29 Oct 2002 14:49:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TJiUp19288 for ietf-calendar-bks; Tue, 29 Oct 2002 11:44:30 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TJiTW19284 for ; Tue, 29 Oct 2002 11:44:30 -0800 (PST) MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Draft confusion X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 14:46:46 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/29/2002 02:44:32 PM, Serialize complete at 10/29/2002 02:44:32 PM Content-Type: multipart/alternative; boundary="=_alternative 006C8D2085256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006C8D2085256C61_= Content-Type: text/plain; charset="US-ASCII" Some of the recent flurry has been due to having so many drafts and having them all over the place. I have found notices for drafts at: http://calsch.org/ietf/draft-ietf-calsch-cap-06.txt http://calsch.org/ietf/cap.txt ftp://royer.com/pub/CALSCH/cap.txt http://inet-consulting.com/cap-09-2.txt http://inet-consulting.com/cap-09-b.txt (not -3?? Or is 2 newer????) May I suggest that we have 1 focal point for revs to be posted to AND to have 'old' revs kept for reference?? We were supposed to have this on the Calsch.org web site but its clearly the most out of date. How about we have 1 URL that is "the latest" that always redirects to the 'current' version? In addition, can someone _please_ go and label the older revs w/updated URLs for the next newest rev. You dont have to go all the way back, just make a linked list that I can follow to get to the absolute most current draft (on Dougs desktop ;^) ). That way I can easily tell if my link is stale and update it w/o causing confusion or agrivation. 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 006C8D2085256C61_= Content-Type: text/html; charset="US-ASCII"
Some of the recent flurry has been due to having so many drafts and having them all over the place.  I have found notices for drafts at:

http://calsch.org/ietf/draft-ietf-calsch-cap-06.txt
http://calsch.org/ietf/cap.txt
ftp://royer.com/pub/CALSCH/cap.txt
http://inet-consulting.com/cap-09-2.txt
http://inet-consulting.com/cap-09-b.txt (not -3??  Or is 2 newer????)

May I suggest that we have 1 focal point for revs to be posted to AND to have 'old' revs kept for reference??  We were supposed to have this on the Calsch.org web site but its clearly the most out of date.

How about we have 1 URL that is "the latest" that always redirects to the 'current' version?  

In addition, can someone _please_ go and label the older revs w/updated URLs for the next newest rev.  You dont have to go all the way back, just make a linked list that I can follow to get to the absolute most current draft (on Dougs desktop ;^) ).  That way I can easily tell if my link is stale and update it w/o causing confusion or agrivation.

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 006C8D2085256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 14:54:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21919 for ; Tue, 29 Oct 2002 14:54:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TJlH519442 for ietf-calendar-bks; Tue, 29 Oct 2002 11:47:17 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TJlGW19437 for ; Tue, 29 Oct 2002 11:47:16 -0800 (PST) In-Reply-To: <3DBDBBB1.4080304@Royer.com> To: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - reply MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 14:49:32 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/29/2002 02:47:18 PM, Serialize complete at 10/29/2002 02:47:18 PM Content-Type: multipart/alternative; boundary="=_alternative 006CCDFA85256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CCDFA85256C61_= Content-Type: text/plain; charset="US-ASCII" Doug asked on 10/28/2002 05:35:29 PM: > > Are you reading from? > > http://inet-consulting.com/cap-09-b-2.txt > > The text you provided is not in -b-2. No Im not (I cant keep up w/the changing URLs...) and yes it is. I just went to that URL and I find: CAR-LEVEL 1 Indicates level of CAR support. CAR-NONE, CAR-MIN or CAR-FULL-1. If CAR-FULL-1 is supplied then CAR-MIN MUST BE assumed. CAR = NONE MUST BE used when query-level of NONE is supplied. on the top of page 105. Im not that crazy... 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 006CCDFA85256C61_= Content-Type: text/html; charset="US-ASCII"
Doug asked on 10/28/2002 05:35:29 PM:

>
> Are you reading from?
>
>    http://inet-consulting.com/cap-09-b-2.txt
>
> The text you provided is not in -b-2.
No Im not (I cant keep up w/the changing URLs...) and yes it is.  I just went to that URL and I find:

      CAR-LEVEL         1     Indicates level of CAR support. CAR-NONE,
                             CAR-MIN or CAR-FULL-1. If CAR-FULL-1 is
                             supplied then CAR-MIN MUST BE assumed.
                             CAR = NONE MUST BE used when query-level
                             of NONE is supplied.
on the top of page 105.  Im not that crazy...

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 006CCDFA85256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 15:02:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22235 for ; Tue, 29 Oct 2002 15:02:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TJskw19764 for ietf-calendar-bks; Tue, 29 Oct 2002 11:54:46 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TJsjW19760 for ; Tue, 29 Oct 2002 11:54:45 -0800 (PST) In-Reply-To: <20021029090234.GA34722@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Tue, 29 Oct 2002 14:57:02 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/29/2002 02:54:47 PM, Serialize complete at 10/29/2002 02:54:47 PM Content-Type: multipart/alternative; boundary="=_alternative 006D7DCB85256C61_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006D7DCB85256C61_= Content-Type: text/plain; charset="US-ASCII" Andrea Campi wrote on 10/29/2002 04:02:34 AM: > > I for one think that even if you are a servlet/portlet writer that its > > still useful for the CS to know what your script driven CUA can do. I > > As long as the default is clearly defined, I think the CS knows what the CUA > can do even if the CUA doesn't implement GET-CAPABILITY - it means the CUA has > no problem with the defaults. As long as no new defaults get added (or none change!) then thats true. If for CAP 1.2 or 2.0 we add a new return value then the CS will be at a loss to accurately tell if the non-supportive CUA really supports some defaults or not since it cannot safely guess what version of CAP the CUA scriptlet is using. After all, the CAP-VERSION is part of the GET-CAPABILITY and w/o it the CS has no definitive way to know what version of CAP the CUA speaks if it wont expreslly say so. OR If we for whatever reason change the default CAP-VERSION value to be something different than 1.0 then when your scriplet connects to the newer CS the CS will mistakenly assume the non-responding CUA is, say, 2.0 instead of 1.0 and may make some incorrect decisions. Anyone else w/opinions either way?? 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 006D7DCB85256C61_= Content-Type: text/html; charset="US-ASCII"
Andrea Campi <a.campi@inet.it> wrote on 10/29/2002 04:02:34 AM:
> > I for one think that even if you are a servlet/portlet writer that its
> > still useful for the CS to know what your script driven CUA can do.  I
>
> As long as the default is clearly defined, I think the CS knows what the CUA
> can do even if the CUA doesn't implement GET-CAPABILITY - it means the CUA has
> no problem with the defaults.

As long as no new defaults get added (or none change!) then thats true.  

If for CAP 1.2 or 2.0 we add a new return value then the CS will be at a loss to accurately tell if the non-supportive CUA really supports some defaults or not since it cannot safely guess what version of CAP the CUA scriptlet is using.  After all, the CAP-VERSION is part of the GET-CAPABILITY and w/o it the CS has no definitive way to know what version of CAP the CUA speaks if it wont expreslly say so.

OR

If we for whatever reason change the default CAP-VERSION value to be something different than 1.0 then when your scriplet connects to the newer CS the CS will mistakenly assume the non-responding CUA is, say, 2.0 instead of 1.0 and may make some incorrect decisions.

Anyone else w/opinions either way??

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 006D7DCB85256C61_=-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 15:42:31 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23974 for ; Tue, 29 Oct 2002 15:42:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TKa1S21005 for ietf-calendar-bks; Tue, 29 Oct 2002 12:36:01 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TKa0W20998 for ; Tue, 29 Oct 2002 12:36:00 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TKZxIR027753; Tue, 29 Oct 2002 12:36:00 -0800 Message-ID: <3DBEF12D.9020703@Royer.com> Date: Tue, 29 Oct 2002 13:35:57 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050902040603030402090904" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050902040603030402090904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 10/28/2002 05:38:52 PM: > > No - the ATT-COUNTER property does not take SENT-BY, CN, or the LANG > > parameters. > It needs to. Otherwise my AA cannot counter for me (or you have no way > to tell that my AA did it for me in your UI will you?). The CN and LANG > property parameters are also useful for the same reason they are useful > on the ATTENDEE property. So when an e-mail comes in and the From address set to: "Bruce_Kahn@notesdev.ibm.com" Please explain what I set the CN, SENT-BY and LANG values to in the ATT-COUNTER property to? How would I know that the value of the From: address is or is not an SA? I would set the ATT-COUNTER property value to: mailto:Bruce_Kahn@notesdev.ibm.com The rest eludes me - please enlighten :-) -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms050902040603030402090904 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTIwMzU1N1owIwYJKoZIhvcNAQkEMRYEFAiGhdKb ww0lSEJKCVInC8XSDhH3MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBDuBEJvi+hbWETsf1N guKU24n6aC7Q0AkNL1GlkOxVVF3HTbn9rFdq5rYMilqHiC/LFBP+E+VJBpAQNAjrBkks/qbi D/vo42rIuFEM8ZdHK2XMXJOcBgbIGrntAvl7GMwXksO+mOlbuIfKnK1jsETMxtMYUTDOEtZP 8yCy4vZm8qAM5DByC9HDUSw1CY3H5EhtBnDxOuibknV2uXK82a461Al7KqiuXnNS1TJkNo6F HgbAiWUZsU7hvFtu6eRvHiJ1keoOEgI1HpqNnAYjlFAwxLP1tpwBAgJzkpglPQavNaAILMOw 9/GZU2u7g1QeXx22i7c3oWuwAd9YO+Yoee5aAAAAAAAA --------------ms050902040603030402090904-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 15:45:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24062 for ; Tue, 29 Oct 2002 15:45:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TKdYo21216 for ietf-calendar-bks; Tue, 29 Oct 2002 12:39:34 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TKdWW21212 for ; Tue, 29 Oct 2002 12:39:32 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TKdWIR027772; Tue, 29 Oct 2002 12:39:32 -0800 Message-ID: <3DBEF201.20704@Royer.com> Date: Tue, 29 Oct 2002 13:39:29 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: COMPONENTS [Was Re: GET-CAPABILITY - reply] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030307050109030800020803" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030307050109030800020803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug wrote on 10/28/2002 05:29:22 PM: > > > COMPONENTS 1 A comma separated list of the names of > > > components that are supported. This > > > includes any components inside of > > > other components (VALARM for example). > > > MUST include at least VCALSTORE, VCALENDAR, > > > VREPLY, and VAGENDA and at least one of > VEVENT, > > > VTODO, VTIMEZONE, or VJOURNAL. The defalt > > > is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, > > > VEVENT,VALARM,VTIMEZONE" > > > > > > The last line is not gramatically correct. It should start with > > > something like "This list MUST include..." > > > > No, there is no such MUST. It is correct. > > The default value for COMPONENTS is (as listed...). > > Your sentence is technically accurate. Its not gramatically correct. > You dont start a sentence with "MUST include...", you have no subject. Thank you - I thought you were talking about the LAST sentence. I agree - fixed in my copy with "It MUST...". Fixed several other places also where it started with "MUST". > > > Also, is there any reason why the 'base' components of VTODO and > > > VJOURNAL are not also in the default list? > > > > Nope. > > Are you going to add them then?? I could :-) -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms030307050109030800020803 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTIwMzkyOVowIwYJKoZIhvcNAQkEMRYEFBEHgoTl reYbWruMGyGRPhCBtAokMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQA7rRiaIz9AWqgNXdw8 GP/g8Wz00I26qL1IxiQ1cU0CK3E96McAZI59sXCearanOnnJuJtPrEDnOKy1YfTpont3RLtx zp+FZqiHxSY7DpbESFTRHoJvD8astfxqLBA6KTEFvmEWMtx5LwgFu7n8Zq1TrLxv80qVhBhc 9ZSqCIDgI3DbO435mZjHEcEelMmfjx0W0NkLTcvw7KV1gR4TZqirD/L/ht0cpULnYcn9lREN yt20QI51Xo6zgxaj+8ojuyMUtXOh0jKEaK0bu5qfGGLboy0SbWYVrGQV0SZOKTZUDFMvaXEC dj0t0p35BUcJ9fnKtSUV1pfcAfM4XpX9S6l3AAAAAAAA --------------ms030307050109030800020803-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 15:49:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24347 for ; Tue, 29 Oct 2002 15:49:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TKglx21292 for ietf-calendar-bks; Tue, 29 Oct 2002 12:42:47 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TKgkW21288 for ; Tue, 29 Oct 2002 12:42:46 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TKgiIR027802; Tue, 29 Oct 2002 12:42:46 -0800 Message-ID: <3DBEF2C2.4040209@Royer.com> Date: Tue, 29 Oct 2002 13:42:42 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030600090204050405050800" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030600090204050405050800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug responded on 10/28/2002 05:22:54 PM: > > Maybe I did miss your point > > - but you did not answer my question. Is it valid > > for the ORGANIZER to keep the SENT-BY values? > > > > I say yes. > > Im _FOR_ ATTCOUNTER so we dont have to keep going back & forth over > that. I was for it in 2000 (go check) and Im for it now. Thank you - yes - we agree - now can you answer my question? :-) > My point about your example was that you used: > > ATTENDEE:...SENT-BY="MAILTO:a@a.com" > ;PARTSTAT=accepted:MAILTO:a1@a.com > > as motivation. My response is simply this: you dont use a SENT-BY for > yourself since you are not acting on your behalf. Now I understand your point. Look closer the two email addresses are NOT the same (I did not use SENT-BY for myself). > You are you and not > someone acting as your proxy (ie: your AA). As such the example above > is not correct (although its legal by just ABNF parsing). I agree - that it is not valid. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms030600090204050405050800 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTIwNDI0MlowIwYJKoZIhvcNAQkEMRYEFHuBOnIx SiFFfqyt8BsZZMzLIBGiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBouWoGP02JwEOhcUCd M+fyhMeTUMKkIvygedKhYw2YrUj+S6ytWq445H8IM4MMqaV5FCZ8vpLDuwWutFh2thC/AZqU 1QtOnjDdEVXNvVBmcl0soscvorF9whVFANkpdwCiuHc/NXCWGZ3kEV6JReKQq/mJhU7bi8J1 UGslymEe3ov7rn2uFiAeOY7odomgh5JZiZ6uZyBZLJ0ZUe0sWY8ZSprU8SqY6N3CqtFWq23q rdV2mTFTvql7O8GzuzXKN9p6w312aV+NJIjymhZxwJnT8ZVIw1ADQ1LqtI8c/pYsDZj0dPK9 pTM7yrx+0lVaVtn/9kbRBd0vRRanGoLMJoU0AAAAAAAA --------------ms030600090204050405050800-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 16:00:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24998 for ; Tue, 29 Oct 2002 16:00:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TKo3322084 for ietf-calendar-bks; Tue, 29 Oct 2002 12:50:03 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TKo1W22076 for ; Tue, 29 Oct 2002 12:50:01 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TKo2IR027849 for ; Tue, 29 Oct 2002 12:50:03 -0800 Message-ID: <3DBEF478.304@Royer.com> Date: Tue, 29 Oct 2002 13:50:00 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060005090108090102090703" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060005090108090102090703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug also wrote on 10/28/2002 05:22:54 PM: > > Maybe I did miss your point > > - but you did not answer my question. Is it valid > > for the ORGANIZER to keep the SENT-BY values? > > > > I say yes. > > I say yes too. > > The other point I was trying to make before was that its NOT expected > that the Organzier would pass the SENT-BY values on in messages to OTHER > ATTENDEEs. Debatable - however the only(?) recipient of a COUNTER *IS* the ORGANIZER - which I think MUST keep the SENT-BY values in ALL messages - otherwise the data would be lost. So the only CUA that would get any COUNTER is the ORGANIZER, which MUST keep a copy of who sent them (if stored in UNPROCESED state). Do you agree? At what point would a COUNTER be sent to another ATTENDEE? And even IF a COUNTER was sent to another ATTENDEE, that CS MAY have a SENT-BY's in the entries. > Its only of real use between the ATTENDEE and the ORGANIZER; > not to the rest of the ATTENDEEs at large. Expecting them to be > preserved and sent out to other ATTENDEEs is not what was originally > envisioned and it only makes the receivers job at interpreting and > rendering harder. > > To be 100% clear: YES the Organizer is anticipated/expected to perserve > the SENT-BY info in some form but they are NOT expected to resend it > subsequent messages to others. Thats my story and Im sticking to it... They CAN send the SENT-BY's in updates to any or all ATTENDEEs. There is no such restriction that I can find. However those ATTENDEE's would still not get a COUNTER, so the point is mute? Correct? How would that make things more difficult for non-ORGANIZERs? They would generally ignore the SENT-BY values - if they got them. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms060005090108090102090703 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTIwNTAwMFowIwYJKoZIhvcNAQkEMRYEFCCJFUfY vEZpk30iWkMUNZNZRuJ3MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAeVjVg6vzM5LQlu1Bd l+g3BKIX7aRI5NfBWXV1vui8HfuuJw8RYbuu5iiBIEECEA+8CaZm7H6vEfAV9Q8S4Y2GoSfk ybbU+SchGAg7RusrNFwSscR0OtLC1cxHjOwc4eo3kzjJe1BgDCMc5sVYOg8JCZFErLePBAtF jPXGVaIdgE6qqSBBiNgvpenDbr6I/XrzgvMT2biAvXUO0oC1WStEB2WqG0nG0g5VUmJtzGla lQu3J7boUyXNjTBLNDcaGHDT0dX0MfsNg5pIMxxm1GB4OQWPZzDqZdSZTNdMXA4DEohk1GtN P0EQx9QiQHHNfMAYX6BCB3hrmh0I6R0qPOhkAAAAAAAA --------------ms060005090108090102090703-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 16:04:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25297 for ; Tue, 29 Oct 2002 16:04:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TKpxN22391 for ietf-calendar-bks; Tue, 29 Oct 2002 12:51:59 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TKpwW22384 for ; Tue, 29 Oct 2002 12:51:58 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TKq0IR027862 for ; Tue, 29 Oct 2002 12:52:00 -0800 Message-ID: <3DBEF4ED.6080103@Royer.com> Date: Tue, 29 Oct 2002 13:51:57 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - No more QUERY-LEVEL? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000005040402080007080204" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000005040402080007080204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > BTW: I think you had a Freudian slip when you say "level of _SQL_ > support". You should say "level of _CAP-QL_ support" since we are not > strict SQL. > > Second editorial comment: Why put parenthesis around the 3rd sentence? > It does not need them. Both fixed - thanks! -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms000005040402080007080204 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTIwNTE1N1owIwYJKoZIhvcNAQkEMRYEFD+wIt7S IsQGiY6SgdxS+tRu+Nr7MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQC0iP9tYo42jua1k1Av QpkmmmKiXxqjMiEZbCsssB25yALEYKuTd5R78xOlCB6AMvmU8ZysuErKxF6vTXhIPTa2LgvM pa86fgifZ839DmfWdOwEbbAVfaFNvOsZGDsY6M4/L5dGPVCYycNwRdbT+VRY1bkE3XThARyT fkoLTFwdF/iA5TWmhy01BZrRe5vpdjaEolm6KGl5Au9mPvQzsZXP81hioNvQW2+gcFtI/ZYi aQs/yr0bIn7zdgQitp+ZiRaupjuHa4jRwIiARgWKxiSXll+qBREycTVtpCUAnLmCXySUCyx2 KWAO0MshepFVcph/ZJkNO+6pfFM5hG/8XLBTAAAAAAAA --------------ms000005040402080007080204-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 16:04:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25313 for ; Tue, 29 Oct 2002 16:04:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TKsBW22701 for ietf-calendar-bks; Tue, 29 Oct 2002 12:54:11 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TKsAW22694 for ; Tue, 29 Oct 2002 12:54:10 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TKsBIR027876 for ; Tue, 29 Oct 2002 12:54:12 -0800 Message-ID: <3DBEF571.9040401@Royer.com> Date: Tue, 29 Oct 2002 13:54:09 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Draft confusion References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040900070901090102080405" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040900070901090102080405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > http://inet-consulting.com/cap-09-2.txt <--- NEWEST! > http://inet-consulting.com/cap-09-b.txt (not -3?? Or is 2 newer????) And because of all of the typo's and small changes, I expect a new version this week with the fixes. --------------ms040900070901090102080405 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTIwNTQwOVowIwYJKoZIhvcNAQkEMRYEFAXPvlaZ ki1B4rclbEDwrTLKQHPTMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB19lt1oIF0+a5j0ggi cGPnTtXxhYEVp7zrSN5V1E2MuugrAJ50iGs4EUyh8oC//l/3NFr2ieqB8ntC2r1dd74jT4yF vXKcLYumhgbB3jpVj1oLjchpS3hNZGizgw+6ZJ2tolsD0FNq9pwvY/8WGWDDp1xyPaCGpWad 7bKg4ge1QbNw1xa6mwlnNxZ4jZP1zvC5KItV1dqmrUBPzzrOJMLk88CCLM5xhyKjBLQEnxlI 4V0C8UgmwI4yMCIkKFs+u2Y5vRGyaKbat5X+oAkdRZ+20fgXKay6CCv6Rk+g5lb/dayjkPry I7tUfCp8wz2Uw5bfnQOevLAnwmnEss1A4NDQAAAAAAAA --------------ms040900070901090102080405-- From owner-ietf-calendar@mail.imc.org Tue Oct 29 16:09:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25496 for ; Tue, 29 Oct 2002 16:09:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TKwb723342 for ietf-calendar-bks; Tue, 29 Oct 2002 12:58:37 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TKwZW23330 for ; Tue, 29 Oct 2002 12:58:35 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9TKwaIR027907 for ; Tue, 29 Oct 2002 12:58:37 -0800 Message-ID: <3DBEF67A.1010409@Royer.com> Date: Tue, 29 Oct 2002 13:58:34 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050805010105030006050609" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050805010105030006050609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Andrea Campi wrote on 10/29/2002 04:02:34 AM: > > > I for one think that even if you are a servlet/portlet writer that its > > > still useful for the CS to know what your script driven CUA can do. I > > > > As long as the default is clearly defined, I think the CS knows what > the CUA > > can do even if the CUA doesn't implement GET-CAPABILITY - it means > the CUA has > > no problem with the defaults. > > As long as no new defaults get added (or none change!) then thats true. > > If for CAP 1.2 or 2.0 we add a new return value then the CS will be at a > loss to accurately tell if the non-supportive CUA really supports some > defaults or not since it cannot safely guess what version of CAP the CUA > scriptlet is using. Not true, the default for the capability "CAP-VERSION" is "1.0". If the CUA supports something newer - then it better know how to respont to GET-CAPABILITY else in CAP 1.newer, we would have to invent something like GET-CAPABILITY2 (yuck). > After all, the CAP-VERSION is part of the > GET-CAPABILITY and w/o it the CS has no definitive way to know what > version of CAP the CUA speaks if it wont expreslly say so. We do expreslly say so - if the CUA does not support a GET-CAPABIBILITY reply - the CS assumes the defaults - CAP 1.0. > OR > > If we for whatever reason change the default CAP-VERSION value to be > something different than 1.0 then when your scriplet connects to the > newer CS the CS will mistakenly assume the non-responding CUA is, say, > 2.0 instead of 1.0 and may make some incorrect decisions. How - the default is "1.0" not "whatever", > Anyone else w/opinions either way?? > > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms050805010105030006050609 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyOTIwNTgzNFowIwYJKoZIhvcNAQkEMRYEFB6P8du8 vhrcyQYUGpBw96VhE/fQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB7Vqwr6KXZW6/kQHvG G8B/VbxwuVF5ufy6Y8FLQU75nnXlm6WVBkf71R7l8wIcdDqv7Crf9jZxZi56gdioomh4kElW 6Ccl2X9BXDYzf+OLWLsisYZ6saVa7PaEudXR1zb8/uzAFBFASkaosjKWcRvUxFTlOQL/Gix3 VipeTlPKofJo0tZUn3tCMWbuLMKy5EecpDvGqtOzLYWDUQtgEJ4qaRE3wwNDRI3ptivBw3B8 RMAo2+/Op8lBmFLpgQwMkbfGPghZyalhDVHT1mkc5VupEz5ruPQUrzqiUzHTbYYlHt0QJ7Qf c0rBmQc/ZOQsBH9h/FjxCr0fdJJqJPWXZVoTAAAAAAAA --------------ms050805010105030006050609-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 03:38:12 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05717 for ; Wed, 30 Oct 2002 03:38:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9U8VrI14069 for ietf-calendar-bks; Wed, 30 Oct 2002 00:31:53 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9U8VqW14062 for ; Wed, 30 Oct 2002 00:31:52 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 3A40615567; Wed, 30 Oct 2002 09:31:51 +0100 (CET) Date: Wed, 30 Oct 2002 09:31:51 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt Message-ID: <20021030083151.GA96495@inet.it> References: <20021029090234.GA34722@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Bruce, On Tue, Oct 29, 2002 at 02:57:02PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > scriptlet is using. After all, the CAP-VERSION is part of the > GET-CAPABILITY and w/o it the CS has no definitive way to know what > version of CAP the CUA speaks if it wont expreslly say so. As Doug said, the default would be 1.0 forever, so there would be no ambiguity even with a future CAP revision. That said, I agree with you that, as soon as a new revision is out, a CUA would be stuck with a choice of either staying at CAp-VERSION 1.0, or implementing GET-CAPABILITY. This alone is a reason for me to retire my idea, and thanks for making me see the light ;-) Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Oct 30 03:40:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05765 for ; Wed, 30 Oct 2002 03:40:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9U8Z2X14433 for ietf-calendar-bks; Wed, 30 Oct 2002 00:35:02 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9U8Z1W14426 for ; Wed, 30 Oct 2002 00:35:01 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id CAB3E15567; Wed, 30 Oct 2002 09:35:00 +0100 (CET) Date: Wed, 30 Oct 2002 09:35:00 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: 6.1.1 CAL-QUERY Value Type Message-ID: <20021030083500.GB96495@inet.it> References: <43D0E73C-E6BE-11D6-B6A3-003065A8EEFC@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Oct 29, 2002 at 11:09:59AM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > Andrea wrote on 10/23/2002 03:33:10 PM: > > My ABNF crafting on the fly is not so great but I think the intent is at > least clear enough. We can get a ANBF guru to tune it as appropriate if > we decide to make it work right. I agree with your proposal. My ABNF skills are not good at all, but I agree we should fix it somehow right now and finetune it later on. > > However, AFAIK we never discussed this before, so we might want to fix > > this it later on. > Actually I raised this at the IETF in February/March in hallway talks > w/Steve & the Steltor contingant. Guess it didnt get reflected in any Yes, that's why I said As Far As I Know - I wasn't around yet. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Wed Oct 30 10:24:55 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19178 for ; Wed, 30 Oct 2002 10:24:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UFC1i21793 for ietf-calendar-bks; Wed, 30 Oct 2002 07:12:01 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UFC0W21789 for ; Wed, 30 Oct 2002 07:12:01 -0800 (PST) In-Reply-To: <3DBEF12D.9020703@Royer.com> To: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 10:11:47 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 10:12:03 AM, Serialize complete at 10/30/2002 10:12:03 AM Content-Type: multipart/alternative; boundary="=_alternative 0053935285256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0053935285256C62_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/29/2002 03:35:57 PM: > > It needs to. Otherwise my AA cannot counter for me (or you have no way > > to tell that my AA did it for me in your UI will you?). The CN and LANG > > property parameters are also useful for the same reason they are useful > > on the ATTENDEE property. > > So when an e-mail comes in and the From address set to: > > "Bruce_Kahn@notesdev.ibm.com" > > Please explain what I set the CN, SENT-BY and LANG values to > in the ATT-COUNTER property to? How would I know that the value > of the From: address is or is not an SA? I assume your 'e-mail' is an iTIP message. However thats outside the discussion bounds since the real focus is on the properties in the iCalendar stream, not on the wrapper/meta info outside the stream. The email bit is superfluous but Ill include it since you asked. You can strip it off for pure CAP transport if you prefer. This is how an iTIP COUNTER would be (partly) constructed from me to you: From: Bruce_Kahn@notesdev.ibm.com To: Doug@Royer.com Subject: Counter proposal for that conf. call Content-Type: text/calendar; method=counter ... ORGANIZER:mailto:Doug@Royer.com ATTENDEE;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com ATTCOUNTER;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com ... This is how an iTIP COUNTER would be (partly) constucted from my AA to you on my behalf: From: Jane_Doe@lotus.com To: Doug@Royer.com Subject: Counter proposal for that conf. call Content-Type: text/calendar; method=counter ... ORGANIZER:mailto:Doug@Royer.com ATTENDEE;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com ATTCOUNTER;SENT-BY=mailto:Jane_Doe@lotus.com;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com ... The CN (and also the related LANG) property are used just as they are in ANY other iTIP message. Their usage han not changed and they are equally useful on the COUNTER for the same reason they are useful on the other methods! The SENT-BY property parameter is used just as in iTIP when an AA "accepts" for me. Only this time they are COUNTERing for me. Since I/she could be COUNTERing to remove me as an ATTENDEE (and put someone in my place?) you need to have the SENT-BY info on the ATTCOUNTER and NOT on my ATTENDEE property which may not be there on _my_ COUNTER to _your_ event. > The rest eludes me - please enlighten :-) Better? 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 0053935285256C62_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/29/2002 03:35:57 PM:
> > It needs to.  Otherwise my AA cannot counter for me (or you have no way
> > to tell that my AA did it for me in your UI will you?).  The CN and LANG
> > property parameters are also useful for the same reason they are useful
> > on the ATTENDEE property.
>
> So when an e-mail comes in and the From address set to:
>
>     "Bruce_Kahn@notesdev.ibm.com"
>
> Please explain what I set the CN, SENT-BY and LANG values to
> in the ATT-COUNTER property to? How would I know that the value
> of the From: address is or is not an SA?
I assume your 'e-mail' is an iTIP message.  However thats outside the discussion bounds since the real focus is on the properties in the iCalendar stream, not on the wrapper/meta info outside the stream.  The email bit is superfluous but Ill include it since you asked.  You can strip it off for pure CAP transport if you prefer.

This is how an iTIP COUNTER would be (partly) constructed from me to you:

    From: Bruce_Kahn@notesdev.ibm.com
    To: Doug@Royer.com
    Subject: Counter proposal for that conf. call
    Content-Type: text/calendar; method=counter

    ...
    ORGANIZER:mailto:Doug@Royer.com
    ATTENDEE;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com
    ATTCOUNTER;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com
    ...

This is how an iTIP COUNTER would be (partly) constucted from my AA to you on my behalf:

    From: Jane_Doe@lotus.com
    To: Doug@Royer.com
    Subject: Counter proposal for that conf. call
    Content-Type: text/calendar; method=counter

    ...
    ORGANIZER:mailto:Doug@Royer.com
    ATTENDEE;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com
    ATTCOUNTER;SENT-BY=mailto:Jane_Doe@lotus.com;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com
    ...

The CN (and also the related LANG) property are used just as they are in ANY other iTIP message.  Their usage han not changed and they are equally useful on the COUNTER for the same reason they are useful on the other methods!

The SENT-BY property parameter is used just as in iTIP when an AA "accepts" for me.  Only this time they are COUNTERing for me.  Since I/she could be COUNTERing to remove me as an ATTENDEE (and put someone in my place?) you need to have the SENT-BY info on the ATTCOUNTER and NOT on my ATTENDEE property which may not be there on _my_ COUNTER to _your_ event.

> The rest eludes me - please enlighten :-)
Better?

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 0053935285256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 10:29:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19649 for ; Wed, 30 Oct 2002 10:29:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UFLSj22047 for ietf-calendar-bks; Wed, 30 Oct 2002 07:21:28 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UFLRW22042 for ; Wed, 30 Oct 2002 07:21:27 -0800 (PST) In-Reply-To: <3DBED16B.8000908@Royer.com> MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 3.2 Calendar Store Object Model X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 10:21:23 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 10:21:29 AM, Serialize complete at 10/30/2002 10:21:29 AM Content-Type: multipart/alternative; boundary="=_alternative 005473D285256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005473D285256C62_= Content-Type: text/plain; charset="US-ASCII" Doug asked wrote on 10/29/2002 01:20:27 PM: > > The 2nd VAGENDAs is superfluous and should be removed. > > Why? It looks to me if it is saying there can be more than one. 2 reasons: 1) You already have an 's' at the end making the 1st one plural and 2) The rest of the list shows plural components/containers too with just 1 entry: | +--properties | +--VEVENTs | | | | | +--VALARMs | +--VTODOs | | | | | +--VALARMs | +--VJOURNALs | +--VCARs | +--VTIMEZONEs | +--VQUERYs | +--VFREEBUSY but no multiple VEVENTs, VTODOs, etc. Oh yea, you need to put an 's' on that VFREEBUSY (or are you only allowing 1 VFREEBUSY per VAGENDA??? :^) ) 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 005473D285256C62_= Content-Type: text/html; charset="US-ASCII"
Doug asked wrote on 10/29/2002 01:20:27 PM:
> > The 2nd VAGENDAs is superfluous and should be removed.
>
> Why? It looks to me if it is saying there can be more than one.
2 reasons:

1) You already have an 's' at the end making the 1st one plural and
2) The rest of the list shows plural components/containers too with just 1 entry:
       |     +--properties
      |     +--VEVENTs
      |     |    |
      |     |    +--VALARMs
      |     +--VTODOs
      |     |    |
      |     |    +--VALARMs
      |     +--VJOURNALs
      |     +--VCARs
      |     +--VTIMEZONEs
      |     +--VQUERYs
      |     +--VFREEBUSY
but no multiple VEVENTs, VTODOs, etc.

Oh yea, you need to put an 's' on that VFREEBUSY (or are you only allowing 1 VFREEBUSY per VAGENDA??? :^) )

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 005473D285256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 10:30:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19721 for ; Wed, 30 Oct 2002 10:30:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UFNJ522136 for ietf-calendar-bks; Wed, 30 Oct 2002 07:23:19 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UFNJW22132 for ; Wed, 30 Oct 2002 07:23:19 -0800 (PST) In-Reply-To: <3DBED076.9040201@Royer.com> To: ietf-calendar@imc.org Subject: Re: 9.3 GET-CAPABILITY Command MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 10:23:17 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 10:23:21 AM, Serialize complete at 10/30/2002 10:23:21 AM Content-Type: multipart/alternative; boundary="=_alternative 0054A09685256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0054A09685256C62_= Content-Type: text/plain; charset="US-ASCII" Doug quickly responded on 10/29/2002 01:16:22 PM: > It's not, that's the point of this list :-) Great! Now I have a valid excuse to go web surfiing @ work. What a perk. Thanks! Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0054A09685256C62_= Content-Type: text/html; charset="US-ASCII"
Doug quickly responded on 10/29/2002 01:16:22 PM:
> It's not, that's the point of this list :-)
Great!  Now I have a valid excuse to go web surfiing @ work.  What a perk.  Thanks!  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0054A09685256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 10:34:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20205 for ; Wed, 30 Oct 2002 10:34:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UFSif22263 for ietf-calendar-bks; Wed, 30 Oct 2002 07:28:44 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UFShW22259 for ; Wed, 30 Oct 2002 07:28:44 -0800 (PST) In-Reply-To: <20021030083151.GA96495@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 10:28:41 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 10:28:46 AM, Serialize complete at 10/30/2002 10:28:46 AM Content-Type: multipart/alternative; boundary="=_alternative 00551F0685256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00551F0685256C62_= Content-Type: text/plain; charset="US-ASCII" Andrea Campi wrote on 10/30/2002 03:31:51 AM: > As Doug said, the default would be 1.0 forever, so there would be > no ambiguity even with a future CAP revision. Wow! A key decision making value that NEVER changes in any version of the protocol. That sounds very useful... > That said, I agree with you that, as soon as a new revision is out, > a CUA would be stuck with a choice of either staying at CAp-VERSION > 1.0, or implementing GET-CAPABILITY. > This alone is a reason for me to retire my idea, and thanks for making > me see the light ;-) Oh, were it so easy to make others see the light... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com For those who are humor-challenged, my responses above were (and still are) sarcasm and tongue-in-cheek respectively --=_alternative 00551F0685256C62_= Content-Type: text/html; charset="US-ASCII"
Andrea Campi <a.campi@inet.it> wrote on 10/30/2002 03:31:51 AM:
> As Doug said, the default would be 1.0 forever, so there would be
> no ambiguity even with a future CAP revision.
Wow!  A key decision making value that NEVER changes in any version of the protocol.  That sounds very useful...

> That said, I agree with you that, as soon as a new revision is out,
> a CUA would be stuck with a choice of either staying at CAp-VERSION
> 1.0, or implementing GET-CAPABILITY.
> This alone is a reason for me to retire my idea, and thanks for making
> me see the light ;-)

Oh, were it so easy to make others see the light...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
For those who are humor-challenged, my responses above were (and still are) sarcasm and tongue-in-cheek respectively
--=_alternative 00551F0685256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 11:10:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22274 for ; Wed, 30 Oct 2002 11:10:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UFsY823283 for ietf-calendar-bks; Wed, 30 Oct 2002 07:54:34 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UFsXW23279 for ; Wed, 30 Oct 2002 07:54:33 -0800 (PST) In-Reply-To: <3DBEF67A.1010409@Royer.com> To: ietf-calendar@imc.org Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 10:52:23 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 10:54:35 AM, Serialize complete at 10/30/2002 10:54:35 AM Content-Type: multipart/alternative; boundary="=_alternative 00577CF985256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00577CF985256C62_= Content-Type: text/plain; charset="US-ASCII" Doug suggested on 10/29/2002 03:58:34 PM: > > If for CAP 1.2 or 2.0 we add a new return value then the CS will be at a > > loss to accurately tell if the non-supportive CUA really supports some > > defaults or not since it cannot safely guess what version of CAP the CUA > > scriptlet is using. > > Not true, the default for the capability "CAP-VERSION" is "1.0". > If the CUA supports something newer - then it better know how > to respont to GET-CAPABILITY else in CAP 1.newer, we would have > to invent something like GET-CAPABILITY2 (yuck). The default for _this_release_ of CAP is "1.0" but it may change for some unforseen reason in the future when a new version of CAP is released. Its not a change in the CUA that Im worried about; its a change in the CS instead. If we rev CAP to a newer CAP-VERSION and some vendor actually implemented it then the CUA could detect this by the CAP-VERSION:2.0 value that it gets back (because all CS's MUST support GET-CAPABILITY). However the newer, spiffier CS has NO way to properly detect what CAP version the CUA is running since the CUA wont say. The current spec is that the CS "MUST assume the CUA supports the default values" in CAP-VERSION:1.0 and that ALL 1.0 defaults apply to the CUA when taking any actions later on. This is great if both sides are both 1.0, not so great if they are not. It is not possible/safe to make assumptions about defaults when there is the potential that the defaults may be different, say between "1.0" and "2.0". We are not omniscient (at least Im not, just ask my wife) so there is the potential that we may change them for some very valid reasons in the future. This could lead to inteorp failure and a very nasty headache for CAP 2.0 designers. One possiblity is that we just 'fix' CAP-VERSION at "1.0" forever (ala MIME-Version). Nice concept if you have an extensible framework to build on but we do not. Also, in MIME there is no assumption about default values for any header or types, etc. We have defaulting of values in CAP. That is another reason why we cannot just fix CAP-VERSION; if we did then what purpose does CAP-VERSION really serve? The only way to solve this issue is to make the CUAs ALWAYS respond to GET-CAPABILITY. Otherwise the CA must _always_ assume CAP-VERSION 1.0 in all future instances of the protocol and any newer CUAs MUST expressly send back a CAP-VERSION:2.0. This negates the original intent to make it 'faster' by not having to code a GET-CAPABILITY handler originally. > We do expreslly say so - if the CUA does not support a GET-CAPABIBILITY > reply - the CS assumes the defaults - CAP 1.0. So for any future version of CAP this will always hold true? If thats the case then any 2.0 CUA MUST support GET-CAPABILITY or be treated by the CS as a 1.0 CUA instead of a newer 2.0 CUA. This is the negation of the original desire to make the CUA faster by not coding a GET-CAPABILITY handler up. Wouln't it just be simpler to say that a CUA MUST respond to the GET-CAPABILITY command and have NO defaulting and mistaken assumptions made? > > If we for whatever reason change the default CAP-VERSION value to be > > something different than 1.0 then when your scriplet connects to the > > newer CS the CS will mistakenly assume the non-responding CUA is, say, > > 2.0 instead of 1.0 and may make some incorrect decisions. > > How - the default is "1.0" not "whatever", So you're saying that for this and all future versions of CAP the default will (MUST) always be "Assume 1.0 if the CUA does not respond to GET-CAPAIBLITY." Correct? 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 00577CF985256C62_= Content-Type: text/html; charset="US-ASCII"
Doug suggested on 10/29/2002 03:58:34 PM:
> > If for CAP 1.2 or 2.0 we add a new return value then the CS will be at a
> > loss to accurately tell if the non-supportive CUA really supports some
> > defaults or not since it cannot safely guess what version of CAP the CUA
> > scriptlet is using.
>
> Not true, the default for the capability "CAP-VERSION" is "1.0".
> If the CUA supports something newer - then it better know how
> to respont to GET-CAPABILITY else in CAP 1.newer, we would have
> to invent something like GET-CAPABILITY2 (yuck).
The default for _this_release_ of CAP is "1.0" but it may change for some unforseen reason in the future when a new version of CAP is released.

Its not a change in the CUA that Im worried about; its a change in the CS instead.  If we rev CAP to a newer CAP-VERSION and some vendor actually implemented it then the CUA could detect this by the CAP-VERSION:2.0 value that it gets back (because all CS's MUST support GET-CAPABILITY).  However the newer, spiffier CS has NO way to properly detect what CAP version the CUA is running since the CUA wont say.  The current spec is that the CS "MUST assume the CUA supports the default values" in CAP-VERSION:1.0 and that ALL 1.0 defaults apply to the CUA when taking any actions later on.  This is great if both sides are both 1.0, not so great if they are not.  

It is not possible/safe to make assumptions about defaults when there is the potential that the defaults may be different, say between "1.0" and "2.0".  We are not omniscient (at least Im not, just ask my wife) so there is the potential that we may change them for some very valid reasons in the future.  This could lead to inteorp failure and a very nasty headache for CAP 2.0 designers.

One possiblity is that we just 'fix' CAP-VERSION at "1.0" forever (ala MIME-Version).  Nice concept if you have an extensible framework to build on but we do not.  Also, in MIME there is no assumption about default values for any header or types, etc.  We have defaulting of values in CAP.  That is another reason why we cannot just fix CAP-VERSION; if we did then what purpose does CAP-VERSION really serve?

The only way to solve this issue is to make the CUAs ALWAYS respond to GET-CAPABILITY.  Otherwise the CA must _always_ assume CAP-VERSION 1.0 in all future instances of the protocol and any newer CUAs MUST expressly send back a CAP-VERSION:2.0.  This negates the original intent to make it 'faster' by not having to code a GET-CAPABILITY handler originally.

> We do expreslly say so - if the CUA does not support a GET-CAPABIBILITY
> reply - the CS assumes the defaults - CAP 1.0.
So for any future version of CAP this will always hold true?  If thats the case then any 2.0 CUA MUST support GET-CAPABILITY or be treated by the CS as a 1.0 CUA instead of a newer 2.0 CUA.  This is the negation of the original desire to make the CUA faster by not coding a GET-CAPABILITY handler up.

Wouln't it just be simpler to say that a CUA MUST respond to the GET-CAPABILITY command and have NO defaulting and mistaken assumptions made?

> > If we for whatever reason change the default CAP-VERSION value to be
> > something different than 1.0 then when your scriplet connects to the
> > newer CS the CS will mistakenly assume the non-responding CUA is, say,
> > 2.0 instead of 1.0 and may make some incorrect decisions.
>
> How - the default is "1.0" not "whatever",
So you're saying that for this and all future versions of CAP the default will (MUST) always be "Assume 1.0 if the CUA does not respond to GET-CAPAIBLITY."  Correct?

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 00577CF985256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 11:12:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22400 for ; Wed, 30 Oct 2002 11:12:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UFttb23335 for ietf-calendar-bks; Wed, 30 Oct 2002 07:55:55 -0800 (PST) Received: from maya.ngi.it (maya.ngi.it [194.177.103.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UFtsW23329 for ; Wed, 30 Oct 2002 07:55:54 -0800 (PST) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by maya.ngi.it (8.12.1/8.12.1) with ESMTP id g9UFtoj7004660 for ; Wed, 30 Oct 2002 16:55:53 +0100 Date: Wed, 30 Oct 2002 16:55:41 +0100 Subject: Re: Diffs - ftp://royer.com/pub/CALSCH/cap.txt Content-Type: multipart/alternative; boundary=Apple-Mail-2--295916473 Mime-Version: 1.0 (Apple Message framework v546) From: Andrea Campi To: ietf-calendar@imc.org In-Reply-To: Message-Id: <0AE5DEE0-EC20-11D6-A80F-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-2--295916473 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Wednesday, October 30, 2002, at 04:28 PM,=20 Bruce_Kahn@notesdev.ibm.com wrote: > > Andrea Campi wrote on 10/30/2002 03:31:51 AM: > > As Doug said, the default would be 1.0 forever, so there would be > > no ambiguity even with a future CAP revision. > > Wow! =A0A key decision making value that NEVER changes in any version = of=20 > the protocol. =A0That sounds very useful... Uhm... now I'm curious... How exactly do you design forward=20 compatibility in a protocol if you don't assume that "if a party=20 doesn't specify a later revision, we must assume it only supports an=20 earlier, known revision"? Note that I said _the default_. Coincidentally, that's how HTTP works - if a client doesn't specify an=20= HTTP version, the server assumes it can only do 1.0 (well, apart from=20 kludges). Bye, Andrea= --Apple-Mail-2--295916473 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, October 30, 2002, at 04:28 PM, Bruce_Kahn@notesdev.ibm.com wrote: Andrea Campi < wrote on 10/30/2002 03:31:51 AM: > As Doug said, the default would be 1.0 forever, so there would be > no ambiguity even with a future CAP revision. Wow! =A0A key decision making value that NEVER changes in any version of the protocol. =A0That sounds very useful... Uhm... now I'm curious... How exactly do you design forward compatibility in a protocol if you don't assume that "if a party doesn't specify a later revision, we must assume it only supports an earlier, known revision"? Note that I said _the default_. Coincidentally, that's how HTTP works - if a client doesn't specify an HTTP version, the server assumes it can only do 1.0 (well, apart from kludges). Bye, Andrea= --Apple-Mail-2--295916473-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 11:18:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22807 for ; Wed, 30 Oct 2002 11:18:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UGA5825472 for ietf-calendar-bks; Wed, 30 Oct 2002 08:10:05 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UGA4W25467 for ; Wed, 30 Oct 2002 08:10:04 -0800 (PST) To: ietf-calendar@imc.org Subject: 9.3 GET-CAPABILITY - CAP-VERSION MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 11:07:56 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 11:10:06 AM, Serialize complete at 10/30/2002 11:10:06 AM Content-Type: multipart/alternative; boundary="=_alternative 0058E93B85256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0058E93B85256C62_= Content-Type: text/plain; charset="US-ASCII" In trying to get a better handle on the GET-CAPABILITY command and defaulting, etc. I suddenly had a couple questions that I cannot find answers to in the 09-b-2 draft (I bet Doug already addressed it in the 09-c or 09-b-3a version though...). The current description of CAP-VERSION is: CAP-VERSION 1 Version of CAP. MUST include at least "1.0" for this version of CAP. Like the "VERSION" property, it may have a range. Uses the exact same syntax as the "VERSION" property value. The default is "1.0". Question 1: If CAP-VERSION can have a range (ie: CAP-VERSION:1.0;2.0) then what are the default values to be used by the CS when it supports multiple versions of CAP? The 1.0? 2.0? Some mix (assuming they are not mutually exclusive)? Question 2: Just what should a CUA or CS do when they detect a CAP-VERSION value that is above/below what they can deal with? For example, my CUA is CAP-VERSION:1.0 and my CS is CAP-VERSION:2.0;2.0 then what should happen when they try to work together? We never expressly codify what should happen in this case. Question 3: (Assumption: We finally realize that blind assumption about default values for unknown clients is bad and correct this in the draft so that both sides MUST support GET-CAPABILITY) What good are defaults if both sides are mandated to send back a response to GET-CAPABLITY? 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 0058E93B85256C62_= Content-Type: text/html; charset="US-ASCII"
In trying to get a better handle on the GET-CAPABILITY command and defaulting, etc. I suddenly had a couple questions that I cannot find answers to in the 09-b-2 draft (I bet Doug already addressed it in the 09-c or 09-b-3a version though...).  

The current description of CAP-VERSION is:

      CAP-VERSION       1     Version of CAP. MUST include at least "1.0" for
                             this version of CAP. Like the "VERSION" property,
                             it may have a range. Uses the exact same
                             syntax as the "VERSION" property value. The
                             default is "1.0".

Question 1:
If CAP-VERSION can have a range (ie: CAP-VERSION:1.0;2.0) then what are the default values to be used by the CS when it supports multiple versions of CAP?  The 1.0?  2.0?  Some mix (assuming they are not mutually exclusive)?

Question 2:
Just what should a CUA or CS do when they detect a CAP-VERSION value that is above/below what they can deal with?  For example, my CUA is CAP-VERSION:1.0 and my CS is CAP-VERSION:2.0;2.0 then what should happen when they try to work together?  We never expressly codify what should happen in this case.

Question 3:
(Assumption: We finally realize that blind assumption about default values for unknown clients is bad and correct this in the draft so that both sides MUST support GET-CAPABILITY)
What good are defaults if both sides are mandated to send back a response to GET-CAPABLITY?

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 0058E93B85256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 11:52:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24911 for ; Wed, 30 Oct 2002 11:52:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UGhGf26775 for ietf-calendar-bks; Wed, 30 Oct 2002 08:43:16 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UGhFW26770 for ; Wed, 30 Oct 2002 08:43:15 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9UGhFIR004159 for ; Wed, 30 Oct 2002 08:43:16 -0800 Message-ID: <3DC00C26.7080606@Royer.com> Date: Wed, 30 Oct 2002 09:43:18 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: ATT-COUNTER added to CAP References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030609010506040901040904" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030609010506040901040904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > This is how an iTIP COUNTER would be (partly) constructed from me to you: > > This is how an iTIP COUNTER would be (partly) constucted from my AA to > you on my behalf: (1) ATT-COUNT does not exist in iMIP, so you iTIP client would have never added it. So given what ALL current iMIP implementaions would send something like: From: SomeAA@notesdev.ibm.com To: Doug@Royer.com Subject: Counter proposal for that conf. call Content-Type: text/calendar; method=counter ... METHOD:COUNTER ... ORGANIZER:mailto:Doug@Royer.com ATTENDEE;SENT-BY="SomeAA@ibm.com" ;CN="Bruce Kahn/NotesDev/IBM":mailto:Bruce_Kahn@notesdev.ibm.com ATTENDEE;SENT-BY="SomeAA@ibm.com" ;CN="Other Guy/NotesDev/IBM":mailto:Other_Guy@notesdev.ibm.com ATTENDEE:mailto:SomeAA@notesdev.ibm.com The CUA would add the ATT-COUNTER property to the object by using the 'e-mail From address' and set it to: ATT-COUNTER:SomeAA@ibm.ocm What would the LANG, CN, and SENT-BY be set to in the ATT-COUNTER property? > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms030609010506040901040904 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDE2NDMxOFowIwYJKoZIhvcNAQkEMRYEFD20VulL g7pv7y/qVz3TZupg3lbNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAX4V/ivOS6+kUMODHR m+ZVqbzZ7bk9NVUZWjQHRM9HWl4Mo5YhsaxMELQDlxS0A8sy85J6d4lLuqnQt+NBCYd/pLrN amIW+n6PmJZE51gnyjwqbnrccQCJnpVZP+I5gg3AGF61XDmSqd2uAXyN9uMINfe+El4VWnAw nEZi4pHA2ESUtXWxD9LhK9TnHBdU/m8ChfiuYopFKWHVdNTRWoWyUW9Dyz+zPKbtQDKadtTR L/iU/73PROGyp+fovYdTsLOfIKUd+tf1He5+PZYWCTgEr2nnFr+iMD427l1Q7YjFDEKX6w4Q FAWuwhjAxD2M1IOC1q5FvAN2ApRquRCdhOrTAAAAAAAA --------------ms030609010506040901040904-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 11:53:59 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24958 for ; Wed, 30 Oct 2002 11:53:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UGdCn26428 for ietf-calendar-bks; Wed, 30 Oct 2002 08:39:12 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UGdBW26423 for ; Wed, 30 Oct 2002 08:39:11 -0800 (PST) To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 11:39:08 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 11:39:14 AM, Serialize complete at 10/30/2002 11:39:14 AM Content-Type: multipart/alternative; boundary="=_alternative 005B92C585256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B92C585256C62_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 23-Oct-2002 with: > > Also, I assume that we are allowing a SENT-BY property parameter to be > > on ATT-COUTNER since its possible my AA is doing the COUNTERing. Do you > > agree? > > Yes. In looking @ this in the 09-b-2 draft I do not see it in there. In Section 7.2 ATT-COUNTER Property see: Formal Definition: The property is defined by the following notation: attcounter = "ATT-COUNTER" *(";" xparam) ":" cal-address CRLF There is mention of the SENT-BY property parameter. Perhaps in 09-b-3 or 09-c...?? 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 005B92C585256C62_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 23-Oct-2002 with:
> > Also, I assume that we are allowing a SENT-BY property parameter to be
> > on ATT-COUTNER since its possible my AA is doing the COUNTERing.  Do you
> > agree?
>
> Yes.
In looking @ this in the 09-b-2 draft I do not see it in there.  In Section 7.2 ATT-COUNTER Property see:

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


        attcounter   = "ATT-COUNTER" *(";" xparam) ":" cal-address CRLF
There is mention of the SENT-BY property parameter.  Perhaps in 09-b-3 or 09-c...??

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 005B92C585256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 11:57:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25172 for ; Wed, 30 Oct 2002 11:57:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UGn8J27128 for ietf-calendar-bks; Wed, 30 Oct 2002 08:49:08 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UGn7W27119 for ; Wed, 30 Oct 2002 08:49:07 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9UGn7IR004190 for ; Wed, 30 Oct 2002 08:49:08 -0800 Message-ID: <3DC00D86.8000000@Royer.com> Date: Wed, 30 Oct 2002 09:49:10 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040003060503040006040302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040003060503040006040302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In trying to get a better handle on the GET-CAPABILITY command and > defaulting, etc. I suddenly had a couple questions that I cannot find > answers to in the 09-b-2 draft (I bet Doug already addressed it in the > 09-c or 09-b-3a version though...). > > The current description of CAP-VERSION is: > > CAP-VERSION 1 Version of CAP. MUST include at least > "1.0" for > this version of CAP. Like the "VERSION" > property, > it may have a range. Uses the exact same > syntax as the "VERSION" property value. The > default is "1.0". > > Question 1: > If CAP-VERSION can have a range (ie: CAP-VERSION:1.0;2.0) then what are > the default values to be used by the CS when it supports multiple > versions of CAP? The 1.0? 2.0? Some mix (assuming they are not > mutually exclusive)? The default value as specified in the draft is "1.0". If an implementation supported several version, then it would not be the default, it would be 1.0;2.0 > Question 2: > Just what should a CUA or CS do when they detect a CAP-VERSION value > that is above/below what they can deal with? For example, my CUA is > CAP-VERSION:1.0 and my CS is CAP-VERSION:2.0;2.0 then what should happen > when they try to work together? We never expressly codify what should > happen in this case. It says '[It] must include at lest "1.0"..." So do you think it is valid to send only "2.0;2.0"? > Question 3: > (Assumption: We finally realize that blind assumption about default > values for unknown clients is bad and correct this in the draft so that > both sides MUST support GET-CAPABILITY) > What good are defaults if both sides are mandated to send back a > response to GET-CAPABLITY? Your logic is failing :-) There has been no such agreement. > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms040003060503040006040302 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDE2NDkxMFowIwYJKoZIhvcNAQkEMRYEFC9Kouig E0/jlbZA1fBzx6qdvAm4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCDBa1tmr41w+yLdl3P vkyrPWAxzAPfgURHpN0me52BpaRBf8mBEEY4J/t1ajpt6fjjjsXVvxpfNhOHbaUTIAm6u95F 90W1rAWN8bnrniNfaf7G0/oLd40TMoIkdKYH/+Q3ruujEaGS4uuTqTqY38jrQ6LZiO+dYZVf Oy0yjAJazViSZFWfCTvX3/JVYaHK3ZB0RyF+uZHYMRvyeGwboby+ylTaR7CF1gcUYgLkwQhe WQgnsNgUtsnecl+75DPs1MbjrIPleWrjrTKX1kOKGg6p1GS6BZXazDNP7kjvd1uPCwK4kkI4 UwIuXcS6hQmdK5DDut6LsVqSUd/xWkdrwFiLAAAAAAAA --------------ms040003060503040006040302-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 12:21:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26931 for ; Wed, 30 Oct 2002 12:21:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UHAow00527 for ietf-calendar-bks; Wed, 30 Oct 2002 09:10:50 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UHAnW00518 for ; Wed, 30 Oct 2002 09:10:49 -0800 (PST) In-Reply-To: <3DBEF478.304@Royer.com> To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 12:08:39 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 12:10:52 PM, Serialize complete at 10/30/2002 12:10:52 PM Content-Type: multipart/alternative; boundary="=_alternative 005E788985256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005E788985256C62_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 10/29/2002 03:50:00 PM: > Debatable - however the only(?) recipient of a COUNTER *IS* > the ORGANIZER - From 2446: 3.2.7 COUNTER The "COUNTER" method for a "VEVENT" calendar component is used by an "Attendee" of an existing event to submit to the "Organizer" a counter proposal to the event description. The "Attendee" sends this message to the "Organizer" of the event. so the answer is that COUNTER is only between an Attendee and the Organizer. No other parties are involved (except maybe an AA or two). > which I think MUST keep the SENT-BY values > in ALL messages - otherwise the data would be lost. The SENT-BY information is ONLY of any real use in the context of the message it is associated with. In all other cases its misleading or confusing or even inappropriate and inaccurate. > So > the only CUA that would get any COUNTER is the ORGANIZER, which > MUST keep a copy of who sent them (if stored in UNPROCESED > state). Do you agree? The SENT-BY is only valid/useful in the context of the message it was on. It was never intended to be preserved and passed on as a kind of hearsay ("Bruces AA says that he is delegating the meeting to Tom Ransdell"). In this conext I agree that SENT-BY is preserved (along w/all other supported properties and property parameters) on that particular message. I do NOT agree that if you accept my COUNTER and send out a REQUEST to the other Attendees that my AAs SENT-BY value should be put on your new REQUEST. Do you?? (It was implied in your "If it is valid to keep them (and I think it is)" > At what point would a COUNTER be sent to another ATTENDEE? From 2446: The "Organizer" rejects the counter proposal by sending the "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts the counter proposal by rescheduling the event as described in section 3.2.2.1 Rescheduling an Event. so if you accept my (or my AAs) COUNTER to your REQUEST you send out a new REQUEST to those involved. Copying over any SENT-BY property parameter is not that useful in the workflow process really. There is only a minor distinction between "Bruce has ACCEPTED Dougs invitation" and "Bruces AA has ACCEPTED Dougs invitation on Bruces behalf" (or COUNTERed or...). ATTENDEEs do not send COUNTERs to one another. The Organzier is the controller of the workflow process, NOT the separate Attendees. > They CAN send the SENT-BY's in updates to any or all ATTENDEEs. There > is no such restriction that I can find. However those ATTENDEE's would > still not get a COUNTER, so the point is mute? Correct? We did not _intend_ for SENT-BY to be preserved ad-naseum thru the entire workflow process. I havent checked for any text that expressly precludes this; Im too busy looking for the next CAP URL. The SENT-BY is intended for indicating a proxys participatoin on someones behalf. As such its only 'valid' between the proxy and the Organzier (or the proxy and the Attendee if proxying for the Organzier). Beyond that point it becomes hearsay and of no use to anyone; the Organizer claims that someone acting on my behalf has ACCEPTed, etc. Also, where do you draw the line logically? If my AA COUNTERs and you reject it, does the SENT-BY still get put on subsequent REQUESTs? If the Organizer copied it to a new REQUEST and sent it out and I ACCEPTed then would you still put it on any subsequent REQUESTs? How about if I sent a REFRESH somewhere in the process? If I COUNTER a REQUEST that already has a SENT-BY on an _another_ ATTENDEE do I have to round trip it back to you (as if that would serve ANY purpose at all!!) If you ACCEPT my COUNTER w/another ATTENDEEs SENT-BY on it would it then be sent out on the new REQUEST too?? Certainly NOT IMHO but maybe thats just me. You are opening up a can of worms that has no benefit or use. > How would that make things more difficult for non-ORGANIZERs? They > would generally ignore the SENT-BY values - if they got them. Maybe in your engine but "generally" is not precise enough for an standard development. "Generally" recurrence rule handling/parsing/processing works consistantly... "Generally" CUAs should be able to deal with multipart MIME and still interoperate fully... To paraphrase someone: "These aren't the property parameters you're looking for. We can move along..." 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 005E788985256C62_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 10/29/2002 03:50:00 PM:
> Debatable - however the only(?) recipient of a COUNTER *IS*
> the ORGANIZER -

From 2446:

3.2.7 COUNTER

  The "COUNTER" method for a "VEVENT" calendar component is used by an
  "Attendee" of an existing event to submit to the "Organizer" a
  counter proposal to the event description. The "Attendee" sends this
  message to the "Organizer" of the event.

so the answer is that COUNTER is only between an Attendee and the Organizer.  No other parties are involved (except maybe an AA or two).

>                  which I think MUST keep the SENT-BY values
> in ALL messages - otherwise the data would be lost.

The SENT-BY information is ONLY of any real use in the context of the message it is associated with.  In all other cases its misleading or confusing or even inappropriate and inaccurate.

>                                                      So
> the only CUA that would get any COUNTER is the ORGANIZER, which
> MUST keep a copy of who sent them (if stored in UNPROCESED
> state). Do you agree?
The SENT-BY is only valid/useful in the context of the message it was on.  It was never intended to be preserved and passed on as a kind of hearsay ("Bruces AA says that he is delegating the meeting to Tom Ransdell").

In this conext I agree that SENT-BY is preserved (along w/all other supported properties and property parameters) on that particular message.

I do NOT agree that if you accept my COUNTER and send out a REQUEST to the other Attendees that my AAs SENT-BY value should be put on your new REQUEST.  Do you??  (It was implied in your "If it is valid to keep them (and I think it is)"

> At what point would a COUNTER be sent to another ATTENDEE?
From 2446:

   The "Organizer" rejects the counter proposal by sending the
  "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts
  the counter proposal by rescheduling the event as described in
  section 3.2.2.1 Rescheduling an Event.

so if you accept my (or my AAs) COUNTER to your REQUEST you send out a new REQUEST to those involved.  Copying over any SENT-BY property parameter is not that useful in the workflow process really.  There is only a minor distinction between "Bruce has ACCEPTED Dougs invitation" and "Bruces AA has ACCEPTED Dougs invitation on Bruces behalf" (or COUNTERed or...).  

ATTENDEEs do not send COUNTERs to one another.  The Organzier is the controller of the workflow process, NOT the separate Attendees.

> They CAN send the SENT-BY's in updates to any or all ATTENDEEs. There
> is no such restriction that I can find. However those ATTENDEE's would
> still not get a COUNTER, so the point is mute? Correct?

We did not _intend_ for SENT-BY to be preserved ad-naseum thru the entire workflow process.  I havent checked for any text that expressly precludes this; Im too busy looking for the next CAP URL.

The SENT-BY is intended for indicating a proxys participatoin on someones behalf.  As such its only 'valid' between the proxy and the Organzier (or the proxy and the Attendee if proxying for the Organzier).  Beyond that point it becomes hearsay and of no use to anyone; the Organizer claims that someone acting on my behalf has ACCEPTed, etc.

Also, where do you draw the line logically?  

If my AA COUNTERs and you reject it, does the SENT-BY still get put on subsequent REQUESTs?  

If the Organizer copied it to a new REQUEST and sent it out and I ACCEPTed then would you still put it on any subsequent REQUESTs?  

How about if I sent a REFRESH somewhere in the process?  

If I COUNTER a REQUEST that already has a SENT-BY on an _another_ ATTENDEE do I have to round trip it back to you (as if that would serve ANY purpose at all!!)

If you ACCEPT my COUNTER w/another ATTENDEEs SENT-BY on it would it then be sent out on the new REQUEST too??  Certainly NOT IMHO but maybe thats just me.

You are opening up a can of worms that has no benefit or use.

> How would that make things more difficult for non-ORGANIZERs? They
> would generally ignore the SENT-BY values - if they got them.

Maybe in your engine but "generally" is not precise enough for an standard development.  "Generally" recurrence rule handling/parsing/processing works consistantly...  "Generally" CUAs should be able to deal with multipart MIME and still interoperate fully...  

To paraphrase someone: "These aren't the property parameters you're looking for.  We can move along..."

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 005E788985256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 12:29:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27364 for ; Wed, 30 Oct 2002 12:29:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UHHt400753 for ietf-calendar-bks; Wed, 30 Oct 2002 09:17:55 -0800 (PST) Received: from agnus.ngi.it (agnus.ngi.it [194.177.103.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UHHsW00749 for ; Wed, 30 Oct 2002 09:17:54 -0800 (PST) Received: from inet.it (host50-59.pool80206.interbusiness.it [80.206.59.50]) by agnus.ngi.it (8.12.1/8.12.1) with ESMTP id g9UHHpaq025079 for ; Wed, 30 Oct 2002 18:17:52 +0100 Date: Wed, 30 Oct 2002 18:17:46 +0100 Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION Content-Type: multipart/alternative; boundary=Apple-Mail-4--290991628 Mime-Version: 1.0 (Apple Message framework v546) From: Andrea Campi To: ietf-calendar@imc.org In-Reply-To: Message-Id: <82557B8B-EC2B-11D6-A80F-003065A8EEFC@inet.it> X-Mailer: Apple Mail (2.546) Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-4--290991628 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Wednesday, October 30, 2002, at 05:07 PM, Bruce_Kahn@notesdev.ibm.com wrote: > > Question 3: > (Assumption: We finally realize that blind assumption about default > values for unknown clients is bad and correct this in the draft so > that both sides MUST support GET-CAPABILITY) > What good are defaults if both sides are mandated to send back a > response to GET-CAPABLITY? You know, that's exactly what I was thinking when I got your email... I strongly agree - defaults should go away. Bye, Andrea --Apple-Mail-4--290991628 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wednesday, October 30, 2002, at 05:07 PM, Bruce_Kahn@notesdev.ibm.com wrote: Question 3: (Assumption: We finally realize that blind assumption about default values for unknown clients is bad and correct this in the draft so that both sides MUST support GET-CAPABILITY) What good are defaults if both sides are mandated to send back a response to GET-CAPABLITY? You know, that's exactly what I was thinking when I got your email... I strongly agree - defaults should go away. Bye, Andrea --Apple-Mail-4--290991628-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 12:44:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28626 for ; Wed, 30 Oct 2002 12:44:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UHbAJ01272 for ietf-calendar-bks; Wed, 30 Oct 2002 09:37:10 -0800 (PST) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UHb9W01268 for ; Wed, 30 Oct 2002 09:37:09 -0800 (PST) Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9UHb5U11405 for ; Wed, 30 Oct 2002 09:37:05 -0800 (PST) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9UHb5I11395 for ; Wed, 30 Oct 2002 09:37:05 -0800 (PST) Received: from c1271 (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g9UHb4I16601 for ; Wed, 30 Oct 2002 10:37:04 -0700 (MST) Message-ID: <05d901c2803b$805d9e40$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3DC00D86.8000000@Royer.com> Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION Date: Wed, 30 Oct 2002 12:40:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Doug Royer" To: Sent: Wednesday, October 30, 2002 11:49 AM Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION > > Question 1: > > If CAP-VERSION can have a range (ie: CAP-VERSION:1.0;2.0) then what are > > the default values to be used by the CS when it supports multiple > > versions of CAP? The 1.0? 2.0? Some mix (assuming they are not > > mutually exclusive)? > > The default value as specified in the draft is "1.0". If an > implementation supported several version, then it would not > be the default, it would be 1.0;2.0 But what about the defaults for the other capabilities? If an implementation supports multiple versions of CAP, which defaults for the non-VERSION capabilities should be "the" default? (Actually, if a CUA can say "not implemented" and expect the CS to know that that means version 1.0, then the defaults MUST forever remain the 1.0 defaults, even in future versions of the spec; otherwise such CUAs risk being broken.) > > Question 2: > > Just what should a CUA or CS do when they detect a CAP-VERSION value > > that is above/below what they can deal with? For example, my CUA is > > CAP-VERSION:1.0 and my CS is CAP-VERSION:2.0;2.0 then what should happen > > when they try to work together? We never expressly codify what should > > happen in this case. > > It says '[It] must include at lest "1.0"..." > > So do you think it is valid to send only "2.0;2.0"? So even if some future version of CAP fixes some hypothetical fundamental flaw in the 1.0 version, and the new version is incompatible with 1.0, CSes and CUAs implementing the new version must ALSO implement the incompatible 1.0 version? > > Question 3: > > (Assumption: We finally realize that blind assumption about default > > values for unknown clients is bad and correct this in the draft so that > > both sides MUST support GET-CAPABILITY) > > What good are defaults if both sides are mandated to send back a > > response to GET-CAPABLITY? > > Your logic is failing :-) There has been no such agreement. Given the arguments provided against allowing a "not-implemented" response (Andrea summed it up nicely by noting that such a CUA would forever be restricted to CAP 1.0, and as noted above it also fixes in stone forever the default values for the 1.0 capabilities), is there still a reason to have that option? If both sides MUST support GET-CAPABILITY (i.e. eliminating the possibility of the CUA returning a not-implemented error), then defaults don't seem to be necessary because "When sending a reply to a "GET-CAPABILITY" command, all of these MUST BE supplied". Graham From owner-ietf-calendar@mail.imc.org Wed Oct 30 12:52:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29039 for ; Wed, 30 Oct 2002 12:52:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UHl3001744 for ietf-calendar-bks; Wed, 30 Oct 2002 09:47:03 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UHl2W01738 for ; Wed, 30 Oct 2002 09:47:02 -0800 (PST) In-Reply-To: <3DBEF2C2.4040209@Royer.com> To: ietf-calendar@imc.org Subject: Re: COUNTER - and who sent it. MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 12:44:51 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 12:47:05 PM, Serialize complete at 10/30/2002 12:47:05 PM Content-Type: multipart/alternative; boundary="=_alternative 0061C8D185256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0061C8D185256C62_= Content-Type: text/plain; charset="US-ASCII" Doug answered on 10/29/2002 03:42:42 PM: > Thank you - yes - we agree - now can you answer my question? :-) I did in an earlier posting, perhaps in a related thread though. Your last question was: > > - but you did not answer my question. Is it valid > > for the ORGANIZER to keep the SENT-BY values? The SENT-BY property parameter is ONLY valid/useful in the context of the message it was on. It is NOT useful/valid on any other messages either to the sender or to other parties involved. I would expect the Organizer to keep my AAs SENT-BY info only in so far as it relates to the message she sent on my behalf. Preserving it beyond that is not useful (nor was it ever intended to be preserved as such). She only acted on my behalf for that message, not for any other messages that the SENT-BY was _not_ on... If I ACCEPT and them my AA COUNTERs (and you reject it), would you send out her SENT-BY= on any further updates you send? Id hope not since it has no value and is not accurate. > > ATTENDEE:...SENT-BY="MAILTO:a@a.com" > > ;PARTSTAT=accepted:MAILTO:a1@a.com > > > > as motivation. My response is simply this: you dont use a SENT-BY for > > yourself since you are not acting on your behalf. > > Now I understand your point. Look closer the two email addresses > are NOT the same (I did not use SENT-BY for myself). Argh! Such tiny difference on my monitor is nearly unreadable. It took me 3 reads to see the "a" vs "a1". To avoid such violent agreements in the future may I suggest you use some value that is more noticably different like "a" and "z"... 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 0061C8D185256C62_= Content-Type: text/html; charset="US-ASCII"
Doug answered on 10/29/2002 03:42:42 PM:
> Thank you - yes - we agree - now can you answer my question? :-)
I did in an earlier posting, perhaps in a related thread though.  Your last question was:

> >   - but you did not answer my question. Is it valid
> > for the ORGANIZER to keep the SENT-BY values?
The SENT-BY property parameter is ONLY valid/useful in the context of the message it was on.  It is NOT useful/valid on any other messages either to the sender or to other parties involved.

I would expect the Organizer to keep my AAs SENT-BY info only in so far as it relates to the message she sent on my behalf.  Preserving it beyond that is not useful (nor was it ever intended to be preserved as such).  She only acted on my behalf for that message, not for any other messages that the SENT-BY was _not_ on...

If I ACCEPT and them my AA COUNTERs (and you reject it), would you send out her SENT-BY= on any further updates you send?  Id hope not since it has no value and is not accurate.

> >                                   ATTENDEE:...SENT-BY="MAILTO:a@a.com"
> >                  ;PARTSTAT=accepted:MAILTO:a1@a.com
> >
> > as motivation.  My response is simply this: you dont use a SENT-BY for
> > yourself since you are not acting on your behalf.
>
> Now I understand your point. Look closer the two email addresses
> are NOT the same (I did not use SENT-BY for myself).
Argh!  Such tiny difference on my monitor is nearly unreadable.  It took me 3 reads to see the "a" vs "a1".  To avoid such violent agreements in the future may I suggest you use some value that is more noticably different like "a" and "z"...

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 0061C8D185256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 13:38:00 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02798 for ; Wed, 30 Oct 2002 13:37:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UIThB04616 for ietf-calendar-bks; Wed, 30 Oct 2002 10:29:43 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UITfW04612 for ; Wed, 30 Oct 2002 10:29:41 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9UITgIR005056 for ; Wed, 30 Oct 2002 10:29:42 -0800 Message-ID: <3DC02518.20708@Royer.com> Date: Wed, 30 Oct 2002 11:29:44 -0700 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org CC: ietf-calendar@imc.org Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION References: <3DC00D86.8000000@Royer.com> <05d901c2803b$805d9e40$092e0165@in.steltor.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070603090905080307060003" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070603090905080307060003 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Graham Gilmore wrote: > > ----- Original Message ----- > From: "Doug Royer" > To: > Sent: Wednesday, October 30, 2002 11:49 AM > Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION > > > >>>Question 1: >>>If CAP-VERSION can have a range (ie: CAP-VERSION:1.0;2.0) then what are >>>the default values to be used by the CS when it supports multiple >>>versions of CAP? The 1.0? 2.0? Some mix (assuming they are not >>>mutually exclusive)? >> >> The default value as specified in the draft is "1.0". If an >> implementation supported several version, then it would not >> be the default, it would be 1.0;2.0 > > > But what about the defaults for the other capabilities? Are some missing default values? > If an implementation supports multiple versions of CAP, which defaults for the > non-VERSION capabilities should be "the" default? The ones in the spec. > (Actually, if a CUA can say "not implemented" and expect the CS to know > that that means version 1.0, then the defaults MUST forever remain > the 1.0 defaults, even in future versions of the spec; otherwise > such CUAs risk being broken.) Yes. > >>>Question 2: >>>Just what should a CUA or CS do when they detect a CAP-VERSION value >>>that is above/below what they can deal with? For example, my CUA is >>>CAP-VERSION:1.0 and my CS is CAP-VERSION:2.0;2.0 then what should happen >>>when they try to work together? We never expressly codify what should >>>happen in this case. >> >> It says '[It] must include at lest "1.0"..." >> >> So do you think it is valid to send only "2.0;2.0"? > > So even if some future version of CAP fixes some hypothetical > fundamental flaw in the 1.0 version, and the new version is incompatible > with 1.0, CSes and CUAs implementing the new version must ALSO implement the > incompatible 1.0 version? Let me restate what I think you asked: "If we decide to break from 1.0, will 2.0 mandate that all existing 1.0 implementations break?" I do not get your point. >>>Question 3: >>>(Assumption: We finally realize that blind assumption about default >>>values for unknown clients is bad and correct this in the draft so that >>>both sides MUST support GET-CAPABILITY) >>>What good are defaults if both sides are mandated to send back a >>>response to GET-CAPABLITY? >> >> Your logic is failing :-) There has been no such agreement. > > > Given the arguments provided against allowing a "not-implemented" > response (Andrea summed it up nicely by noting that such a CUA would forever > be restricted to CAP 1.0, and as noted above it also fixes in stone forever > the default values for the 1.0 capabilities), is there still a reason to > have that option? > > If both sides MUST support GET-CAPABILITY (i.e. eliminating the > possibility of the CUA returning a not-implemented error), then defaults > don't seem to be necessary because "When sending a reply to a > "GET-CAPABILITY" command, all of these MUST BE supplied". I argued FOR CUA's MUST reply == don't ask me :-) -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070603090905080307060003 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDE4Mjk0NFowIwYJKoZIhvcNAQkEMRYEFDIBeE7q cbUIZjbA8BDdDzNkZj/zMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAaN3Pyeqpr/ywQr9SC j0XsNnFUaCSCUgxqrGvuSejS4zp8C4F3nxGdwzI8ATqHdQ9lZJFmq1vdDwbm+x8/nO3Omz08 932RDiavHSCZvF+v5n8Doq69CfC0pX3IClnXCnkESQj7E53ezLxcNgsFQ4m2aDudnSafl3Jw g0qiX/vezD+CDxJ3QBvFdjMSluBc+9Vz0dz1BNf2l3qmta0+pMdkBBFwhQ7ftmCqYfPxS7k7 CsmlCzZKlcs91AO+8JUMj/8na2bknhpMrs8WRxBRKkxEQnEpqXuSyq7fMFrAaaHV7QKxHqpI rJJm/sz0DUVRnuQrC3iuxu0vCeUYPdbgtyXOAAAAAAAA --------------ms070603090905080307060003-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 13:39:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02950 for ; Wed, 30 Oct 2002 13:39:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UIXHC04684 for ietf-calendar-bks; Wed, 30 Oct 2002 10:33:17 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UIXGW04680 for ; Wed, 30 Oct 2002 10:33:16 -0800 (PST) To: ietf-calendar@imc.org Subject: Editorial: Consistant labeling of iMIP & iTIP MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 13:31:06 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 01:33:19 PM, Serialize complete at 10/30/2002 01:33:19 PM Content-Type: multipart/alternative; boundary="=_alternative 006604D085256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006604D085256C62_= Content-Type: text/plain; charset="US-ASCII" In trying to match my notes to the latest draft I noticed that the draft uses different formating at different points for the same kinds of reference. For example: "TARGET" and "CMD" properties. This memo does not address how a CUA transmits iTIP or iMIP objects to non CAP programs. followed later by: some [iMIP] objects or contacting other CS's and performing CAP operations on those CSs. The are mixed "iMIP" and "[iMIP]" references throughout the draft. Since the reference is to the RFC all references probably should be bracketed. I dont care which way the change goes as long as its consistant thru the draft. There are also similar iTIP/[iTIP] mixes that should be fixed concurrently. 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 006604D085256C62_= Content-Type: text/html; charset="US-ASCII"
In trying to match my notes to the latest draft I noticed that the draft uses different formating at different points for the same kinds of reference.  For example:

   "TARGET" and "CMD" properties.  This memo does not address how a CUA
  transmits iTIP or iMIP objects to non CAP programs.
followed later by:

   some [iMIP] objects or contacting other CS's and performing CAP
  operations on those CSs.

The are mixed "iMIP" and "[iMIP]" references throughout the draft.  Since the reference is to the RFC all references probably should be bracketed.  I dont care which way the change goes as long as its consistant thru the draft.

There are also similar iTIP/[iTIP] mixes that should be fixed concurrently.

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 006604D085256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 14:35:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06132 for ; Wed, 30 Oct 2002 14:35:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UJSfQ07289 for ietf-calendar-bks; Wed, 30 Oct 2002 11:28:41 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UJSeW07285 for ; Wed, 30 Oct 2002 11:28:40 -0800 (PST) To: ietf-calendar@imc.org Subject: 1.3 Defintions: BOOKED MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 14:26:28 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 02:28:43 PM, Serialize complete at 10/30/2002 02:28:43 PM Content-Type: multipart/alternative; boundary="=_alternative 006B169485256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006B169485256C62_= Content-Type: text/plain; charset="US-ASCII" The 09-b-2 draft says: BOOKED - xxx An entry in the calendar store has one of three conceptual states. It is "UNPROCESSED" state, "BOOKED" state or marked as "DELETED" state. How the implementation stores the state of any object is not a protocol issues and is not discussed. An object can be said to be booked, unprocessed, or marked for delete. First, the "xxx" after the dash should be removed. Second, the term 'entry' is used to denote those components like VEVENTs or VTODOs instead of using 'entity' which denotes all objects including VTIMEZONEs, VCARs, etc. There is no actual definition of what an 'entry' actually is. There is text under Section 2.2 that says: A CUA may create a "BOOKED" state entry by depositing a iCalendar object into the store. This is done by depositing an object that does not have a "METHOD" property. However this is not 100% accurate as a CUA can deposit a VCAR into the CS w/o a METHOD property and by this definition the VCAR would be considered "BOOKED". (Same goes for a VQUERY, VTIMEZONE, etc) We may want to create an explicit definition as to what a Calendar Entry is versus a Calendar Entity since we use the terms freely but not do not explicitly define them (see above). This could allow some folks to interpret the distinction incorrectly. To seed the distinction I would define entry explicitly as VEVENTs, VTODOs or VJOURNALs only and be done w/it. We cant just say "Any [RFC2445] defined components" because that would include VTIMEZONEs, VFREEBUSYs and VALARMs." Editorial: The text: 1. A "UNPROCESSED" state scheduling entry... should start with "An" instead of "A". Editorial suggestion: The text: All scheduled entries are [iTIP] objects. should include the phrase "group" to be more accurate: All group scheduled entries are [iTIP] objects. since I can schedule an event on my calendar w/o using iTIP (ie: I create a doctors appointment w/o using iTIP). Editorial suggestion: The text: 2. A booked entry is stored with the "CREATE" command. should be tweaked to be like the following for consistancy: 2. A "BOOKED" state entry is stored with the "CREATE" command. the same kind of change goes for changing: 3. A marked for delete component is set to the "DELETE" state. to something like: 3. A "DELETED" state entry has been marked for deletion or actually removed from the Calendar. After all you do not put deleted VCARs or VTIMEZONEs into a "DELETED" state do you? Along w/this change you probably should change the references of "deleted object" to "deleted entry" in that paragraph. If you opt not to make this change you need to change "DELETE" to "DELETED" at least. On the topic of querying for deleted entries, we should clearly state (preferably in 1.3) that no actual data is guaranteed to be returned for a "DELETED" entry with maybe the exception of the UID (maybe...). Otherwise we get into the rat hole of specifying tombstoning, etc. Id prefer we just clearly state that a CUA can query for DELETED entries and the CS can return some data but whats returned is not specified or guaranteed. 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 006B169485256C62_= Content-Type: text/html; charset="US-ASCII"
The 09-b-2 draft says:

   BOOKED -  xxx An entry in the calendar store has one of three
     conceptual states.  It is "UNPROCESSED" state, "BOOKED" state or
     marked as "DELETED" state.  How the implementation stores the
     state of any object is not a protocol issues and is not discussed.
     An object can be said to be booked, unprocessed, or marked for
     delete.
First, the "xxx" after the dash should be removed.

Second, the term 'entry' is used to denote those components like VEVENTs or VTODOs instead of using 'entity' which denotes all objects including VTIMEZONEs, VCARs, etc.  There is no actual definition of what an 'entry' actually is.  There is text under Section 2.2 that says:

   A CUA may create a "BOOKED" state entry by depositing a iCalendar
  object into the store.  This is done by depositing an object that
  does not have a "METHOD" property.

However this is not 100% accurate as a CUA can deposit a VCAR into the CS w/o a METHOD property and by this definition the VCAR would be considered "BOOKED".  (Same goes for a VQUERY, VTIMEZONE, etc)

We may want to create an explicit definition as to what a Calendar Entry is versus a Calendar Entity since we use the terms freely but not do not explicitly define them (see above).  This could allow some folks to interpret the distinction incorrectly.   To seed the distinction I would define entry explicitly as VEVENTs, VTODOs or VJOURNALs only and be done w/it.  We cant just say "Any [RFC2445] defined components" because that would include VTIMEZONEs, VFREEBUSYs and VALARMs."

Editorial:  The text:

      1.  A "UNPROCESSED" state scheduling entry...

should start with "An" instead of "A".

Editorial suggestion:  The text:

                                  All scheduled entries are
         [iTIP] objects.

should include the phrase "group" to be more accurate:

                                  All group scheduled entries are
         [iTIP] objects.

since I can schedule an event on my calendar w/o using iTIP (ie: I create a doctors appointment w/o using iTIP).

Editorial suggestion:  The text:

      2.  A booked entry is stored with the "CREATE" command.

should be tweaked to be like the following for consistancy:


      2.  A "BOOKED" state entry is stored with the "CREATE" command.

the same kind of change goes for changing:

      3.  A marked for delete component is set to the "DELETE" state.

to something like:

      3.  A "DELETED" state entry has been marked for deletion or actually removed from the Calendar.

After all you do not put deleted VCARs or VTIMEZONEs into a "DELETED" state do you?  Along w/this change you probably should change the references of "deleted object" to "deleted entry" in that paragraph.

If you opt not to make this change you need to change "DELETE" to "DELETED" at least.

On the topic of querying for deleted entries, we should clearly state (preferably in 1.3) that no actual data is guaranteed to be returned for a "DELETED" entry with maybe the exception of the UID (maybe...).  Otherwise we get into the rat hole of specifying tombstoning, etc.  Id prefer we just clearly state that a CUA can query for DELETED entries and the CS can return some data but whats returned is not specified or guaranteed.

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 006B169485256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 14:51:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06913 for ; Wed, 30 Oct 2002 14:51:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UJkPE08281 for ietf-calendar-bks; Wed, 30 Oct 2002 11:46:25 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UJkOW08275 for ; Wed, 30 Oct 2002 11:46:24 -0800 (PST) To: ietf-calendar@imc.org Subject: 2.2 Relationship of RFC-2446 (ITIP) and CAP: Taking no action MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 14:46:20 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 02:46:27 PM, Serialize complete at 10/30/2002 02:46:27 PM Content-Type: multipart/alternative; boundary="=_alternative 006CB62B85256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006CB62B85256C62_= Content-Type: text/plain; charset="US-ASCII" In 09-b-2, Section 2.2 Relationship of RFC-2446 (ITIP) and CAP is: The CUA could also decide not to book the object. In which case the "UNPROCESSED" state objects could be deleted from the CS. Or the CUA could set those object to the marked for delete state. There is another option that should be added to the list since we are listing options. The other option is the CUA decides to take no action and as such does NOT remove the "UNPROCESSED" objects from the CS. Just because I open an email does not mean I have to take any action on it (unless its a posting from Doug). Hmm, besides the grammar bug I already reported to Doug in the last line I think that the 3rd sentence says basically the same thing that the 2nd does. Dont both say that the CUA can delete the entry??... 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 006CB62B85256C62_= Content-Type: text/html; charset="US-ASCII"
In 09-b-2, Section 2.2 Relationship of RFC-2446 (ITIP) and CAP is:

   The CUA could also decide not to book the object.  In which case the
  "UNPROCESSED" state objects could be deleted from the CS.  Or the CUA
  could set those object to the marked for delete state.

There is another option that should be added to the list since we are listing options.  The other option is the CUA decides to take no action and as such does NOT remove the "UNPROCESSED" objects from the CS.  Just because I open an email does not mean I have to take any action on it (unless its a posting from Doug).

Hmm, besides the grammar bug I already reported to Doug in the last line I think that the 3rd sentence says basically the same thing that the 2nd does.  Dont both say that the CUA can delete the entry??...

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 006CB62B85256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 15:12:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08244 for ; Wed, 30 Oct 2002 15:12:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UK4Z710650 for ietf-calendar-bks; Wed, 30 Oct 2002 12:04:35 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UK4ZW10646 for ; Wed, 30 Oct 2002 12:04:35 -0800 (PST) To: ietf-calendar@imc.org Subject: 2.2 Relationship of RFC-2446 (ITIP) and CAP: Soft deletes? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 15:04:31 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/30/2002 03:04:37 PM, Serialize complete at 10/30/2002 03:04:37 PM Content-Type: multipart/alternative; boundary="=_alternative 006E606785256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006E606785256C62_= Content-Type: text/plain; charset="US-ASCII" Ok, maybe its just me but when I read in Section 2.2 Relationship of RFC-2446 (ITIP) and CAP: The marked for delete state is used to keep the object around so that the CUA can process duplicate requests automatically. If a duplicate [iTIP] object is deposited into the CS and there exists identical marked for delete objects, then a CUA acting on behalf of the "OWNER" can silently drop those duplicate entries. I cant help but thinking that we just created 'soft deletes' and are mandating that all CUAs/CSs implement them. If an entry is deleted there can be no guarantee that its data still exists. As such its not going to be possible to perform accurate duplicate [iTIP] object detection. If we are going to mandate soft-deletions be used (please NO!!) then we need lots more text to be clearer how all they should be implemented. Im of the opinion that at most Ill want my CS to keep around a UID and RECURRENCE-IDs to do deletion detection with some course of action suggestions I can give my CU. Detecting 'duplicate responses' may sound well and good but if I took the "merge the UNPROCESSED entries into a BOOKED entry" advocated in the draft then I may not want automatic detection and deletion to occur. For example: Doug ACCEPTs my invitation and I process it into my BOOKED entry and delete his ACCEPT message. He then DECLINEs and then changes his mind and ACCEPTs again. Should be CS detect his 2nd ACCEPTance and toss it leaving me w/just a DECLINE?? Nope. The same goes for multiple COUNTERs, etc. The only times deletion detection is helpful (in my view) are cases like: I accidentally deleted an entry I was invited to and I call and have the Organizer re-invite me so I can add it to my calendar again. I purposely deleted a meeting Im the Organzier for and sent out CANCELation notices to my Invitees. Some didnt get it and send me COUNTERs, REPLYs, etc. Detecting this allows me to craft a new cancellation notice. If the CUA wants to be nice for me as described then it would toss away the new REQUEST in the former example and likely flounder and do nothing in the latter case. The only way for the CUA to detect the deletion is to do a query for a deletion 'hit' for every UNPROCESSED entry its dealing with. Sounds like LOTS of overhad I want to avoid... Can we strike this bit about doing silent deletions since it implys so much baggage?... 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 006E606785256C62_= Content-Type: text/html; charset="US-ASCII"
Ok, maybe its just me but when I read in Section 2.2 Relationship of RFC-2446 (ITIP) and CAP:

   The marked for delete state is used to keep the object around so that
  the CUA can process duplicate requests automatically.  If a duplicate
  [iTIP] object is deposited into the CS and there exists identical
  marked for delete objects, then a CUA acting on behalf of the "OWNER"
  can silently drop those duplicate entries.
I cant help but thinking that we just created 'soft deletes' and are mandating that all CUAs/CSs implement them.  If an entry is deleted there can be no guarantee that its data still exists.  As such its not going to be possible to perform accurate duplicate [iTIP] object detection.

If we are going to mandate soft-deletions be used (please NO!!) then we need lots more text to be clearer how all they should be implemented.

Im of the opinion that at most Ill want my CS to keep around a UID and RECURRENCE-IDs to do deletion detection with some course of action suggestions I can give my CU.   Detecting 'duplicate responses' may sound well and good but if I took the "merge the UNPROCESSED entries into a BOOKED entry" advocated in the draft then I may not want automatic detection and deletion to occur.  

For example: Doug ACCEPTs my invitation and I process it into my BOOKED entry and delete his ACCEPT message.  He then DECLINEs and then changes his mind and ACCEPTs again.  Should be CS detect his 2nd ACCEPTance and toss it leaving me w/just a DECLINE??  Nope.  The same goes for multiple COUNTERs, etc.

The only times deletion detection is helpful (in my view) are cases like:

I accidentally deleted an entry I was invited to and I call and have the Organizer re-invite me so I can add it to my calendar again.
I purposely deleted a meeting Im the Organzier for and sent out CANCELation notices to my Invitees.  Some didnt get it and send me COUNTERs, REPLYs, etc.  Detecting this allows me to craft a new cancellation notice.

If the CUA wants to be nice for me as described then it would toss away the new REQUEST in the former example and likely flounder and do nothing in the latter case.

The only way for the CUA to detect the deletion is to do a query for a deletion 'hit' for every UNPROCESSED entry its dealing with.  Sounds like LOTS of overhad I want to avoid...

Can we strike this bit about doing silent deletions since it implys so much baggage?...

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 006E606785256C62_=-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 15:15:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08486 for ; Wed, 30 Oct 2002 15:15:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UKArf10844 for ietf-calendar-bks; Wed, 30 Oct 2002 12:10:53 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UKApW10840 for ; Wed, 30 Oct 2002 12:10:51 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9UKAqIR006032 for ; Wed, 30 Oct 2002 12:10:52 -0800 Message-ID: <3DC03CCF.4030209@Royer.com> Date: Wed, 30 Oct 2002 13:10:55 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000707040808090706020008" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000707040808090706020008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > We may want to create an explicit definition as to what a Calendar Entry > is versus a Calendar Entity since we use the terms freely but not do not > explicitly define them (see above). This could allow some folks to > interpret the distinction incorrectly. To seed the distinction I would > define entry explicitly as VEVENTs, VTODOs or VJOURNALs only and be done > w/it. We cant just say "Any [RFC2445] defined components" because that > would include VTIMEZONEs, VFREEBUSYs and VALARMs." Again - what's the problem? It is true. --------------ms000707040808090706020008 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDIwMTA1NVowIwYJKoZIhvcNAQkEMRYEFC9PvtbM 9jfaC7HutZv8h11L812/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBJrNQIZX0Nw8AVjh/O oaA5OsGnLwxXcEORTQQr/I3aPJG9rW3nhr8zPEA0ZawnzxW6UmzkDf/HeJkUgjAcuZZeMaDz bZPJDhpAG1nZKMNjq3zhKq/vGAjeVtQvltq54jki5jHVEUzckT3C2Kk26V5JS9+RQdmp613y bsxG41zpjSF9Xl9tqOgKzhhl0+7Nn5Vzkmg4HrpsI2Kviq9bDXpp1X7hyOTZCKDtgDLnG+ax M5CVu+nXesc1BpKJkDcZ4dvv7PZvKYsZqbMsO7xN/poLTGSQrZoORh7+p/VOYc5BXk68gV4e ZS6DHzFzvYzknVkpZbKWZ1PkPLfR2UnBNgIKAAAAAAAA --------------ms000707040808090706020008-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 15:15:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08488 for ; Wed, 30 Oct 2002 15:15:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UK9tm10799 for ietf-calendar-bks; Wed, 30 Oct 2002 12:09:55 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UK9rW10795 for ; Wed, 30 Oct 2002 12:09:53 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9UK9tIR006004 for ; Wed, 30 Oct 2002 12:09:55 -0800 Message-ID: <3DC03C96.6080306@Royer.com> Date: Wed, 30 Oct 2002 13:09:58 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050505010501040304050803" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050505010501040304050803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > A CUA may create a "BOOKED" state entry by depositing a iCalendar > object into the store. This is done by depositing an object that > does not have a "METHOD" property. > > However this is not 100% accurate as a CUA can deposit a VCAR into the > CS w/o a METHOD property and by this definition the VCAR would be > considered "BOOKED". (Same goes for a VQUERY, VTIMEZONE, etc) What's the problem? --------------ms050505010501040304050803 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDIwMDk1OFowIwYJKoZIhvcNAQkEMRYEFP4+DUOc tZMZ0n+nJh40NWZr0tlpMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBQc/gzyoDZsdaVvbNd VXxZeBpoyl2DG4zgsrSZc4BlkL3DOOdaUV3w7rGEWtmNZDNuOr6iMwHixGeg409Xp/BMgXym Cf24ZQF2Y9Nc9HShrHLXR2p/WKm0wHBdC8O0PirweGgewhBJswntkndAK3SfpGlazfqO9D6h +4DBGkToGovOJKwVndez3oP7rkx1Dyl6456qxlBKqh9u4spgHxqMElYByuDbp0IhskAd4C6x SBx5KQrg3+LyIbFPhWnmTNIYWFzALOwLz6oc/pzf0Si8ogDvTRb4uHGkWpXFMb9oRkOUmwFj mueALCAdign6gGHafbyPmE6cAus5kAXM+KDrAAAAAAAA --------------ms050505010501040304050803-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 15:15:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08519 for ; Wed, 30 Oct 2002 15:15:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UK5k510668 for ietf-calendar-bks; Wed, 30 Oct 2002 12:05:46 -0800 (PST) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UK5eW10663 for ; Wed, 30 Oct 2002 12:05:40 -0800 (PST) Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9UK5b110048 for ; Wed, 30 Oct 2002 12:05:38 -0800 (PST) Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9UK5bj10042 for ; Wed, 30 Oct 2002 12:05:37 -0800 (PST) Received: from c1271 (Montreal-vpn-pc1.vpn.oracle.com [141.144.2.172]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g9UK5aB05268 for ; Wed, 30 Oct 2002 13:05:36 -0700 (MST) Message-ID: <066701c28050$407b0be0$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: <3DC00D86.8000000@Royer.com> <05d901c2803b$805d9e40$092e0165@in.steltor.com> <3DC02518.20708@Royer.com> Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION Date: Wed, 30 Oct 2002 15:09:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Bruce wrote] > >>>Question 3: > >>>(Assumption: We finally realize that blind assumption about default > >>>values for unknown clients is bad and correct this in the draft so that > >>>both sides MUST support GET-CAPABILITY) > >>>What good are defaults if both sides are mandated to send back a > >>>response to GET-CAPABLITY? [Doug wrote] > >> > >> Your logic is failing :-) There has been no such agreement. [I wrote] > > > > Given the arguments provided against allowing a "not-implemented" > > response (Andrea summed it up nicely by noting that such a CUA would forever > > be restricted to CAP 1.0, and as noted above it also fixes in stone forever > > the default values for the 1.0 capabilities), is there still a reason to > > have that option? > > > > If both sides MUST support GET-CAPABILITY (i.e. eliminating the > > possibility of the CUA returning a not-implemented error), then defaults > > don't seem to be necessary because "When sending a reply to a > > "GET-CAPABILITY" command, all of these MUST BE supplied". [Doug wrote] > > I argued FOR CUA's MUST reply == don't ask me :-) So you agree, and Bruce agrees, and Andrea agrees, I agree, everyone who has expressed an opinion on the subject agrees... that sounds an awful lot like agreement. Agreed? :) To sum up what I think everyone seems to be agreeing to: We should change section 9.3 of the spec (http://inet-consulting.com/cap-09-2.txt) from this: "A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. The "GET-CAPABILITY" command MUST BE implemented by all CSs. The CS MUST send a "GET-CAPABILITY" command to a CUA after the initial connection. The CUA MUST recogonize the "GET-CAPABILITY" command and MAY return a not implemented reply meaning that the CUA supports only the default capababilities." to this: "A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial connection. The "GET-CAPABILITY" command MUST BE implemented by all CSs. The CS MUST send a "GET-CAPABILITY" command to a CUA after the initial connection. The "GET-CAPABILITY" command MUST BE implemented by all CUAs." Or perhaps some even better phrasing thereof. Furthermore, I would PROPOSE that, given that (a) the above change is *agreed* to (any objections? anyone?), and that (b) the aforementioned spec also reads (again in section 9.3): "When sending a reply to a "GET-CAPABILITY" command, all of these MUST BE supplied." We can therefore remove references to "default" values for capabilities within the GET-CAPABILITIES reply, since they must all be supplied in any case and there would be no occasion where a CS or CUA would need to use the defaults. Comments? Graham From owner-ietf-calendar@mail.imc.org Wed Oct 30 15:18:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08672 for ; Wed, 30 Oct 2002 15:18:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UKCU010920 for ietf-calendar-bks; Wed, 30 Oct 2002 12:12:30 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UKCSW10913 for ; Wed, 30 Oct 2002 12:12:28 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9UKCTIR006050 for ; Wed, 30 Oct 2002 12:12:29 -0800 Message-ID: <3DC03D30.80205@Royer.com> Date: Wed, 30 Oct 2002 13:12:32 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090502050608080203070804" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090502050608080203070804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > After all you do not put deleted VCARs or VTIMEZONEs into a "DELETED" > state do you? Why not? -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms090502050608080203070804 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDIwMTIzMlowIwYJKoZIhvcNAQkEMRYEFB6rUBIl swk4pIEiq1DeC77ix+1uMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCjHQGf77oA2eAwPcGt LDkP7FPfqHE28MwXSaZGtnJCj2klbWdcr83zhkNM2WYu3fRnlmR6XOiNmsI9Vp+sIY7h4Xqy IGFT+fYA9Gp/1C9CtMj36eRvFXC6I1pZcqfIi+a+IZDkRvtBi6t/Pj6pkYAIYZU/mu1SX9Ho yraX7hrJ9ng/4ddqx0FsLNPc8XXN0Sdsog9l8QZA3BVOoGhwIg93iaxmljjSGIz1AAd9/Pc3 S827TCGtwu+wCispzb6QdjtAkzxMUqhz6oaWtMhzsnJUNDauaVM4IuIJNlHuDFZtKeuG9yqK loJOgN6UzCMYHf1UcFbOqMzpZ/u49NQC8DbZAAAAAAAA --------------ms090502050608080203070804-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 15:23:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08938 for ; Wed, 30 Oct 2002 15:23:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UKIYI11175 for ietf-calendar-bks; Wed, 30 Oct 2002 12:18:34 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UKIXW11171 for ; Wed, 30 Oct 2002 12:18:33 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9UKIUIR006105 for ; Wed, 30 Oct 2002 12:18:31 -0800 Message-ID: <3DC03E9A.3000101@Royer.com> Date: Wed, 30 Oct 2002 13:18:34 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000707090506060301090106" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000707090506060301090106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > On the topic of querying for deleted entries, we should clearly state > (preferably in 1.3) that no actual data is guaranteed to be returned for > a "DELETED" entry with maybe the exception of the UID (maybe...). > Otherwise we get into the rat hole of specifying tombstoning, etc. Id > prefer we just clearly state that a CUA can query for DELETED entries > and the CS can return some data but whats returned is not specified or > guarantee. No, that won't work. Other reasons for the DELETED state are: Detection of duplicate iTIP messages Your going to have to keep the entire object in order to detect if it is a duplicate. Ignoring events for which you do not wish to attend. If you keep getting a REQUEST for a meeting, you can mark it as DELETED and then ignore any updates. In some cases you will want to remain on the distribution list, even if you are not going to attend a specific instance. AND I do not recall this WG discussing ANY options that would allow the CS or CUA to remove anything from the marked for deleted objects. The only change to the object is it state. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms000707090506060301090106 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDIwMTgzNFowIwYJKoZIhvcNAQkEMRYEFA3DiYDh sVe1HscfSmwv2t1Otz9lMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAp4oTkRP38Gg50UZJY e4KO3bM8CdcBqANlm6yemQOv15BejAPgJiE8HoCHb1150mhbeHmvXrdoZKz1ZzaHl+WMP81f 9h8prARB6IA2D0YGWedoBZrYutPQP33gx85fhRGDA3XLvHTgACFSFjlKnY076ogAstyFV2/D DsoBTknAl1NmwoMyVah1xXTjCvl1uxpdA4V9etofQePP4TnIkSj+nNLEyxp0KDq1soYni1C1 PM+4HsKQ6KnUpE47mb2yqivXz+yePycktqb+P83CGovHrUHsWArMn0Au3isHLBkYXY9dOrWk SHW7JbEdxHO0kmuyVB1Rqxxdr/JRqT6s7K0/AAAAAAAA --------------ms000707090506060301090106-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 15:26:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09109 for ; Wed, 30 Oct 2002 15:26:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UKM7U11257 for ietf-calendar-bks; Wed, 30 Oct 2002 12:22:07 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UKM6W11253 for ; Wed, 30 Oct 2002 12:22:06 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9UKM7IR006135 for ; Wed, 30 Oct 2002 12:22:07 -0800 Message-ID: <3DC03F72.70101@Royer.com> Date: Wed, 30 Oct 2002 13:22:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 2.2 Relationship of RFC-2446 (ITIP) and CAP: Taking no action References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070107050106000405080108" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070107050106000405080108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > In 09-b-2, Section 2.2 Relationship of RFC-2446 (ITIP) and CAP is: > > The CUA could also decide not to book the object. In which case the > "UNPROCESSED" state objects could be deleted from the CS. Or the CUA > could set those object to the marked for delete state. > > There is another option that should be added to the list since we are > listing options. The other option is the CUA decides to take no action > and as such does NOT remove the "UNPROCESSED" objects from the CS. Just > because I open an email does not mean I have to take any action on it > (unless its a posting from Doug). I'll add. > Hmm, besides the grammar bug I already reported to Doug in the last line > I think that the 3rd sentence says basically the same thing that the 2nd > does. Dont both say that the CUA can delete the entry??... I'll make it clearer - in one case the object is marked for delete. In the other - it is deleted. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070107050106000405080108 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDIwMjIxMFowIwYJKoZIhvcNAQkEMRYEFNDj94VW hYAiEEyZRHUmpALLEg4iMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAyXRl6lWSqaoLqrL0S E883iDBKyfqDWUARWNRmq0w5A2JiNIo7HHGOWJCTtscCZuiYTDbbmvuTtDbrmE5koNIjmDQx bRpbUBYwL4VttKAtBvfOnsxD/qiZUEk33xv5DtTJ4oAUfXz9zgkuDF4sPtf2yyOY+Xey7uPx DnBbmKAF+5NPnrma+aeKNs+TRwOliep9NJz9to7agLiaksjbtWiy+lIy7M2Lhq42fcP9/sRC 8XFJ7g4r56envgu5U6+ccv/uuUYPwocdvLKpJu0JYGXrqaU2imprcIMUmx5BnM0ynDdkpYTI nhehE1qrk8nFiV1DMqXXMV8G7hWmLoabne0AAAAAAAAA --------------ms070107050106000405080108-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 16:51:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14373 for ; Wed, 30 Oct 2002 16:51:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9ULg7015455 for ietf-calendar-bks; Wed, 30 Oct 2002 13:42:07 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9ULg5W15450 for ; Wed, 30 Oct 2002 13:42:05 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9ULg7IR006772 for ; Wed, 30 Oct 2002 13:42:07 -0800 Message-ID: <3DC05232.3090906@Royer.com> Date: Wed, 30 Oct 2002 14:42:10 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 9.3 GET-CAPABILITY - CAP-VERSION References: <3DC00D86.8000000@Royer.com> <05d901c2803b$805d9e40$092e0165@in.steltor.com> <3DC02518.20708@Royer.com> <066701c28050$407b0be0$092e0165@in.steltor.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000703060403070402090504" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000703060403070402090504 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit > So you agree, and Bruce agrees, and Andrea agrees, I agree, everyone who > has expressed an opinion on the subject agrees... No - not everyone agreed - please re-read the archives. I changed it to what it is now after that debate. It would be great to get rid of the default values and go back to minimumims. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms000703060403070402090504 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDIxNDIxMFowIwYJKoZIhvcNAQkEMRYEFGtWGeHe 12OG3yhjGhIoS+Utzz+BMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAHb3MFR+hQD2WKTzwD M0qzchhL29T8HQ3WEPXAG/P8Et/1FL50gt4U8wc8lEKtU9bB91GaYHC8Fhzy52ktN7BAj80Y /KvrdkFOb/0Frn/DUvQljA8ApdA8DDp3eBN9W9NHjNidOHE1sG4JKaL3j5zsTVhrahBWrOkM 66LWFNhz7s4SHVal09CAF7wNywvFJvj+W3VpZSXqtAeYjthKhCN7HgYILXp6ipix3+xB7isO cryUKysr+33y3zE9Y28O5E1kgHVvDJPw5O3TdMqTt+KebF9L0YTPfBTq87N2uYlAVNVJpwd0 5zAen7JyWaFXmyal1U/pIpVIEwjT/aF/uwFZAAAAAAAA --------------ms000703060403070402090504-- From owner-ietf-calendar@mail.imc.org Wed Oct 30 16:55:45 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14575 for ; Wed, 30 Oct 2002 16:55:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9ULp1N15609 for ietf-calendar-bks; Wed, 30 Oct 2002 13:51:01 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9ULoxW15602 for ; Wed, 30 Oct 2002 13:50:59 -0800 (PST) Received: from Royer.com ([12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9ULp0IR006836 for ; Wed, 30 Oct 2002 13:51:01 -0800 Message-ID: <3DC05448.6060600@Royer.com> Date: Wed, 30 Oct 2002 14:51:04 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 2.2 Relationship of RFC-2446 (ITIP) and CAP: Soft deletes? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060508040306030403090601" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060508040306030403090601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Ok, maybe its just me but when I read in Section 2.2 Relationship of > RFC-2446 (ITIP) and CAP: > > The marked for delete state is used to keep the object around so that > the CUA can process duplicate requests automatically. If a duplicate > [iTIP] object is deposited into the CS and there exists identical > marked for delete objects, then a CUA acting on behalf of the "OWNER" > can silently drop those duplicate entries. > I cant help but thinking that we just created 'soft deletes' and are > mandating that all CUAs/CSs implement them. We did not 'just create' anything - it has been on the list for a long time (years?). And I assume when you say 'soft deletes' you are talking about the DELETED state? > If an entry is deleted there can be no guarantee that its > data still exists. I guarantee you: if you delete the data - it does not exist. > As such its not > going to be possible to perform accurate duplicate [iTIP] object detection. So don't delete the data - mark it for delete (aka DELETED state). > If we are going to mandate soft-deletions be used (please NO!!) then we > need lots more text to be clearer how all they should be implemented. Bruce - this topic has been on the list for YEARS. This is nothing new. > Im of the opinion that at most Ill want my CS to keep around a UID and > RECURRENCE-IDs to do deletion detection with some course of action > suggestions I can give my CU. Detecting 'duplicate responses' may > sound well and good but if I took the "merge the UNPROCESSED entries > into a BOOKED entry" advocated in the draft then I may not want > automatic detection and deletion to occur. The CS does not automatically do anything. The DELETED state exists for CUAs. If you do not want to tag objects as DELETED, then don't. > For example: Doug ACCEPTs my invitation and I process it into my BOOKED > entry and delete his ACCEPT message. He then DECLINEs and then changes > his mind and ACCEPTs again. Should be CS detect his 2nd ACCEPTance and > toss it leaving me w/just a DECLINE?? Nope. The same goes for multiple > COUNTERs, etc. I think you are confusing marked for delete (DELETED state) and removing the object from the store. See the DELETE command. "If a component is to be marked for delete and not physically removed, then include the "OPTIONS" parameter with its value set to the "MARK" value in order to alter its state to "DELETED"." > > Can we strike this bit about doing silent deletions since it implys so > much baggage?... I can not find any text in CAP about 'silent deletions'. > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms060508040306030403090601 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMDIxNTEwNFowIwYJKoZIhvcNAQkEMRYEFHM5QPtC JkTAwCZ5fTWImk/QkM2eMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBpm87MIvH0e0xDrb+l jJX7S7xAMi2HNBCiAAXa7gzWLhFjeGkq0bqCkaSAL41NSrSm3eVyLnMxe/70KvvGyScrRA0D IOUdPo50TPwkIb37Q5Uf/p4JaYv7lvrbsu5k76AQ5sfF0UvaUsIn7yKlIXKeyh/8wtipS1zJ ygyuBCofA+CBcnYQksvXI3d0SY9fiq8XM8+L1uCejdC2jnCip2J+BKTcKVzKuX1mNtc1bFiz LHisRQAa4ZyQ0sJJ2jA7VQfKGe/TvLJOm5S7xlTKwcSR1ehbm5/CKR4FTGGnSTJA18wumbER RZd7uKGi4xDVUVT8qqIZ+r9P70A8L/hdCmIsAAAAAAAA --------------ms060508040306030403090601-- From owner-ietf-calendar@mail.imc.org Thu Oct 31 07:09:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15194 for ; Thu, 31 Oct 2002 07:09:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VC28Z03023 for ietf-calendar-bks; Thu, 31 Oct 2002 04:02:08 -0800 (PST) Received: from eeyore.jsoft.com (24-240-234-245.charter.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VC27W03017 for ; Thu, 31 Oct 2002 04:02:07 -0800 (PST) Received: from jsoft.com (IDENT:NQ4hv6Sfr+xoQb0TH8CWCSMV2QEVt5Du@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id g9VBufC00404 for ; Thu, 31 Oct 2002 05:56:42 -0600 Message-ID: <3DC11A79.1020503@jsoft.com> Date: Thu, 31 Oct 2002 05:56:41 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Diffs - http://INET-Consulting.com/cap-09-b-2.{txt,html} References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit What's the status of the changes? I see good conversation going on. I also think the draft (the version I read) was pretty good, nice job! Are we submitting as is and then moving forward? Gary pregen@egenconsulting.com wrote: > > We should wait for changes to be made that match what the list wants. > That's why I posted my comments > > Here's what the IETF sent as the deadline. NOte that they ask for no > last minutes submissions. We fall into the 11/4 deadline date. > > > > > Please do NOT wait until the last minute to submit. > > > >Be advised: NO placeholders. Updates to initial submissions received > > the week of October 28th will NOT be accepted. > > > >November 4th: FINAL Internet-Draft Cutoff > > > ___________________ > Patricia Egen Consulting > www.egenconsulting.com > 423-875-2652 > > > *Andrea Campi * > Sent by: owner-ietf-calendar@mail.imc.org > > 10/23/2002 15:49 > > > To: pregen@egenconsulting.com > cc: Doug Royer , ietf-calendar@imc.org > Subject: Re: Diffs - > http://INET-Consulting.com/cap-09-b-2.{txt,html} > > > > > Hi Pat, > > On Wednesday, October 23, 2002, at 08:41 PM, pregen@egenconsulting.com > wrote: > > > > > Hi, i hope everyone is taking this opportunity to read Doug's changes. > > Is anyone opposed to what is there so far? If so please say so on > > the list. If I do not hear angry outbursts or major objections, then > > we will have Doug submit the changes to date. > > I'm currently going through my notes, I hope to finish posting what I > think tonight but it might take longer. Could we please wait a little > more, just to be sure we at least fix those issues we already had > consensus on? > > Bye, > Andrea > From owner-ietf-calendar@mail.imc.org Thu Oct 31 08:44:25 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18844 for ; Thu, 31 Oct 2002 08:44:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VDZh012454 for ietf-calendar-bks; Thu, 31 Oct 2002 05:35:43 -0800 (PST) Received: from Arista.iris.com (bi-01pt1.bluebird.ibm.com [129.42.208.186]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VDZgW12448 for ; Thu, 31 Oct 2002 05:35:42 -0800 (PST) In-Reply-To: <3DBED0E0.9060003@Royer.com> To: ietf-calendar@imc.org Subject: Re: 3.1 System Model MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 30 Oct 2002 09:54:55 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.11 |July 24, 2002) at 10/31/2002 08:35:43 AM, Serialize complete at 10/31/2002 08:35:43 AM Content-Type: multipart/alternative; boundary="=_alternative 0052118185256C62_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0052118185256C62_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 10/29/2002 01:18:08 PM: > Are you saing my email had an error - or the draft? Both. Your example is not in the draft(S) that Ive read and its already been shown as being in violation of the 2445 ABNF. In looking at the even more recent -09-b-2 draft I find that it too is in error. For example, from Section 3.3.1 Use of BEEP, MIME and iCalendar: C: MSG 1 2 . 432 62 C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: VERSION:2.0 C: PRODID:-//someone's prodid C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID C: END:VCALENDAR C: END Both violate the ABNF for icalbody from 2445: icalbody = calprops component because there is no component present; its all 'calprops'. 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 0052118185256C62_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 10/29/2002 01:18:08 PM:
> Are you saing my email had an error - or the draft?
Both.  Your example is not in the draft(S) that Ive read and its already been shown as being in violation of the 2445 ABNF.  In looking at the even more recent -09-b-2 draft I find that it too is in error.  For example, from Section 3.3.1 Use of BEEP, MIME and iCalendar:

      C: MSG 1 2 . 432 62
     C: Content-Type: text/calendar
     C:
     C: BEGIN:VCALENDAR
     C: VERSION:2.0
     C: PRODID:-//someone's prodid
     C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID
     C: END:VCALENDAR
     C: END
Both violate the ABNF for icalbody from 2445:

      icalbody   = calprops component
because there is no component present; its all 'calprops'.

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 0052118185256C62_=-- From owner-ietf-calendar@mail.imc.org Thu Oct 31 13:42:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07258 for ; Thu, 31 Oct 2002 13:42:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VIShl02494 for ietf-calendar-bks; Thu, 31 Oct 2002 10:28:43 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VISgW02490 for ; Thu, 31 Oct 2002 10:28:42 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9VISWIR015841 for ; Thu, 31 Oct 2002 10:28:43 -0800 Message-ID: <3DC17658.3080907@Royer.com> Date: Thu, 31 Oct 2002 11:28:40 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 3.1 System Model References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070500030109080508020404" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070500030109080508020404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit There are possible solutions: (1) We alter the ABNF for CAP to allow it. (2) We create a new object that will only contain a CMD property. I would go for (1) by adding the following in section "2. Additions to iCalendar", after the 'calprops' ABNF and before the "In addition.." paragraph: Also the 'component' part of the 'icalbody' ABNF as described in [iCAL] section 4.6 is optional when the "VCALENDAR" component is sending a command as shown in the following modified ABNF: icalbody = calprops component ; If the "VCALENDAR" component contains the "CMD" ; component then the 'component' is optional: ; / calprops Bruce_Kahn@notesdev.ibm.com wrote: > > Doug responded on 10/29/2002 01:18:08 PM: > > Are you saing my email had an error - or the draft? > > Both. Your example is not in the draft(S) that Ive read and its already > been shown as being in violation of the 2445 ABNF. In looking at the > even more recent -09-b-2 draft I find that it too is in error. For > example, from Section 3.3.1 Use of BEEP, MIME and iCalendar: > > C: MSG 1 2 . 432 62 > C: Content-Type: text/calendar > C: > C: BEGIN:VCALENDAR > C: VERSION:2.0 > C: PRODID:-//someone's prodid > C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID > C: END:VCALENDAR > C: END > > Both violate the ABNF for icalbody from 2445: > > icalbody = calprops component > > because there is no component present; its all 'calprops'. > > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070500030109080508020404 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMTE4Mjg0MFowIwYJKoZIhvcNAQkEMRYEFByU41Fy o1s+IHv7Tpcpiw7xE3skMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCmAjc6+mUvMVS3Up14 iiO4R31SjdnUQKV5heDjOUUN/Jucn3Seb4wImavzezMdE1BBQcM8mok1CfPy2sXcX5oUtSA9 +uP7pAHFHXp3bq9o4p29/pDF1yb6qhv+X11t+uJgV/YaGQ1BrxgDSWBm21VKZdfieWEAwlOd QcwjB8p9ehUaZa7sBRT7p4SYv4wWJKwRI5Nhk0fKf0Qf/2kROr3sCm7b2Jb0EWcZc7WLHqgd WmZPkh0igszNxZTpF5GUcW8PhGUoUgXEI2a9aLgapxkziGE/NcgKpVQLabowFoj+4lcQDH6h MQzJyTIvO92ZFzbgllfnRUecxvpi6GK6lMbTAAAAAAAA --------------ms070500030109080508020404-- From owner-ietf-calendar@mail.imc.org Thu Oct 31 13:48:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07501 for ; Thu, 31 Oct 2002 13:48:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VIccE02817 for ietf-calendar-bks; Thu, 31 Oct 2002 10:38:38 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VIcbW02813 for ; Thu, 31 Oct 2002 10:38:37 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9VIccIR015919 for ; Thu, 31 Oct 2002 10:38:38 -0800 Message-ID: <3DC178B6.5060806@Royer.com> Date: Thu, 31 Oct 2002 11:38:46 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: GET-CAPABILITY - reply References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060601090809050601010004" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms060601090809050601010004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > Doug posited: > > The default values apply only to a CUA when it does not support > > sending a "GET-CAPABILITY" command reply. The following CS > > properties are returned in response to a "GET-CAPABILITY" command: > > Just to be clear: If a CUA _does_ support GET-CAPABILITY then default > values are not allowed? This is only the case if the CUA returns a > not-supported response code too, not a failure response code of some kind. Thanks - I have changed the text to: When the CUA does not support sending a "GET-CAPABILITY" reply, then the CS MUST assume the defaults listed below. The following properties are returned in response to a "GET-CAPABILITY" command: Better? > Also, the use of CS in the last line is inappropriate if the CUA also > supports GET-CAPABILITY. Simply striking it from the text seems to be > sufficient. Done. --------------ms060601090809050601010004 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMTE4Mzg0NlowIwYJKoZIhvcNAQkEMRYEFF/AZz00 /eyvt3RL3F+glu6DmnFjMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBcgn7Qep7Ge8VXPmlu RenvpjQX/Zm+dqPVf1k42xOuSI8GfVkBNdN1qzpCXDp5mjv6P7fLGJtgwsINqF3C0lGYl1Xj JulgvMX3pw2mAP4VWnOFFJMfNUf/ANCFTS4+w5uo0DK8f0w9c5weQULzI2KeH0MyeYSLkR7r kgAQsNh00x+X3zc1XiMAqd7lv2g8VgF4ZcL3TBgxlPG5PKacY7OqkaaBJHlzQ3zZnjm1KT2E qhCjO3jAeEwb8vVRbEV0yPr4EHre4ebPpTWctRXSfWTqANFSKQ7p9nvijRUfQqrKO7XTlLxF g/djNPxxImcnIu4UGM2SeCLza7plVFYydrkkAAAAAAAA --------------ms060601090809050601010004-- From owner-ietf-calendar@mail.imc.org Thu Oct 31 13:58:55 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08185 for ; Thu, 31 Oct 2002 13:58:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VIjFe03095 for ietf-calendar-bks; Thu, 31 Oct 2002 10:45:15 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VIjEW03090 for ; Thu, 31 Oct 2002 10:45:14 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9VIjFIR015972 for ; Thu, 31 Oct 2002 10:45:15 -0800 Message-ID: <3DC17A43.2090202@Royer.com> Date: Thu, 31 Oct 2002 11:45:23 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 2.2 Relationship of RFC-2446 (ITIP) and CAP: Taking no action References: <3DC03F72.70101@Royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000808030604060001070409" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000808030604060001070409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Doug Royer wrote: > > > Bruce_Kahn@notesdev.ibm.com wrote: > >> >> In 09-b-2, Section 2.2 Relationship of RFC-2446 (ITIP) and CAP is: >> >> The CUA could also decide not to book the object. In which case the >> "UNPROCESSED" state objects could be deleted from the CS. Or the CUA >> could set those object to the marked for delete state. >> >> There is another option that should be added to the list since we are >> listing options. The other option is the CUA decides to take no >> action and as such does NOT remove the "UNPROCESSED" objects from the >> CS. Just because I open an email does not mean I have to take any >> action on it (unless its a posting from Doug). I added the sentence: The CUA could also ignore objects for later processing. to the end of the above paragraph - okay? > I'll add. > >> Hmm, besides the grammar bug I already reported to Doug in the last >> line I think that the 3rd sentence says basically the same thing that >> the 2nd does. Dont both say that the CUA can delete the entry??... > > > I'll make it clearer - in one case the object is marked for delete. > In the other - it is deleted. The entire paragraph now reads: The CUA could also decide not to book the object. In which case the "UNPROCESSED" state objects could be removed from the CS or the CUA could set those object to the marked for delete state. The CUA could also ignore objects for later processing. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms000808030604060001070409 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMTE4NDUyM1owIwYJKoZIhvcNAQkEMRYEFOCNX9w6 Xl2/b/niPRueqoyzxi9zMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQA3UT1wO6bwtFzNVskd zhhJSZxGclAbB4Hlw6Juxw28i9BIw2RFx94xHVC5ueRKbpxHY3lgRd2B14W+NLiBArdfwXti cx37UMLDGKIeSnEVfn4r85WCnZY7C6OqZb9Z8RIgBcunaRGdF6m/y0mNGjkc4bcCn3OVnUCQ IEbJVqgFkXzQisx8H6kTOiHkGneDqZEsnCt9TxrOY/6NwTcBXjfywFxnJ73gwEFk6H22CBHS xszskuqYhxjbSyJB1U5G3F+Et8CG3sQA2J51mC7ayNracaSlalTRUClbc9tmUc0hiQ0d3rPB pY+gtkb5Kc/jMuOMgs0wTksaWg9NLA6OsW6MAAAAAAAA --------------ms000808030604060001070409-- From owner-ietf-calendar@mail.imc.org Thu Oct 31 14:11:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08945 for ; Thu, 31 Oct 2002 14:11:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VJ4cw05151 for ietf-calendar-bks; Thu, 31 Oct 2002 11:04:38 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VJ4bW05147 for ; Thu, 31 Oct 2002 11:04:37 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9VJ4cIR016112 for ; Thu, 31 Oct 2002 11:04:38 -0800 Message-ID: <3DC17ECE.5070007@Royer.com> Date: Thu, 31 Oct 2002 12:04:46 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 1.3 Defintions: BOOKED References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070805070902030203030807" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070805070902030203030807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > The 09-b-2 draft says: > > BOOKED - xxx An entry in the calendar store has one of three > conceptual states. It is "UNPROCESSED" state, "BOOKED" state or > marked as "DELETED" state. How the implementation stores the > state of any object is not a protocol issues and is not discussed. > An object can be said to be booked, unprocessed, or marked for > delete. > > First, the "xxx" after the dash should be removed. Done. > Second, the term 'entry' is used to denote those components like VEVENTs > or VTODOs instead of using 'entity' which denotes all objects including > VTIMEZONEs, VCARs, etc. There is no actual definition of what an > 'entry' actually is. There is text under Section 2.2 that says: I changed it to use the word 'object', to be consistent with the rest of CAP: An object in the calendar store .... > A CUA may create a "BOOKED" state entry by depositing a iCalendar > object into the store. This is done by depositing an object that > does not have a "METHOD" property. > > However this is not 100% accurate as a CUA can deposit a VCAR into the > CS w/o a METHOD property and by this definition the VCAR would be > considered "BOOKED". (Same goes for a VQUERY, VTIMEZONE, etc) Yes - they are booked. > Editorial: The text: > > 1. A "UNPROCESSED" state scheduling entry... > > should start with "An" instead of "A". Done. > Editorial suggestion: The text: > > All scheduled entries are > [iTIP] objects. > > should include the phrase "group" to be more accurate: > > All group scheduled entries are > [iTIP] objects. > > since I can schedule an event on my calendar w/o using iTIP (ie: I > create a doctors appointment w/o using iTIP). As I don't see the distinction, (are not all ITIP object group scheduling objects?) How about: All object with a "METHOD" property are [iTIP] objects. > Editorial suggestion: The text: > > 2. A booked entry is stored with the "CREATE" command. > > should be tweaked to be like the following for consistancy: > > 2. A "BOOKED" state entry is stored with the "CREATE" command. Done. > the same kind of change goes for changing: > > 3. A marked for delete component is set to the "DELETE" state. > > to something like: > > 3. A "DELETED" state entry has been marked for deletion or > actually removed from the Calendar. That would make it - not true. I used: A "DELETED" state entry is created by sending a "DELETE" command with the "OPTION" parameter value set to "MARK". -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070805070902030203030807 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMTE5MDQ0NlowIwYJKoZIhvcNAQkEMRYEFGiv0ljb baBkGIwCN/d72mrt1nyaMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCOSjXEmlUbAjbhUY4Q F2gCujqojylmmeVD396VkpXeayJm1A8tk4yvk/kXTnT2jl/z7m5FqvkuaZndjaE/klFGy4vy nYuo5pHL3oZEMeEregQO9fLdJ/a4lsGYl3/hNjmtCsHKDlHCexdTGFKQjwjgp57QxN9v14RH FSB6UjY9UHhjt6hHI+65+TBPs7iCsZ99XVSrUe1vDPbU10eq8V0W/xpq9Ubw0+r7ywoya9Nl Swcs7nyI1sJ3vcaK2qmEEXLLRbqQ2RrxXBynVQkleYmw+Aanb0FHxTr/1C34PnAggSt39hVM qXXnf3JhPvpVsolnOc/HN76mWoZGRfDPvwU6AAAAAAAA --------------ms070805070902030203030807-- From owner-ietf-calendar@mail.imc.org Thu Oct 31 14:22:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09523 for ; Thu, 31 Oct 2002 14:22:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VJ9pW05286 for ietf-calendar-bks; Thu, 31 Oct 2002 11:09:51 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VJ9oW05282 for ; Thu, 31 Oct 2002 11:09:50 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9VJ9oIR016151 for ; Thu, 31 Oct 2002 11:09:51 -0800 Message-ID: <3DC18007.7000707@Royer.com> Date: Thu, 31 Oct 2002 12:09:59 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: Editorial: Consistant labeling of iMIP & iTIP References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070802030409060806000905" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms070802030409060806000905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > The are mixed "iMIP" and "[iMIP]" references throughout the draft. > Since the reference is to the RFC all references probably should be > bracketed. I dont care which way the change goes as long as its > consistant thru the draft. Fixed - thanks! > There are also similar iTIP/[iTIP] mixes that should be fixed concurrently. Fixed - thanks! -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms070802030409060806000905 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMTE5MDk1OVowIwYJKoZIhvcNAQkEMRYEFHJN0By9 CRkFPCaMTPhs9y+QYqouMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQB94cOzOTdPrfK6meFf Go35QspUBmZvgIthfkWqqgC6W1kDIxnS4Fg4GbRqU4C89WiByePlf202LmXCU3lbPSFuFwwc uAfpT3L5mgQKRU9jxr3KdVZb8fy3cCvN5ArjSZ+z52j3IWuoKTUXvsPudlJRMRI22BS/bWms zDkVaJcmkmSmoj8Wd8hYL6eq2VXjiJ6vvg5rejR5s0yV52kJ1nea8GTgfIpimvu4NuGHCCx0 zgkJy4LMMsJXuskg9bGqXvjrzLxYllPL/PFw+AjtcG45QYxa1ANR0DcmH/cl4AnCUaJhy4Oj scO652FqilIPz4g/g7Wurjf3ABh0PXkwpEHUAAAAAAAA --------------ms070802030409060806000905-- From owner-ietf-calendar@mail.imc.org Thu Oct 31 14:39:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11467 for ; Thu, 31 Oct 2002 14:39:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VJXBx06456 for ietf-calendar-bks; Thu, 31 Oct 2002 11:33:11 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VJXAW06451 for ; Thu, 31 Oct 2002 11:33:10 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9VJXBIR016350 for ; Thu, 31 Oct 2002 11:33:11 -0800 Message-ID: <3DC1857F.6030507@Royer.com> Date: Thu, 31 Oct 2002 12:33:19 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: CUT OFF DATE Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050600010506090306090808" To: undisclosed-recipients:; Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050600010506090306090808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 'OUR' cut off date for the '-09' version of the draft is Tomorrow evening Friday November 1st, so that we have time to incorporate the WG comments into CAP before the IETF cut-off date (of November 4th 9 AM ET). Please keep those cards and letters coming. We are getting CLOSE! And please do NOT stop sending comments after November 1st , we can still use them, however they may be in rev '-10'. I am hoping that our next push (-10) can be the final call. Unless something comes up, it should mostly be typos, removing duplicate text and perhaps some reorganization without rewording. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms050600010506090306090808 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMTE5MzMxOVowIwYJKoZIhvcNAQkEMRYEFDxWtEkk L7dQSsY3zOjRV6SE3H00MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBAc2OJrWcHqTYqEWlu NaMwHnOXclak9u8015q7WaZynJ1KGa1K4z57m4DhjJlWsbX7cLxjxFKSgrjdgc0x9gKuTHBn k/Pk6BbymAs9lVxFu5clelNh/68opsqiud1hHHKmSBQt52c52FZB2WGa0IKGWbCoHkiYXjc6 cYBXjBY3CMYt/UxJxJOfRMMRmegwRxh4vn/9EMwJlH7ylyNyf9pyLhOlyo+4sMY9gTJkgMu+ hNPk8HrW0Bmhzj3G2+BR8OrF6kfY1tvMNNyEOLyuFZ9V9+SPTtp2Et9PVECMM4RR/jaNMUIm BR5o5io5/kyneM2MI0YiWE+RNJYQjJI6t3aCAAAAAAAA --------------ms050600010506090306090808-- From owner-ietf-calendar@mail.imc.org Thu Oct 31 16:21:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15673 for ; Thu, 31 Oct 2002 16:21:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VLFYW12672 for ietf-calendar-bks; Thu, 31 Oct 2002 13:15:34 -0800 (PST) Received: from royer.com (royer.com [4.23.9.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9VLFXW12668 for ; Thu, 31 Oct 2002 13:15:33 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id g9VLFZIR017191 for ; Thu, 31 Oct 2002 13:15:35 -0800 Message-ID: <3DC19D80.10006@Royer.com> Date: Thu, 31 Oct 2002 14:15:44 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: [Fwd: CUT OFF DATE] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000809060503000305020109" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000809060503000305020109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [This may be a duplicate] 'OUR' WG cut off date for the '-09' version of the draft is Tomorrow evening Friday November 1st. This is so that we have time to incorporate the WG \ comments into CAP before the IETF cut-off date (of November 4th 9 AM ET). Please keep those cards and letters coming. We are getting CLOSE! And please do NOT stop sending comments after November 1st , we can still use them, however they may be in rev '-10'. I am hoping that our next push (-10) can be the final call. Unless something comes up, it should mostly be typos, removing duplicate text and perhaps some reorganization without rewording. -- - Doug Royer Work: (208)612-INET Doug@Royer.com Fax: (866)594-8574 http://INET-Consulting.com Cell: (208)520-4044 http://Royer.com/People/Doug --------------ms000809060503000305020109 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC 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+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAzMTIxMTU0NFowIwYJKoZIhvcNAQkEMRYEFFwioRYa 8sQn2dCpkpdOuwYkw3TzMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBTzWXcxZCXxVAwgvyb hQa8rhRkla/4f0qlAjEfEOGT6iqSdzqRTNYnijJ7m11L2JUBDJ3U3FYk7XYTSA+zkPP2YTGq LgRGsbLcoBT3/hInLtLZaqGNfhYSIX8OxhIB4bEqkM+yLa4RnWXeUiPi1CYbqU2aeAqJn0Zr BanaYIu+njB3WdtEwAqgNPRSU9GiEZWfNyC9k65YfCOLyLcsuQSw7l3Z2sRJannxkCQm146K CQpmjG6xZiqkWFugie1glfwySJCu0bBulK53/6ZBqzZrVAeoY+/WGHRiqR32QwiQgFFTped9 Qf6ANnvfJi4+8cter2tbZfcHK1amiJgrTWyJAAAAAAAA --------------ms000809060503000305020109--